The system says forty-three. The shelf has forty. Both numbers were true at some point today.
On-hand is not one figure per product, and treating it as one is what hides the problem. The same SKU sits in three bins, under two lots, in a package that came in on someone else's pallet, and the product-level total is the sum of all of it. A shortfall in one bin nets quietly against a surplus in another and the number on the product page looks fine. The count that would find it is scheduled by whoever remembers, entered on top of whatever the system currently believes, and by the time it is keyed in the stock has moved again. Nothing is broken. The variance is always explainable, and it is explainable every week.
What you get with inventory management
On-hand stock held as a set of records rather than a balance. Each one is the intersection of a product, a location, a lot or serial number, a package and an owner, carrying its own quantity and its own reserved quantity, so the same product in two bins, under two lots, or belonging to two owners is several records, and a discrepancy has somewhere specific to be.
Tracking is a policy per product, not per warehouse: none, by lot, or by unique serial. Lot and serial names are held unique per product and company, and which operations are even allowed to invent a new lot number is a setting on the operation type rather than a habit.
A count is a proposed quantity, kept in its own field beside the number the system believes, with the difference computed and stored. Nothing moves until the count is applied, and applying it creates an inventory move in the appropriate direction. Counts can be requested onto named records with a due date and an assignee, or scheduled from a counting frequency set on the location itself, which computes the next expected count date.
And if the stock moved while a count was outstanding, that is collected as a conflict before anything is applied, not written over the top of the newer figure.
Stock that belongs to someone else lives in the same records rather than outside them: an owner is one of the keys the quantity is filed under, on the stock, the move line, the transfer and the package.
Where inventory management comes from
All of it is Odoo Community, built into the stock image, the per-location stock records, the three tracking policies, the count-and-apply cycle, the conflict record, per-location count scheduling, the Count Sheet report and the traceability report. There is no module to add, no tier to reach, no per-seat fee, and the deployment is one you own. In NetSuite this is a licensed module and a per-seat renewal; in Odoo it is already included, and that difference is the product.
Two boundaries are worth knowing before you sign anything, because both are things NetSuite markets under this heading.
The first is reorder logic. Reordering rules are real and they are Community, minimum and maximum quantities, lead-time and visibility horizons, a snooze, and a replenishment screen. What they are not is demand planning. The minimum and maximum are figures a person sets; there is no history model, no seasonality and no trend anywhere in the product. NetSuite markets this as "demand-based replenishment" using "historical and seasonal sales data" to move reorder points dynamically, and that specific mechanism is absent. Replen ishment is covered on reorder rules and replenishment, where it is stated as what it is.
The second is narrated reporting. NetSuite ships AI-written summaries over its inventory reports. There is no counterpart in either Odoo edition and no free module that supplies one, it is one of twelve capabilities on the whole map with no route, and an install does not close it. The inventory analytics that do exist are rule-based, and they do not narrate.
What the agent adds to inventory management
It watches the stock that is meant to be sellable, and it raises what it finds. It reads on-hand quantities sitting in internal locations, separates the ones that are genuinely negative, where the oversell has already happened, from the ones that are merely low, and writes a severity and a concrete recommendation for each. A person reviews that; on approval it logs one finding against the product so the note is waiting on the record the next time anyone opens it.
That is the whole of it, and the boundary is the promise rather than a caveat. It changes no quantity. It posts no inventory adjustment, holds no listing and blocks no sale order. It is an agent that notices and hands you the decision, which is a different product from one that transacts, and the difference is the reason it is safe to leave running.
This is a monitoring workflow, not a correcting one. It writes one follow-up activity and nothing else. Nothing on this page describes something that has run for a customer, Del AI has completed no migrations.
What is cycle counting in inventory management?
Cycle counting is the practice of counting a small part of the inventory on a repeating schedule instead of counting everything at once during a shutdown. A location, a product category or a group of high-value items is counted this week, a different set next week, and over a cycle the whole warehouse is covered without the business stopping. The reason to prefer it to an annual physical count is not that it is less work, it is that the gap between an error occurring and the error being found gets short enough that the cause is still knowable. A variance found in March on stock that moved in October is a write-off. The same variance found nine days later is usually a receiving mistake somebody can still remember.
Why can a stock count come back clean at the product level and still be wrong?
Because the figure on a product page is a sum, and sums hide offsetting errors. On-hand for a single product is normally spread across several locations, and often across several lots, packages or owners within those locations. If one bin is short by three units and another holds three that were put away in the wrong place, the product total is exactly right and both bins are wrong. The picker who walks to the first bin finds nothing there, and the ledger has no complaint to make because nothing about it is out of balance. This is the argument for holding stock as records keyed by location and lot rather than as a balance per product: the total is then something you can derive, and the place where a discrepancy lives is something you can point at.
What should an inventory agent do when it finds a negative on-hand quantity?
It should raise it and stop, rather than correct it. A negative on-hand figure is not a problem in itself, it is the receipt for a problem that already happened, usually stock that was shipped or consumed before the paperwork that brought it in was processed. The correct resolutions are different from each other and only one of them is an inventory adjustment: the missing receipt may be sitting unprocessed, the goods may have been picked from the wrong lot, the count may be wrong, or the stock genuinely may not exist. An agent that writes an adjustment to make the number non-negative has destroyed the evidence for which of those it was, and it has done so silently, because the ledger balances either way afterwards. Naming the record, the severity and the recommended action turns a number nobody was looking at into a decision somebody makes on purpose, and leaves the adjustment, which is a stock-ledger write, with the person who is accountable for it.
Does Odoo track inventory that a vendor still owns?
Yes, and it does it inside the same stock records rather than beside them. An owner is one of the keys that on-hand quantity is filed under, alongside the location, the lot and the package, and it is present on the stock record, the move line, the transfer and the package, so vendor-owned goods can be received, stored, counted and moved without the receiving company taking title. One consequence is worth knowing before you plan around it: stock whose owner is not the company is deliberately excluded from valuation, so it writes no valuation layer and no journal entry, and the stock module ships no ownership-transfer action to bring that stock onto the books when title eventually passes. Consignment is therefore fully tracked and not automatically capitalised, and the moment of purchase has to be booked as its own transaction.