Data Issues

1. At a Glance

Issue study · From the public record. No organisation is named here. Everything about it comes from the public record.

Organisation type	Manufacturers whose stock and production figures cannot be relied on: a large US food manufacturer as the main case, beside surveys and a report from India
Size band	The firm in the record: large. Our reader: a mid-size manufacturer whose stock, production and dispatch programs were built in-house or by a partner, beside a packaged ERP
Region	The main case: the US. One report from India. The EU rule: EU importers, reaching Indian exporters through their buyers
The decision at stake	Whether to go on counting and correcting figures that drift again, or to find and fix the parts of the firm’s own programs that make them wrong, before a new system or an AI project is built on them
The public outcome	After its move to a new ERP system, the food manufacturer reported that it could not see its finished stock at its warehouses, and estimated that this cost it more than 100 million US dollars in sales in 2024
Why it matters to a mid-size manufacturer	When a business cannot rely on what its system shows, the cost lands in orders not filled, and every later project starts from the same figures

2. The Business Problem, in the Buyer’s Words

“We close the plant for two days every March and count everything. For a few weeks the figures are good. By May the planners are walking to the stores again before they promise anything, and each of them keeps a list of their own. The stores do what the screens tell them, and I believe them. Now we are asked about an AI project, and a new system after that, and both will start from these figures. I do not need another count. I need to know where the wrong numbers come from.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm is caught between counts that do not last and projects that cannot start until its figures can be relied on.

3. What We Found

Method. 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, one survey on why firms keep old systems, and the European Commission’s pages on its carbon border rule.

A firm that could not see its finished stock. A large US food manufacturer moved to a new ERP system. The figures are from the company’s own filing in 2024.

What	Public record
What the company reported	It could not see its finished stock at its warehouses
What the company tied the loss to	Orders it could not fill
Effect on sales	More than 100 million US dollars in sales in 2024, by the company’s estimate
Period	2024
Why it happened	Not examined by us; we draw no cause from the record

This is about stock that could not be seen, not figures that were wrong. It is the one public account of what it costs a manufacturer not to be able to rely on what its system shows.

What manufacturers say holds them back. 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.

What a report from India says. 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”, and that without that groundwork “a successful pilot might remain merely a pilot”.

Why firms hesitate to replace. 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.

A rule that asks importers to declare the emissions in their imports. The European Commission’s page on the rule (updated 26 June 2026) says that “the CBAM definitive regime applies from 1 January 2026”, and that “EU importers declare the emissions embedded in their imports and surrender the corresponding number of certificates each year”. It applies to importers of more than 50 tonnes of covered goods, which include iron and steel and aluminium. In its questions and answers of 17 December 2025, the Commission says: “If embedded emissions of goods, as calculated by a third country producer, are not verified by an independent verifier, the importers have to use default values.” For steel and aluminium those default values carry a mark-up of “10% in 2026, 20% in 2027, and 30% in 2028”, and “CBAM certificates will be sold only from 1 February 2027”. The Commission’s pages place these steps on EU importers, and do not mention India.

Our reading of why the figures go wrong, and stay wrong. These four are our reasoning from the record above and from how such programs commonly work. None is a finding of any source.

1. A figure passes through many rules, and nobody has traced it. Receipt, booking, issue, scrap and adjustment each apply a rule, some of them assumptions such as a standard recipe or an old unit conversion.
2. A count corrects records and leaves rules alone. The adjustment overwrites the clue, and the same rules run the next morning.
3. Entry screens accept what cannot be right. A slipped decimal or a booking against a closed order goes in unchallenged, or forces a workaround the people on the floor did not choose.
4. Data is carried forward without anyone knowing where it was made. A new system, an AI project or a buyer’s request is given whatever the old programs recorded.

Our reading of the EU rule, and only that: an Indian steel or aluminium exporter whose production and dispatch records cannot tie a batch to a shipment may find it hard to give its EU buyer figures for each shipment; where a producer’s figures are not verified, the Commission says, “the importers have to use default values”. Whether the rule touches a particular exporter is for that firm and its advisers. The part we would look at is the records: supplier data, and the trail from batch to shipment.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Count again, and count more often	The differences are small and nothing else waits on the figures	It is paid for every year, and the cause is still running	Right as a check; it is not a cure
Bring in a data-cleaning specialist	Years of records must be put right at once, and the causes are already fixed	If the rule that spoiled the records is still running, they drift again	Right after the causes are fixed, not before
Trace a wrong figure through the firm’s own programs to the rule or step that makes it	The same parts are short at every count, and nobody can say why	A trace corrects nothing on its own	The first half of our recommendation
Rebuild the points where figures are entered, with checks, one module at a time	The cause is known to sit in the firm’s own entry screens or programs	Without a trace first, the wrong screen may be rebuilt; a check that is too strict is worked around	The second half, once the trace has named the cause

5. Our Recommendation, and the Decision It Asks of the Board

For the stock, production and dispatch programs a manufacturer built or had built beside its ERP: trace the key figures through them first, from entry to report, in a written specification confirmed by the firm’s own people. Then rebuild the part that makes a figure wrong, one module at a time, with checks at the point of entry, while the old program keeps running. The firm’s own staff go on counting, and correct the records once each cause has gone. The packaged ERP, the machines and the counting are not part of this work.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the manufacturer’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Key stock and production figures	Known to be doubtful, not traced	Each traced from where it is entered to where it is reported	The specification
Rules that change a figure on its way	In the code and in people’s memory	Each written down: what it does, where it lives, what depends on it	The specification and the map of the system
The cause of each kind of difference	”The stores” or “the data”	Named: the rule, conversion or manual step that produces it	The specification and the risk register
Checks at the point of entry	An old screen accepts almost anything	Each rebuilt part refuses an entry that cannot be right, with the checks written down	The specification and the traceability matrix
The trail from batch to shipment	Not written down	Each step a batch passes through, from production record to dispatch, named	The specification
Places where the old data cannot be relied on	Found after go-live	Listed before any move, for the business to decide	The risk register
Disagreement between screen and rack on key parts	Noticed, never kept	Measured by your own staff on a sample they choose, before and after each part is rebuilt	Your staff’s own count, reported at every review

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the figures nobody trusts, the counts that do not last and the projects waiting on them. 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 study 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.
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, while your own staff correct the existing records. We never do a single cutover. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: where each key stock and production figure is entered, changed and reported in the firm’s own programs, and the rule applied at each step, confirmed by the firm’s own people.
• The risk register: what the assessment found, listed before any price is set, including rules that rest on an assumption and places where the old data cannot be relied on, listed for the business to decide.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• The code: the rebuilt modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT has no data cleaning, reconciling or migration service, and does not count stock. The manufacturer’s own people correct the records, and a count will still be needed.
• IOanyT’s terms on access cover a client’s code, not its stock, production or customer records. It reads the programs, not the records.
• IOanyT cannot see inside or change a packaged ERP product, and is not a partner of any ERP maker. Where a figure is made inside one, the manufacturer’s ERP specialist deals with it. The case in section 3 was a move to a new ERP system, so IOanyT’s part is far narrower.
• IOanyT does not connect to machines, read counts from them or work on plant control systems.
• Errors made on the floor, such as a miscount, a mislabelled bin or scrap that was never booked, are not caused by software and are not cured by it. Nothing in this study blames the people who work in stores or production.
• IOanyT does not measure or verify emissions, and gives no compliance, legal or tax advice. What the EU rule asks of an importer, or an importer of its suppliers, is for them and their advisers. Nothing here makes a firm compliant.
• IOanyT promises no level of stock accuracy and no result from AI.
• This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a manufacturer. IOanyT has no published case of this work for a manufacturer.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
Company filing, 2024	The main case: finished stock that could not be seen, and the quarter’s sales
An industry body’s survey of manufacturers, 2026	Barriers to AI
A market-data firm’s report of an Indian summit, 2026	Fragmented data in smaller and mid-sized Indian producers
A vendor’s survey of US IT professionals, 2025	Why firms hesitate to replace old systems
European Commission, CBAM definitive regime, updated 26 June 2026	Who must declare, from when, and the goods covered
European Commission, questions and answers, 17 December 2025	Default values, the mark-up, and the date certificates go on sale

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 a wrong figure is made, so that a count can check the cure instead of being it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →