First stop the number being used
Before correcting anything, stop the system allocating against a figure you have
just disproved. Blocking or freezing the location does that: no new picks are
directed there, and no availability calculation counts it.
The order matters. Correcting first and blocking second leaves a window in which
the allocator hands the three phantom units to three orders, and now you have
three customers expecting stock that does not exist and three cancellations to
issue. In a busy warehouse that window is seconds long and gets hit.
Then ask what the missing units were already committed to, because that is
the part with a customer attached. Three units allocated to an order picked this
morning means the discrepancy has already left the building or is about to;
three allocated to an order not yet released means you can source them elsewhere
before anyone notices.
Correct by adjustment, never by edit
The correction is a stock adjustment: a recorded transaction with a
quantity, a reason code, a user and a timestamp, which happens to bring the
system figure to match the physical one.
It is not an update to a quantity field, and the distinction is the whole design
point. Inventory is financial — stock is an asset on a balance sheet, and a
write-down is a cost that finance and often auditors will examine. An adjustment
is a posting; an edit is an unexplained change to an asset figure, which is
exactly the shape of thing controls exist to prevent.
The reason code is the part people treat as optional and is the most valuable
field on the record. "Adjustment: -3" tells you nothing next quarter.
"Adjustment: -3, reason: damage found at pick" is a data point about packaging.
Aggregate reason codes across a site and they name the process that is failing,
which is the only way this stops recurring.
The causes, roughly in order of frequency
Theft is what people assume and is rarely the largest contributor. The
unglamorous list:
Mis-picks. A picker took four of the adjacent item instead of this one, so
two locations are wrong in opposite directions and the pair reconciles if anyone
looks.
Receiving errors. The advance ship notice said twelve, ten arrived, and
receiving confirmed against the notice rather than against the pallet. This is
the first divergence of the day in most warehouses and it propagates everywhere.
Unrecorded movement. Someone moved stock to a forward-pick location at
midnight and did not scan it. Common, human, and the reason handheld workflows
are designed to make the scan the only way to complete the task.
Damage disposed of informally. A crushed carton went in the bin without a
transaction.
Unit-of-measure confusion. One case of twelve counted as one unit, or the
reverse. This one produces spectacular discrepancies and is a data-modelling
failure rather than a warehouse one.
Notice that most of these are pairs — something is wrong in two places — which
is why a discrepancy is a prompt to count the neighbouring locations rather than
only the one that failed.
Cycle counting, and why it beats a stocktake
The instinct is an annual full count. It is worse in every dimension: the site
stops, it takes days, it is done by people unfamiliar with the stock, and it
tells you your accuracy once a year with no ability to act on the drift in
between.
Cycle counting counts a rotating subset during normal operation. Accuracy is
maintained continuously, errors are found close to when they happened, and the
counters are the people who know the goods.
The selection is where the design lives, and it is not uniform. The conventional
approach counts high-value and fast-moving items far more often than slow,
low-value ones — an ABC classification, where the small share of items
representing most of the value gets counted many times a year and the long tail
gets counted once. Event-triggered counts are the useful addition: count a
location when a pick finds less than expected, when it hits zero, or when it has
had an adjustment recently, because those are the locations most likely to be
wrong again.
The metric that matters is not the count of adjustments but location
accuracy — the proportion of counted locations that matched — trended over
time and broken down by area and by shift. A rising adjustment count with steady
accuracy means you are counting more; falling accuracy means a process changed.
Negative on-hand is a signal, not an error
Worth raising unprompted because it reveals whether someone has worked with real
systems. A negative on-hand figure means the system recorded more going out than
it ever recorded coming in — receipts unrecorded, or a transaction posted twice.
Some systems block negatives outright, which sounds safe and forces the operator
to make something up so the pick can complete. Allowing them and alerting is
usually better: the negative is truthful, it is a precise pointer at a missing
receipt, and suppressing it hides the evidence.
The honest framing
Inventory accuracy is never 100% and no design makes it so. The physical world
diverges from the record continuously, and the discipline is not prevention but
detection speed and correction quality: how quickly you notice, whether the
correction is auditable, and whether the reason code tells you enough to change
the process that caused it.
Which is also why the availability figure the website shows is calculated with a
buffer rather than from raw on-hand. The system knows its own record is
approximately true, and designs around it.
Do not edit the number. Block the location, record an adjustment with a
reason, and treat the reason codes in aggregate as the only thing that will
actually stop it recurring.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).