The Hidden Cost of Messy ERP Data

Because AI is a data problem before it is a tool problem, and most teams discover that in the wrong order. They pick a model, build a slick demo on a handful of clean records, and it works. Then they point it at the real ERP and the answers fall apart. It's a recurring pattern in why AI projects fail in the last mile: the build is fine, but the ground it stands on is shaky.

The model does not clean anything. It reads what's there. If a vendor exists under three spellings, a spend query returns three partial numbers. If half your records are missing a cost centre, any analysis that groups by cost centre silently drops them. The AI doesn't warn you. It answers confidently, in seconds, and the speed is the danger, because nobody re-checks a fast answer.

So the failure isn't the technology. It's pointing good technology at bad data and trusting the output.

It's rarely one dramatic problem. It's a thousand small ones that compound.

• Duplicates. The same customer, vendor, or item entered several times under slightly different names.
• Blank required-for-analysis fields. Categories, tax codes, cost centres, and regions left empty because they weren't mandatory at entry.
• Inconsistent categorisation. The same kind of item filed under three different categories by three different people.
• Free-text where structure was needed. Notes fields holding data that should have been its own field.
• Stale records. Closed accounts, old prices, and former contacts never archived.

None of these break the ERP. They quietly break anything you build on top of it, AI included.

This is common. A Harvard Business Review study of real corporate data found that only 3% of companies' data meets basic quality standards, so the messy ERP is the norm. The cost is hidden because it never appears as a line item. It shows up as second-order damage. AI initiatives that get scoped, half-built, and quietly shelved when the output can't be trusted. Reports that two teams reconcile by hand every month because the system numbers disagree. Decisions made on segmentation that drops a third of the records. Time spent arguing about whose number is right instead of acting on it.

For finance and operations teams this often runs to a few hours a week per person in pure reconciliation and cleanup, plus the larger opportunity cost of automation projects that never ship. The dollar figure is real, it's just spread thin enough that nobody owns it. If you want to put a number on the upside of fixing it, our AI business case generator frames the saving against the cost to build. That's why messy data persists. It's expensive in aggregate and cheap-looking in any single instance.

You assess it against the specific workflow. "Is our data clean" has no answer. "Is our vendor and bill data clean enough to automate three-way matching" does.

Walk the records the use case touches and check the basics: how many duplicates, how many blank fields the logic depends on, how consistent the categories are. Our data readiness for AI tool turns that into a score so you know whether to build now or clean first.

Here's the honest caveat. Sometimes the assessment says your data isn't ready, and the right move is to delay the AI project and fix the data. That feels like a setback. It is cheaper than building on sand and watching the project fail in production. Clean the slice the workflow needs, then automate that slice. You need the part the agent touches to be trustworthy. That's a far lower bar than a perfect ERP.