October 14, 2026
October 14, 2026
A customer is standing in front of you, holding her phone, and the website told her you had three of them in stock. Your screen agrees. The shelf does not, and neither does the stockroom after eleven minutes of looking. You offer to order one in, she says she'll try the other shop, and the system quietly carries on believing in three jackets that no longer exist.
In short: retail inventory records are wrong more often than most owners assume, and the research has said so for twenty years. The question is not whether your numbers drift, but in which direction, because overstated stock costs you sales while understated stock costs you cash and margin. Custom software earns its place when it fixes the way your counts go wrong.
What the research actually found about inventory accuracy
Those figures come from the academic literature on perpetual inventory, summarised in a 2008 working paper from the University of Arkansas. They are old, which is precisely what makes them interesting. Barcode scanning was already universal when that work was done, and the records were still wrong half the time, which tells you the problem was never really about scanning.
Most people who have run a shop know about phantom inventory even if they have never heard the term. The system says the stock is there, the stock is not there, and nobody finds out until a customer asks. It is the error everyone notices, partly because a disappointed customer is standing right in front of you when it surfaces.
What makes phantom stock genuinely dangerous, though, is quieter than the lost sale. Because the system still believes it holds three jackets, it does not reorder. The shelf stays empty not for an afternoon but for weeks, right through the part of the season when that jacket was supposed to sell, and the sales data afterwards shows a slow line that probably should be dropped next year. The error has now corrupted not just one transaction but your buying decisions for the following season.
Hidden inventory is the mirror image, and it rarely gets discussed because it never produces an awkward conversation at the counter. Here the system thinks you have fewer than you really do, so it reorders stock you already own, ties up cash you did not need to spend, and eventually leaves you discounting the surplus. Gruen and Corsten found this happens about as often as the phantom variety, which means roughly half the money your inventory errors are costing you is going out quietly, through over-ordering and markdowns, rather than through the visible lost sale.
That split matters a great deal when you start specifying software, because the two problems have completely different fixes. Phantom stock is usually a process and detection problem, solved by counting more cleverly and by noticing when a product stops selling in a way that looks suspiciously like a zero. Hidden stock is more often a receiving and location problem, solved by knowing where things actually are.
Nothing on this list is exotic, which is rather the point. Inventory accuracy erodes through ordinary days rather than through dramatic failures.
Goods arrive and get booked in against the purchase order rather than against what is physically in the boxes, because it is Friday and the van is waiting. A customer returns an item, the refund goes through the till, and the garment sits behind the counter for three days before anyone puts it back into stock, during which time the system thinks it is sellable and the shelf disagrees. Two products share a supplier code and get scanned interchangeably by a part-time colleague who was never told they are different. Theft happens, and the system has no idea. A click-and-collect order gets picked, the customer never comes, and the item goes back to the shelf without anyone reversing the allocation.
Then there is the transfer between branches, which deserves its own paragraph for the sheer reliability with which it goes wrong. Stock leaves one shop, arrives at another, and somewhere between those two events it exists in both places, or neither, depending on who confirmed what and when. Multi-site retailers who look closely at their discrepancies often find transfers sitting at the top of the list.
What these have in common is that every one of them happens in a few seconds, during a busy moment, and none of them feels like an error at the time.
Retail has a traditional answer to all of this, which is to close on a Sunday in January, bring in the family, and count everything. It is thorough, it is exhausting, and it is worth less than most people assume.
An annual count tells you the size of your discrepancy once a year, long after the discrepancy did its damage. It also tells you nothing about which products drift and why, because by the time you count, the trail is cold. You correct the numbers, everyone goes home, and the drift starts again the following Tuesday.
Cycle counting works on a different premise: count a small slice of the range every week, choose the slice according to risk rather than alphabetical order, and treat each discrepancy as information about a process rather than as a number to be corrected. High-value lines get counted often. Fast movers get counted often. The dusty corner of the range that nobody has touched since March can wait.
This is also where software earns its keep in a way that is genuinely hard to buy off the shelf, because the question of which items to count this week depends on how your particular shop goes wrong. A grocer with short shelf lives, a fashion retailer with size curves, and a hardware shop with loose fixings all have different risk profiles, and a count list that reflects yours is worth considerably more than a generic rotation.
Every weakness described so far behaves itself for ten months of the year and then turns up at once, in the six weeks when getting it wrong is most expensive.
The mechanism is not mysterious. Volume rises, so receiving gets rushed and the discrepancies that would normally be caught slip through. Temporary staff arrive who have had an hour of training and no feel for which two products are easily confused. Deliveries come more often and in bigger quantities, stock gets stacked wherever there is room rather than where the system expects it, and the stockroom stops resembling its own location model somewhere around the second week of December. Meanwhile returns climb, online orders compete with walk-in customers for the same physical units, and nobody has time to count anything.
So accuracy decays fastest precisely when accurate numbers are worth the most, and the damage compounds in both directions at once. Phantom stock during peak does not merely lose you a sale, it loses you a sale you had already paid to acquire through advertising, from a customer who came in specifically for that item. Hidden stock during peak leaves you placing panic orders at short notice, often at worse terms, for goods you were already sitting on.
The retailers who handle this well tend to do two unglamorous things. They count the critical lines more often as volume rises rather than less, accepting that an hour spent counting in late November returns more than an hour spent counting in May. And they decide in advance how online and in-store demand compete for the same unit, so that the rule is made calmly in October rather than improvised by whoever is on shift when the last one sells twice.
This is worth raising early with any software vendor, because a demonstration given in a calm month tells you very little about how a system behaves when the shop is full. Ask them what happens to their reorder logic when four weeks of sales arrive in one, and listen for whether they have met the question before.
Let us be honest about something first, because the pages competing for your attention on this topic are written by companies that build software and tend to arrive at a predictable conclusion.
Most retailers should buy. Shopify, Lightspeed, Cin7, Odoo, NetSuite and a dozen others have solved the common case thoroughly, they are cheaper than a build, they work on the day you pay for them, and somebody else maintains them. If you run a few shops with standard products and a conventional supply chain, a packaged system plus disciplined process will beat a custom build on almost every measure that matters.
The honest pattern in most successful projects is not a full custom build at all. It is a packaged core doing the ordinary work, with custom software handling the two or three things that make your business yours, joined properly so that neither side needs convincing the other exists. Our guide to custom software development covers the general trade-offs, and the integration question is covered in our article on system integration.
If you do build, these are the capabilities that repay the investment, drawn from what the error sources above actually demand.
Receiving against reality. Let the person unpacking the boxes record what is in them, quickly, with the discrepancy raised there and then rather than discovered in March. The interface for this should be usable by someone holding a box cutter.
A location model that matches your building. Shelf, stockroom, transit, returns pending, reserved for collection and damaged are different states, and software that collapses them into one number called "stock" will keep producing phantom and hidden inventory in equal measure.
Discrepancy as a first-class record. When a count disagrees with the system, the interesting part is not the correction. It is the pattern across six months, which tells you which products, which shifts and which processes are leaking. Most packaged systems record the adjustment and discard the story.
Suspicious zero detection. A product that was selling steadily and has sold nothing for nine days has either gone out of fashion very suddenly or is sitting invisible somewhere. This single alert catches a surprising amount of phantom stock before a customer does.
Counting support built around risk. Generate the week's count list from value, velocity and discrepancy history rather than from a rotation.
Seasonal memory. Retail is not a steady state, and a system that cannot tell the difference between a normal November and a normal July will give you reorder advice that is confidently wrong twice a year.
Published figures for this category sit roughly between 90,000 and 400,000 US dollars, with one widely visible vendor page putting small business builds at the lower end and large enterprise work above 600,000. Those numbers come from the companies selling the work, they describe the United States market, and they vary by a factor of four for reasons nobody explains, so use them to understand the shape of the spend rather than as a quotation.
What those pages tend to omit matters more than the range itself.
Your own people will spend real hours on this, in discovery, in testing and in the weeks after launch, and those hours come out of running the shops. Data migration is almost always worse than expected, because the stock file you are migrating contains years of accumulated mess that nobody has had a reason to confront until now. The system needs looking after once it exists, which is a recurring line nobody budgets in the first year. And there is a less obvious cost in the delay itself, since a build that takes six months is six months during which the process fixes you could have made this week sit waiting for software that has not arrived.
That last point deserves acting on rather than merely noting. Tighten receiving, start cycle counting, and clean up your returns process before anyone writes a line of code. The improvement is immediate and free, and you will specify far better software afterwards, because by then you will know which of your problems were really process problems wearing a technology costume.
A brief word of caution, since this subject attracts recycled numbers.
You will frequently encounter the claim that store-level inventory accuracy averages 63 percent, usually credited to the Auburn University RFID Lab. Tracing it back leads to a 2008 working paper from the University of Arkansas, not Auburn, and the paper itself notes that the retailer involved considered its true accuracy figures confidential, so only the relative improvement was published. The underlying literature it cites is sound and is quoted in the table above. The travelling 63 percent is less so.
Similarly, the shrink rates you will see attributed to the National Retail Federation deserve a date attached. The NRF reported 1.44 percent of sales in its 2021 survey, around 94.5 billion dollars, and a later survey put the figure near 1.68 percent and 112 billion. The organisation then discontinued the long-running annual shrink survey over concerns about its methodology, which is a reasonable thing for a trade body to do and an important caveat for anyone building a business case on those numbers.
None of this means the problem is overstated. It means the problem is better measured in your own shops than borrowed from somebody else's press release, and a week of honest cycle counting will give you a figure you can actually act on.
Conclusion
Pick fifty lines this week and count them properly. Write down not just the discrepancies but the direction of each one, and then sit with the list for twenty minutes, because the pattern in it is worth more than any software demonstration you will sit through this quarter. If the errors cluster around receiving, you have a receiving project. If they cluster around transfers, you have a transfers project. Either way you will walk into the next vendor conversation knowing something they do not.
Serdao has built and integrated software for eighteen years from a French head office with delivery in Ho Chi Minh City, and we are members of CCI France Vietnam and French Tech. Our custom software development and system integration pages set out how we scope this kind of work, and you can contact our team if you would like a second opinion on what your count list is telling you.
1. How do I know whether my inventory accuracy is a real problem?
Count fifty lines chosen by value and velocity, not at random, and compare them against the system without correcting anything first. The proportion that match exactly, and the direction in which the rest are wrong, will tell you more in an afternoon than any benchmark. If most of your errors overstate stock, you are losing sales. If they understate it, you are overpaying for inventory.
2. Can't we just fix this with better barcode discipline?
It helps, but the research above was conducted in an era when barcode scanning was already standard and records were still wrong around half the time. Scanning records the transactions that happen at the till. Most inventory drift happens somewhere else entirely, in receiving, returns, transfers and theft, which is why discipline alone tends to plateau.
3. Is RFID the answer?
For certain retailers, especially apparel with high SKU counts, it genuinely transforms counting speed and accuracy, and the Wal-Mart trial behind that 2008 paper showed a meaningful reduction in inaccuracy. It also carries tagging cost and process change that smaller operations rarely justify. Treat it as one option for the counting problem rather than as a replacement for the system that interprets the counts.
4. We already have a POS with stock control. Why would we need anything else?
Often you would not. The case for more usually appears when you have several channels disagreeing with each other, products that do not fit tidily into units, locations your POS cannot model, or pricing and allocation rules you have had to maintain in a spreadsheet beside the system. If you recognise none of those, your money is better spent on process than on software.
5. How long before it pays for itself?
Be sceptical of confident answers here, including the ones on vendor sites quoting payback in months, since those figures usually come from the vendor's own project history rather than independent research. A more useful approach is to measure your current discrepancy rate, estimate what a given improvement is worth in your margins, and treat anything the software cannot plausibly influence as outside the business case.
6. Should we start with one shop or roll out everywhere?
One shop, almost always, and preferably one that is representative rather than one that is easiest. The second site is where you discover which parts of your design were genuinely general and which were quietly specific to the first location, and finding that out across eleven branches at once is an expensive way to learn it.