The system says four units are in that location and there is one on the shelf. What do you do, and how do you stop it happening again?

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.