Retail Figures Are Not Wrong by Accident. Each One Is Made Wrong Somewhere.
We reviewed the public record on retail stock, product and customer figures that cannot be trusted. Here is what we found, why the cause stays hidden, the four ways to respond, and the benchmark we would set.
The system says there are fourteen of the blue jacket in size medium. The store manager walks to the rail and counts nine.
The manager corrects the figure, as managers do most weeks. Head office suspects returns are going astray in the stores. The stores say the system has always done this.
Three months later the figure for the same jacket is wrong again, by a different amount.
The paradox: Everyone knows which numbers are wrong, and nobody knows where they become wrong.
What We Found
For this article we went through the public record on retail figures that could not be trusted: press reporting of one large retailer’s system roll-out, one retail group’s account of its old supply chain system, and two surveys, from 2013 to 2026.
Four findings stand out.
When the figures are wrong, the business cannot run on them. When a large retailer’s Canadian business rolled out a packaged ERP product in 2013, its supply chain failed. A later press account says: “An investigation found that only about 30% of the data in the system was actually correct.” An older case, and a packaged product, which is not our kind of work. The record does not say how the data came to be wrong.
Late is one way of being wrong. A large retail and hospitality group described its ten-year-old in-house supply chain system as obsolete, and said of the time before it was replaced: “Before, we didn’t have access to real-time data visibility.” That is about late data, not wrong data; but a figure a day late is the wrong figure for today’s decision.
The systems behind the figures do not share. In a vendor-sponsored survey of “more than 100 senior retail and brand leaders” in the UK: “Among direct-to-consumer brands, 70% said their core systems were not yet fully integrated”. “Some 56% of retailers said fragmented systems were affecting profitability and customer experience”.
Data holds back change, too. In a vendor’s survey of 504 IT professionals in the US, 35% named data migration concerns among the reasons for not upgrading old systems. It covers every sector, not retail alone.
Our reading is that a wrong number is made somewhere particular: a rule in old code, a join between two systems, or a step done by hand. Nobody can say where, because nobody has followed the figure back.
What our review does not show: We found no figure for how often retail data is wrong, or what it costs. The one case squarely about wrong data is from 2013, concerns a packaged product at a very large retailer, and records no cause. The group’s remark is about late data. The UK survey is about integration, and its link to wrong figures is our reasoning. Both surveys come from firms that sell related services, and the US survey is not about retail. We found no named mid-size retailer with this problem, and nothing from India or the Middle East. That most wrong figures are made in a rule, a join or a manual step is our reading; some begin on the shop floor, where no software change helps.
What Waits While Nobody Knows Where the Number Goes Wrong
Wrong data is usually discussed as a tidying job. Our reading is that it costs more than the tidying.
The first cost is the meeting that never reaches its subject. A range review opens with an argument about whose figure is right, and the decision moves to next week.
The second cost is the evidence thrown away. A correction on the screen leaves no trace of its cause. Fifty corrections a week may be one rule, misfiring fifty times, and it runs again tonight.
The third cost is the argument about people. Without a traced cause, head office and the stores cannot settle whose fault it is, and the people who count and correct every week carry a fault that may not be theirs.
The gap we see: most retailers can say which figures are wrong. Few can say where any one of them is made wrong: which rule, which join, which step done by hand. A retailer that can name the place can fix the cause. One that cannot keeps correcting the result.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Answer Figures Nobody Trusts, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Run a cleaning project: count, merge, correct | The figures drifted for a known, one-off reason, such as a bad import | Whatever made the records wrong keeps running, so the project returns |
| Buy a data-quality tool and run it yourselves | Errors come from many outside sources, and the firm has staff to act on what the tool flags | It flags wrong records after they are made; the rule that made them is not opened |
| Replace the system and expect the new one to put it right | The old system is due to go for other reasons, and its rules are well understood | The old data and manual steps move across, and nobody has said where the errors came from |
| Trace each wrong figure to where it is made, then rebuild that part with checks at the point of entry | The same kinds of error return after every clean-up, and the systems were built or adapted for the firm | It costs money before anything changes, and some causes may be on the shop floor, beyond any software change |
Our recommendation: trace each wrong figure to where it is made, then rebuild the part that makes it, one module at a time, with checks that refuse a bad entry when it is typed. We do not clean, correct or reconcile records, and we do not count stock: your own people do, and a clean-up lasts once its cause has gone. We read the code and the structure of the database, not your records.
Where You Are Now, and Where You Should Be
A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures from your own business, each with a target.
For this issue, the benchmark would look like this.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Key figures (stock, price, product, customer) | Known to be wrong, not traced | Each traced to the rule, join or manual step that produces it | The specification |
| The rules that change those figures | In old code nobody has read | Written down in plain words, confirmed by your own people | The specification |
| The causes of wrong figures | ”The data is bad” | Each listed, and marked as in the system or on the shop floor | The risk register |
| Disagreement between systems on a key figure | Noticed, never measured | Measured by your own staff on a sample they choose, and falling as each part is rebuilt | Your staff’s own count, reported at every review |
| A verdict on each cause | Every error corrected the same way | Each marked rebuild, leave, or for the shop floor, agreed with you | The staged plan |
The starting points above are what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a retailer.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the figures you trust least. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the code your firm built or had built that changes stock, price, product and customer figures, and the joins between your systems. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the part that produces a wrong figure, rebuilt beside the old system on technology that is still supported, with checks at the point of entry. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.
The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.
What we do not do: we do not clean, correct, merge or reconcile records, and we do not count stock; your own people do. We have no data-quality product, and we do not examine customer or stock records. Inside another supplier’s packaged product we see only what goes in and comes out, and we do not install, upgrade or move packaged shop platforms or packaged ERP products. Errors that begin on the shop floor are untouched, and nothing here blames the people in your stores. We do not host or secure your systems. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a retailer.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | A wrong number has a known cause and an owner, and meetings stop opening with a dispute over whose figure is right. |
| CTO or CIO | A traced path for each key figure, from where it is entered to where it is reported, showing the rule or join where it goes wrong. |
| CFO | A variance in stock value or margin has a cause that can be named, not only a correction that is posted. |
| COO | Operations can tell which errors come from the system and which from the floor, and sends counts and training where they will help. |
| Head of marketing | Marketing knows which product and customer data can be trusted in a campaign today, and which cannot yet. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| After a large retailer’s packaged ERP roll-out in Canada in 2013, “only about 30% of the data in the system was actually correct”. | Our part is far narrower than this case. We do not implement packaged ERP products, we do not clean or move data, and we do not say why that data was wrong. For systems a retailer built or had built, we read the code and trace where a wrong figure is made. |
| A large retail and hospitality group said of its ten-year-old in-house system: “Before, we didn’t have access to real-time data visibility.” | Our part is narrower than this case. We read an in-house system and write down how and when each figure moves through it, so a firm can see where information arrives late or changed. We do not supply a replacement product or correct the data. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start with where the wrong number is made, because that is the part a clean-up never reaches.