Every fresh department manager knows the on-hand number in their inventory management system is off. What is less obvious is how far off it tends to be, and why more counting doesn’t close the gap.

Across retail, roughly two-thirds of inventory records are inaccurate at the moment of a count, and perishables run worse than shelf-stable items. In fresh, that is not a data-quality lapse. It is the predictable result of using a running-balance record in a department where product moves without leaving a trace.

What is perpetual inventory, and why does it break in fresh?

Perpetual inventory is the default method of grocery inventory management: you count what you have, the system add what is received, and subtract sales and scan-outs. The arithmetic assumes every movement of product generates a transaction, and in center store it can work. A can arrives, sits, and sells, and each step leaves a record.

Fresh items, however, are too variable for a running balance to keep up. The DC sends a different variety. The item master says a case holds 12 and the box on the dock holds six. Mixed berries ring as strawberries. A raw whole chicken becomes five retail items at yields that change with the cutter. Culls and samples go in the bin with nothing recorded. None of this is a failure by store associates. It is failure in the design and an accurate depiction of how an ordinary fresh department runs.

How does a wrong on-hand number affect each department?

A wrong number in center store costs a late reorder on an item with a 12-month shelf life. The same wrong number in produce or deli becomes shrink or an empty shelf inside 48 hours. Fresh also generates the most record-degrading activity per item: more receiving, more handling, more production, more markdowns.

So the record is worse in fresh than anywhere else, and the errors that cost the most run one direction: the screen says six cases and the table is empty. The system won’t order because it thinks the product is there. The department manager either catches it on a walk and writes the order by hand, or the floor has a hole until the next count. Either way the sale is gone, and the item never showed up on anyone’s review, because on the screen it looked fine.

Why doesn’t counting more fix it?

The instinctive response is to count more. A cycle count does correct the record for the items counted, on the day they are counted, and the drift starts again the next morning. Data cleanup and system integration reduce the noise without removing it, because the causes are physical. Product leaves the department without a transaction, and no amount of data hygiene creates a transaction that never happened. The record has to be built to handle that uncertainty rather than assume it away.

What does a wrong on-hand number do to the order?

Every ordering system starts from on-hand. When the record says six cases and the cooler holds two, the system orders late and the shelf sits empty while the screen shows stock. When the record says two and the cooler holds six, the system orders into a full cooler and the extra becomes shrink.

Overrides follow. Store teams change the recommendation because they can see the shelf and the system can’t. A high override rate is usually a symptom of a wrong on-hand number rather than a stubborn team.

How does Afresh estimate on-hand inventory?

Afresh does not depend on a retailer-maintained perpetual inventory. Across more than 12,800 departments, its on-hand estimates are 10–40% more accurate than perpetual inventory. Instead of treating on-hand as one known number, the platform keeps its own estimate for every item in every store, and it knows how sure it is about each one.

The estimate starts with what came into the department and what sold. It then folds in store counts, recorded shrink and scan-outs, case-pack and unit-of-measure details, the loss pattern the model learns for that item in that store, and more. As new signals arrive, the estimate moves with them.

Afresh compares how fast an item should be depleting with what the register and the counts actually show, learns how quickly each item’s record tends to drift, and tracks how confident it is in the current position.

When that confidence drops far enough to change the next order, the item goes on the count list. An item the model is still sure about stays off the list, and nobody counts it because a schedule said to.

A count is more than a correction. It becomes another signal the model uses to recalibrate the estimate and decide when that item needs checking again. The resulting position, with its uncertainty, feeds the order recommendation, so the system can weigh an empty shelf against product that becomes shrink.