A Wrong Stock Figure Is Made Somewhere. Most Manufacturers Never Find Out Where.

A customer rings on Tuesday and asks for 350 of a bracket by Friday. The sales desk looks at the screen. There are 400 in stock. The order is accepted.

On Wednesday the picker goes to the rack. There are 310. The screen still says 400, and the line that makes the bracket is booked until next week.

On Thursday the managing director rings the customer to apologise. Then comes a familiar conversation. The stores say they issue what the system tells them. Production says it books what it makes. IT says the system adds up what it is given. All three are right.

What We Found

For this article we went through the public record on manufacturers and the figures their systems hold: a company’s own filing, a survey of manufacturers on what holds back their use of AI, a report of an industry summit in India, and one survey on why firms keep old systems.

When stock cannot be seen, the loss is counted in sales. A large US food manufacturer moved to a new ERP system. Afterwards, it reported in its own filing, it could not see its finished stock at its warehouses, which cost it more than 100 million US dollars in sales in 2024. This is a case of stock that could not be seen, not of figures that were wrong. We take one narrow point from it: when a business cannot rely on what its system shows, the cost lands in orders not filled.

Manufacturers name data as their first barrier to AI. In one survey of manufacturers, run by an industry body, respondents picked their top three barriers to using AI. Problems with data came first, named by about six in ten. The need to upgrade old equipment was named by about a quarter. The survey is about AI, not about stock.

In India, the barrier is described as fragmented data. A report of an industry summit held in Bengaluru in 2026 says that “smaller and mid-sized Indian producers encounter a deeper barrier: fragmented data, aging machinery, and a lack of standardized operating frameworks”. Without that groundwork, it says, “a successful pilot might remain merely a pilot”.

Data worries also hold back replacement. In one survey of about 500 IT professionals in the US, run by a firm that sells software services, about a third named concerns about moving data among their reasons for not replacing old systems. That survey covers every sector, not manufacturing alone.

Our reading goes one step further, and it is our reasoning, not a finding of any source. A stock figure is the sum of every receipt, booking, issue, scrap entry and adjustment since the last count, and each passes through a rule: a unit conversion set years ago, a standard recipe that takes components off stock when finished goods are booked, a step done by hand at the end of a shift. When one rule is slightly wrong, it makes the same wrong figure again and again. That is how everyone can be right and the figure still wrong. Some rules live in the packaged ERP, some in programs the firm built beside it, and some errors are made on the floor, where no program makes or cures them.

What Waits While Nobody Knows Where the Figure Goes Wrong

Unreliable figures are usually treated as a stores problem. Our reading is that they hold up much more than the stores.

The first cost is the count that never ends. A count corrects the records, not whatever made them wrong, so the same differences return.

The second is the promise that cannot be kept. Planners learn not to believe the screen, walk to the rack before committing to anything, and keep private lists.

The third is the project that cannot start: an analysis, an AI pilot or a new system is only as good as its figures.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Respond to a Wrong Figure, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Count again and adjust the system to the shelves	The difference has a known, one-off cause, such as a delivery booked twice	The count overwrites the clue, and whatever made the difference is still running the next morning
Tighten procedures in the stores	The differences trace to the floor: an unlabelled bin, scrap never booked	If the cause is a rule in a program, people are asked to fix something they did not make
Bring in a data-cleaning specialist	Years of records must be put right at once, before a move	The records are clean on the day the work ends; the rule that spoiled them is untouched
Trace a wrong figure through the firm’s own programs, then rebuild the part that makes it	The same differences return after every count, and the programs were built for the firm	It costs money before anything changes, part of the path may lie inside the packaged ERP, and a count is still needed

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own programs, each with a target.

Measure	Typical starting point	Where it should be	How it is checked
The path of each key stock and production figure	Known in pieces, to different people	Every point where it is changed written down, from entry to report	The specification
The rule applied at each point	In the code, and in people’s memory	Each written down in plain words, including conversions and standard recipes	The specification
Where each rule lives	Not known	Named: the ERP, one of the firm’s own programs, or a step done by hand	The specification and the map of the system
Rules that rest on an assumption	Not listed	Listed, with what depends on each, for the business to decide	The risk register
Differences between screen and rack	Adjusted away after each count	Kept by your own staff and set beside the rules that could explain them	Your staff’s own record, reported at every review

The starting points above are what the public record suggests and 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 manufacturer.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the figures nobody trusts and the programs they pass through. 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.
2. 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.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the stock, production and dispatch programs you built or had built beside your ERP, and the steps a figure passes through in them. 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.
4. 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 of your own programs that makes a figure wrong, rebuilt 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.
5. 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.

This approach has limits. A trace corrects nothing: your own people still count and adjust. We do not clean, correct, reconcile or migrate records, and we do not count stock. Our terms on access cover your code, not your stock, production or customer records. We cannot see inside or change a packaged ERP product, and we do not connect to machines. Some causes will be on the floor, where software does not help, and a count will still be needed. We promise no level of stock accuracy and no result from AI. We have no published case of this work for a manufacturer.

What changes for the business:

Role	What they gain
CEO	A wrong stock figure has a known cause and an owner, and a delivery promise rests on something that has been looked into.
CTO or CIO	A written path for each key figure, from where it is entered to where it is reported, showing the rule or step where it goes wrong.
CFO	A stock variance has a cause that can be named, and not only a write-off that is posted.
COO	Operations can tell which errors come from the programs and which from the floor, and sends counts and training where they will help.
Head of digital	Digital projects know which figures can be relied on 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 its move to a new ERP system, a large US food manufacturer reported that it could not see its finished stock at its warehouses, which cost it more than 100 million US dollars in sales in 2024.	Our part is far narrower. We do not install packaged ERP products or migrate data, and draw no cause from the record. For a manufacturer’s own programs, we write down where each figure is changed and rebuild the part that makes it wrong.

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 by finding where the wrong figure is made, because a count can only correct it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →