Your AI CFO is only as good as your ERP master data

An open wooden card-index drawer on brass runners, full of blank cards, with a brass magnifying glass resting on top in amber light

Ask a controlling model which customers are slipping on payment and it will answer confidently. Then someone in credit control notices that the third-largest customer on the list is the same company as the seventh: one record created by sales years ago, another created by a branch office when the customer opened a second site. Same VAT number, different payment terms, different credit limits. The model was not wrong about the data. The data was wrong about the company.

Every AI system that reads an ERP inherits its master data — customers, suppliers, products, cost centres, the chart of accounts and the mappings between them. Transactions are usually in reasonable shape, because they come out of processes with controls around them. Master data comes out of whoever needed a record that day, and it decays quietly.

The real cause: nobody who creates the mess feels it

The person who creates a duplicate customer does not suffer from it. Sales needed to issue an invoice and the record let them. The cost lands months later, in a controller’s reconciliation or in a forecast that splits one customer’s behaviour across two records and gets both wrong.

Reporting tolerated this because people patched it on the way. The controller knows those two records are one company and adds them up in the spreadsheet. A model does not know what the controller knows unless someone writes it down — so automating the analysis removes the person who was silently correcting the master data every month.

The failures that matter most

Duplicate business partners. One legal entity under several records, often with different terms, limits or currencies. Payment behaviour, exposure and concentration risk all get split, and all get understated.

Cost-centre drift. A reorganisation moves teams between cost centres mid-year and history is not restated. Every year-on-year comparison now mixes a structural change with a performance change, and a model will happily explain the structure as performance.

Product hierarchies that change under the data. A product moves to another group, or a new item code replaces an old one with no link between them. Volume collapses in one line and appears from nowhere in another.

Catch-all accounts. “Other operating costs” quietly grows to hold a meaningful share of spend. Whatever lands there is invisible to any analysis built on drivers.

Free text where a field should be. Supplier names in a description, project codes in a memo line, payment terms in a note. A model can parse free text. It cannot make it consistent after the fact without guessing, and guessing is how trust in a finance system dies.

Missing intercompany partner codes. In a group with several entities, flows without a partner code cannot be eliminated reliably, and the consolidated numbers carry noise nobody can trace.

What to do instead

Clean master data is not a project you finish before AI arrives. It is a loop of its own.

  • Make the system surface master-data problems, not hide them. “These two records share a VAT number” is a finding in its own right, reported with the evidence — not something to merge quietly. Merging is a decision for the person who owns the record.
  • Keep a mapping layer beside the ERP. Where the structure changed — a reorganisation, a new product hierarchy — keep an explicit mapping from old to new so history can be compared like for like. Analysis reads through the mapping; the ERP stays untouched. It is one more reason read-only connectors make sense: corrections live beside the books, never inside them.
  • Match on identifiers before names. Tax IDs, company-register numbers and bank account numbers are far more stable than names typed by people.
  • Give each master-data class an owner. Customers, suppliers, products, cost centres. Not a governance committee — one named person who sees the findings every week.
  • Log every correction. If a forecast changed because two customers were treated as one, the explanation should say so. It is the lineage discipline set out in what EU AI rules mean for a finance model: every number traceable to its source and to every rule applied on the way.

There is a sovereignty angle too. Master data holds your customer list, your supplier terms and your pricing structure in their most compact form. Cleaning it with a hosted service means exporting exactly the dataset a competitor would most like to read — the argument made in why financial data should never leave the building.

A test you can run today

Export your customer master with tax identification numbers and count how many tax IDs appear on more than one active record. Then do the same for suppliers.

If the answer is zero, check that the field is actually filled in. If it is more than a handful, take the largest pair and compare their payment terms, credit limits and last year’s payment behaviour side by side. That comparison is a preview of what any model would get wrong about that customer. It is also the cheapest data fix you will make this year, and the kind of finding ObserBI is being built to surface on its own, every night, before it turns into a wrong forecast.