When stock numbers drift

Buyers forgive a slow site. They do not forgive being told an article is available and then waiting three weeks for it, and they do not forgive being told it is unavailable when it is on your shelf. Both are stock accuracy problems, and they have different causes.

The shop says no and the shelf says yes

The single most common report, and the causes in order:

1. Stale reservations. Check Order Management › Stock › Reservations for active holds against orders that were never placed. An abandoned checkout that reserved stock and has no expiry holds it forever. Release expired runs the sweep; a reservation lifetime prevents the next one.

2. The article is not tracked at this location. Stock rows are per location. If the article has stock in hamburg and your allocation strategy only reaches main, the answer is legitimately no.

3. The location is disabled. A disabled location's stock does not count.

4. It is not a stock problem at all. An article can be invisible for six reasons and stock is only one of them — work through Why a product is not showing up.

The shop says yes and the shelf says no

The expensive direction, because the order is already taken.

Bookings that never happened. Goods left the building without a shipment being recorded, so the stock was never committed. This is the same cause as an order stuck at placed after delivery — see Orders that get stuck.

Backorders that were allowed. If your backorder policy permits it, a reservation can exceed stock, and the shortfall is recorded on the reservation rather than refused. That is a deliberate setting, not drift. Check the policy before you go looking for a bug.

Breakage and shrinkage nobody booked. The real answer, usually. Physical stock moves without anyone telling the system. Only a stocktake finds it.

An ERP that writes stock outside the ledger. If your ERP owns stock and pushes levels rather than movements, the ledger cannot explain the number because the ledger was not used. That is a design decision to be aware of, not a fault — but it means the movement trail below will not answer your questions.

Read the ledger

Order Management › Stock › Movements is every booking with its type, quantity, order reference and reason. Filter to one article and read it from the date the number was last known to be right.

If the movements do not add up to the current level, something wrote stock outside the ledger. That is an integration question: Sync errors.

The weekly loop

Five checks, none of which takes long:

1. Reservations older than your lifetime. Should be none. If there are, your lifetime is unset or too long.
2. Reorder alerts. Sort the stock list by reorder_point and work the rows at or below it.
3. Adjustments without a real reason. "correction" is not a reason. Require reasons on adjustments and read them.
4. Negative or zero available on A-articles that should never run out.
5. A rolling spot count. Ten articles a week, physically counted against the system. It finds shrinkage before a customer does.

Before you trust the number publicly

If you are about to start showing live availability to buyers — and in B2B you should, because it is one of the top things they ask for — do three things first:

• Run the spot count for a month and measure how often the system is right.
• Decide what you display: an exact number, a band ("more than 10"), or a delivery date. Bands are more forgiving and usually more useful.
• Decide what happens at zero. Backorder with a date beats a blank page, and both beat a number that turns out to be wrong.

An availability display that is right 95 % of the time is worth having. One that is right 70 % of the time costs you more trust than it buys.

Next

• Manage stock day to day — the bookings themselves.
• Stock, locations and availability — the settings that prevent most drift.