The number nobody believes
Ask a store manager how much of a product they have, and you will often get two answers: the one on the screen and the one they believe. The second is usually offered with a small shrug. Ask the planner at head office, and they will quote the first, because the first is the only one they can see.
That gap is the most expensive quiet problem I have met in retail systems. Replenishment orders are built on the screen number. Online promises of “in stock” are built on the screen number. Staff send customers to the shelf because the screen says there is one more, and the customer leaves unhappy. Meanwhile, the real number is sitting in a back room, or on the wrong shelf, or in a damaged-goods bin, or never arrived.
I have worked on retail systems, checkout, stock and, more recently, practical AI for many years. The pattern repeats across formats and countries: the stock count never matches. This essay is a field guide to why, and to the loop that keeps the gap small enough to run a business on.
Why the count drifts
It helps to stop treating drift as a mystery and start sorting it into causes. Nearly every discrepancy I have seen belongs to one of three groups.
Physical causes
Goods leave the building without a sale: theft, damage, spoilage, samples, staff use. Goods arrive but are miscounted at the door. Goods are in the building but in a place the system does not know about, such as a promotional display, a stock room corner, or a returns cage. A shopper picks up an item, changes their mind, and leaves it on the wrong aisle, so the item exists but is lost to anyone looking.
These causes are physical, and no software removes them. What software can do is shorten the time between the event and the moment someone notices.
System causes
A sale is recorded twice, or not at all, because a till was offline and replayed. A return is accepted into stock when the item is damaged. A unit-of-measure mismatch turns a case of twelve into twelve cases. An item gets a new code during a range change and the old code keeps its stock. Two systems each hold a version of stock, and one of them lags.
System causes are sneaky because they are consistent. The same fault drifts the same item the same way every week, and the drift looks like shrink.
Process causes
A receiving team skips the check on a trusted supplier. A transfer between stores is shipped but not received. A stock adjustment is posted without a reason. Cycle counts are done on the easy aisles because the hard ones are tiring. A promotion changes the pack size and nobody tells the stock team.
Process causes are the most human and the most fixable. They are also the ones that hide longest, because each step looks reasonable to the person doing it.
A parable of the granary
Here is a parable, in the spirit of the teaching stories I like, about a granary keeper. It is a story I tell, not a record of history.
A king appointed a keeper to look after his grain stores. Each year the king asked how much grain there was, and each year the keeper opened his ledger and read out a number. Each year, when the grain was actually needed, there was less. The king grew angry and replaced the keeper. The new keeper did something different. Before reading the ledger, he walked the store, and every few days he counted one section and compared it with the book. When the numbers differed, he did not blame anyone first. He asked what had happened in that section since the last count: rats, a leaking roof, a delivery not entered, a measure of grain given to a guest. Over a season, the ledger and the store grew closer, and the king stopped asking angry questions.
The point I take from the parable is not that the first keeper was dishonest. It is that he treated the ledger as the truth and the store as a detail. The second keeper treated the ledger as a claim, and the store as the evidence. A reconciliation loop is the habit of testing the claim against the evidence, often, in small pieces, and asking why they differ before deciding who is to blame.
The ledger and the shelf
Two ideas are worth keeping separate.
The ledger is the system’s record of what should be there: receipts in, sales out, adjustments and transfers. It is a story told by events.
The shelf is what is physically there. It is a fact observed at a moment in time.
They differ because events can be missed, duplicated, misdescribed or delayed, and because things move without events. Reconciliation is the discipline of bringing the story and the fact into agreement, and of learning from each disagreement.
An important consequence: a count is not an act of repair. A count is a new observation. If you count and then simply overwrite the ledger, you have fixed this week’s number and learned nothing. The value is in what you do with the difference.
What a reconciliation loop is
A loop, not a project. A project ends. A loop runs every day, at a small scale, and the number stays usable. I think of it as four steps.
Detect
You cannot fix a gap you have not noticed. Detection comes from several sources, and mature operations use more than one.
- Scheduled counts of selected items or areas.
- Event-triggered checks: a pick that cannot find the item, a negative stock position, a return of something the system thinks is not in the building, a sale of an item with zero recorded stock.
- Pattern signals: an item whose sales and receipts never add up, a store with a rising rate of adjustments, a supplier whose deliveries are often short.
The second group is the most underused. A staff member who cannot find an item is a free count. If the system treats “could not find it” as a signal rather than an annoyance, drift is detected at the moment it hurts.
Diagnose
Before correcting, ask which kind of cause is likely. A useful habit is to look at the item’s recent history: receipts, sales, transfers, returns, adjustments. Most discrepancies leave fingerprints. A pack-size change shows up as a sudden step. A missed receipt shows up as sales without enough stock. A duplicate sale shows up as a sale with no matching customer footfall in that hour.
Even a rough diagnosis changes what you do next. If the cause is a missing delivery receipt, you chase the supplier or the receiving team. If it is theft, you review the area. If it is a data error, you fix the master record.
Decide
Decide how to treat the difference. Not every gap deserves the same response. Small differences in cheap items may be written off with a reason code. Large ones, or those in high-value or high-risk items, need a second person and perhaps a recount.
The decision should be written down, because the next person who meets the same item needs to know what was done and why.
Correct and learn
Adjust the ledger with a clear reason, and then do the step most teams skip: record the cause, and feed it to whoever can remove it. If the receiving team misses deliveries from one supplier, the fix is a process. If a pack-size change confuses stock, the fix is in item setup. The loop closes when the cause is addressed, not when the number is changed.
Cycle counts that find something
Cycle counting is the most common tool, and it is often done in a way that finds little. Counting the same easy shelves every month produces tidy results and false comfort.
A few principles help.
Count where drift is likely. Fast movers, high-value items, items with recent changes, items with many adjustments, items near entrances and returns areas. A simple scoring of risk and value beats counting alphabetically.
Count at quiet moments but not predictable ones. If everyone knows the count happens on Tuesday morning, the Tuesday shelves are tidy.
Count blind where you can. If the counter sees the system quantity first, they are tempted to confirm it. Blind counts are slower and more honest.
Recount differences before adjusting. A first count that disagrees with the ledger is often a counting error. A second count from a different person resolves most of them cheaply.
Look at the location, not only the quantity. An item found in the wrong place is a discrepancy even if the total is right. Online fulfilment and in-store pick both depend on location accuracy.
Keep the count small. A short count done every day will find more, and teach more, than a large count done twice a year.
Tolerance, trust and the cost of precision
Perfect accuracy is not the goal. It would cost more than the stock is worth. The goal is accuracy that is good enough for the decisions you make from it.
That means thinking about tolerance by purpose. The number needed to decide a replenishment order is different from the number needed to promise an item online, which is different again from the number needed for financial reporting. A promise to a customer that an item is “in stock” deserves a higher bar than a weekly forecast, because a wrong promise is visible and personal.
One practical tool is a buffer. If the system shows stock for online orders, it may hold back a small quantity for items with a history of drift, so that the promise rarely fails. A buffer is an admission that the number is not perfect, and it is more honest than pretending otherwise.
Trust is the other side. Staff stop caring about accuracy when they see the number ignored. Planners stop trusting the system when it has misled them. Rebuilding trust takes visible wins: a count that found a real cause, a fix that stopped a recurring gap, a report that said where the drift came from and then showed it shrinking.
Where automation helps and where it misleads
Automation can do a lot here, and it can also make things worse if used carelessly.
It helps in detection. Models and rules can spot items whose history looks wrong, rank counts by likely value, and flag stores whose adjustments drift. It helps in diagnosis by summarising the history of an item and proposing likely causes for a person to confirm. It helps with handoffs, drafting a clear note to a supplier or a store about a missing delivery.
It misleads when it hides the loop. An automatic adjustment that quietly makes the ledger match a count removes the signal that something is wrong. A forecast that smooths over drift makes the shelf and the screen look closer than they are. A confident model with poor data gives confident wrong answers faster.
My rule of thumb is that automation should speed up the loop and make it more visible, not replace the human judgment in the decide step for anything of real value. The most useful thing an automated helper can often do is say: this looks wrong, here is the evidence, someone should look.
A starting playbook
For a team that wants to improve without a big programme, I would start here.
- Choose a scope. One store, one department, or one category with a known problem. Small enough to learn quickly.
- Measure the gap honestly. Do a blind count of a sample and compare with the ledger. Note the size and direction of the differences.
- Sort the differences into physical, system and process causes. Even a rough split points at where to look first.
- Turn “could not find it” into a signal. Give staff a simple way to flag it, and make the system treat it as a trigger for a recount.
- Set up a daily small count. A handful of items chosen by risk, counted blind, recounted when different.
- Require a reason on every adjustment. A short list of reasons, reviewed monthly for patterns.
- Assign owners to causes. Receiving, item setup, supplier management, loss prevention. Each cause has a name next to it.
- Tell the floor what changed. When a cause is fixed, say so. People keep taking part when they see results.
- Revisit tolerances and buffers. As accuracy improves, tighten what you promise. As it slips, widen the buffer before customers notice.
Closing thought
The stock count will never match perfectly, and that is fine. The mistake is to treat the screen as the truth and the shelf as an exception. The better habit is the second granary keeper’s: walk the store, count a little every day, and ask why before asking who.
If you run stores, a warehouse network or a retail operations team, and want a second opinion on where your numbers drift and what to fix first, I am happy to talk it through. The first conversation is a free 20-minute call: https://topmate.io/raja_jeevan_kumar_maduri