ERP data readiness is the difference between an AI agent pilot that proves value quickly and one that spends its first month raising exceptions about your own records. Most finance teams assume the hard part of a pilot is the model, but agents usually stall on duplicate vendors, a chart of accounts that grew without rules and supporting documents that are incomplete or unreadable. This article sets out the specific master data, chart of accounts and document problems that block agents, how to test for them on real transactions, and which fixes are worth doing before a pilot rather than after it. It closes with a finance data quality checklist and implementation steps you can run against a single process.
1. What is ERP data readiness for AI agents?
ERP data readiness means your transactional and master data are consistent, complete and explainable enough for an agent to act on them without guessing. A human AP clerk knows that 'Gulf Star Trading LLC' and 'Gulf Star Trdg' are the same supplier, that one particular travel account is the one people actually use, and that the second PDF attached to an invoice is the corrected version. An agent has to infer all of that from the data, and every inference it makes is a decision someone may later need to audit.
The standard is stricter than reporting readiness. A dashboard can tolerate a few mapping errors because people read it in aggregate and query the outliers. An agent posting accruals, matching invoices or proposing a payment run works at record level, one decision at a time. A wrong cost centre on a single line becomes a wrong posting that someone has to find and reverse. That is why readiness should be judged against the specific process the agent will run, rather than against an abstract quality score for the whole ERP.
2. Vendor master data quality: where most agent pilots stall
Vendor master data quality is usually the first problem an accounts payable or procurement agent exposes. The faults are predictable: the same supplier created several times under slightly different names, tax registration numbers missing or stored in a free-text field, bank details changed without a documented approval, and inactive vendors that were never blocked. Each one forces the agent either to stop and escalate or to make a match it cannot fully justify. Neither outcome builds confidence in the pilot.
Take a distribution group with entities in Dubai and Riyadh that maintain separate vendor records in the same ERP. One logistics provider appears four times: twice with a VAT number, once with an old bank account and once flagged as a one-time vendor. An AP invoice verification agent asked to match an incoming invoice has to choose between them. Until those records are merged, or linked to a single golden record with the others blocked, every invoice from that supplier becomes an exception for a person to clear.
Master data cleansing does not need to cover every vendor before a pilot. Rank suppliers by invoice volume over the past year and clean the ones that carry most of the traffic for the in-scope entities. Check for duplicates on tax number, bank account and normalised name, complete mandatory fields, block dormant records and confirm who approves bank detail changes. Customer records deserve the same treatment for any collections or cash application work, particularly payer hierarchies and parent-child links between accounts.
3. Chart of accounts rationalisation: a structure agents can reason about
A chart of accounts that has grown for a decade without governance is a quiet but serious blocker. Typical symptoms include several accounts with near-identical descriptions, accounts opened for a single project and never closed, suspense and miscellaneous accounts carrying real balances, and local charts mapped inconsistently to the group chart. People compensate with experience. An agent proposing a GL code for a non-PO invoice will spread its choices across the duplicates, and reviewers will spend the pilot correcting coding instead of testing the workflow.
Chart of accounts rationalisation for a pilot is narrower than a full redesign, and a full redesign is rarely worth doing just to start one. Focus on the accounts the in-scope process touches. Write a plain-language usage rule for each, merge or block obvious duplicates, clear and restrict suspense accounts, and confirm the mapping from each local chart to the group chart. Those usage rules matter more than teams expect: they become the instructions the agent follows and the reference an auditor checks its decisions against.
Groups with several entities feel this most. Where intercompany accounts are not mirrored between entities, or counterparty codes are missing from postings, an agent cannot pair the two sides of a transaction with confidence and falls back on amount and date. Dimensions carry the same risk: if a department code means one thing in the UK entity and another in Saudi Arabia, any agent producing spend analysis compares unlike with unlike. If intercompany is on your roadmap, the counterparty mapping covered in our article on intercompany reconciliation automation should start alongside the chart work.
4. Document data quality: the evidence agents read
Agents do not only read ERP tables. They read invoices, delivery notes, contracts, remittance advices and bank statements, and document data quality decides how much of that reading can be trusted. The problems are physical as much as digital: low-resolution scans, multi-page PDFs with several invoices merged, handwritten delivery notes, Arabic and English on the same page, and attachments named 'scan001'. Current extraction handles bilingual documents and messy layouts far better than older OCR, but it cannot recover a purchase order number the supplier never printed.
Part of the fix sits upstream. Ask your largest suppliers to quote the PO number and send one invoice per file, ideally through a structured channel; in Saudi Arabia, ZATCA e-invoicing is already moving many suppliers towards structured electronic invoices. Inside the business, make sure goods receipts are posted when delivery happens rather than in a batch at month end, because an agent reviewing three-way match exceptions needs the receipt to exist when the invoice arrives. Then check that each supporting document is linked to its transaction in the ERP instead of sitting in a shared mailbox.
5. How do you run a data readiness assessment before a pilot?
A useful data readiness assessment takes weeks rather than a quarter, and it is scoped to one process and a small number of entities. Pull a recent period of real transactions, for example a few months of supplier invoices for two entities, and run them through the checks the agent would perform. Record how many fail on a missing or duplicate vendor, an ambiguous account, a missing receipt or an unreadable document. That failure profile tells you exactly what the agent would escalate, which no generic quality score can.
Classify each failure by owner and by fix. Some belong to the master data team, some to procurement, some to suppliers, and some are process gaps such as late goods receipts. Then decide what must be fixed before go-live, what can be fixed during the pilot with the agent flagging it, and what is acceptable as a permanent exception routed to a person. If you want an outside view of where your organisation stands before choosing a process, a short AI readiness assessment can help frame the decision.
Where data sits in several ERPs, or in an ERP plus spreadsheets, decide whether the agent should read directly from each source or from a governed data layer holding the cleaned and mapped version. For a single-entity pilot on one ERP, direct access is usually fine. For a group running SAP in one region and Dynamics 365 or NetSuite in another, a shared model on a platform such as Microsoft Fabric stops each agent re-solving the same mapping problems and gives auditors one place to trace what the agent saw.
6. What not to fix first, and where agents help with clean-up
Not every data problem deserves attention before a pilot. Transactions from closed periods rarely matter unless the agent needs them for pattern matching, and perfect descriptions on low-volume vendors will not change the result. A common mistake is launching a broad master data programme and postponing the pilot until it finishes. Those programmes lose momentum because nobody can see what the clean data is for. A narrow fix tied to one agent and one process produces visible results and a reason to keep going.
Agents can also sustain ERP data readiness once they are running. A well-designed agent records why it escalated each item, so the escalation log becomes a prioritised list of defects: duplicate vendors found during matching, accounts used against their rule, documents missing references. The agent proposes the merge or correction, and a named person approves it in the ERP. Every AITHENTIC agent works this way, with a defined role, decision rights, escalation logic and a full audit trail, and people approve exceptions. The data improves because the daily work keeps exposing it.
Key challenges
- Duplicate and incomplete vendor and customer records that force agents to escalate or guess.
- Charts of accounts with overlapping, undocumented and suspense accounts that scatter GL coding.
- Inconsistent dimensions and intercompany mappings across entities and ERPs.
- Poor-quality or unlinked supporting documents, including scans without PO references.
- Process gaps such as late goods receipts that leave correct data arriving too late for the agent.
The framework
A practical operating model is Scope, Sample, Sort, Fix, Monitor. Scope the pilot to one process and a few entities, and list the master data objects, accounts and document types that process depends on. Sample a recent period of real transactions and run the agent's intended checks against it. Sort every failure by owner and by whether it must be fixed before go-live, during the pilot or accepted as a routed exception. Fix the pre-go-live items with named owners and account usage rules written in plain language. Monitor through the agent's escalation log once live, treating repeated escalations as data defects to correct at source rather than work around.
How to implement it
- Choose one process and two or three entities, and list every master data object, GL account and document type it touches.
- Extract a recent sample of real transactions and test it against the agent's intended checks, recording each failure reason.
- Deduplicate and complete the high-volume vendor or customer records, block dormant ones and confirm the approval route for bank detail changes.
- Write a usage rule for every in-scope GL account, block duplicates and restrict suspense accounts.
- Ask major suppliers for PO references and one invoice per file, and ensure receipts and documents are linked to transactions in the ERP.
- Log every agent escalation from day one and review the log weekly as a data defect backlog with named owners.
Frequently asked questions
What is a finance data quality checklist for AI agents?
It is a set of checks across four areas: master data, chart of accounts, documents and process timing. Test vendors and customers for duplicates and missing tax or bank fields, accounts for duplicates and unclear usage, documents for legibility, references and links to transactions, and processes for receipts and approvals recorded when they happen. Running a real transaction sample against these checks is the fastest way to find the gaps.
How long does ERP data readiness take before an AI pilot?
For one process and a few entities, ERP data readiness work can usually be scoped in a few weeks, with critical fixes completed before the pilot starts. The timeline depends on how many duplicate records exist, how far the chart of accounts has drifted and whether suppliers can change how they send invoices. A group-wide master data programme takes much longer and should not hold up a focused pilot.
Do you need to clean all master data before deploying AI agents?
No. Clean the records the in-scope process actually uses, starting with the highest-volume vendors or customers and the GL accounts that process posts to. Closed-period history and low-volume records can wait. Once agents are live, their escalation logs show which remaining defects matter, so clean-up continues in priority order instead of running as a separate programme that loses momentum.
Can AI agents clean ERP data themselves?
Agents can find defects and propose fixes, but people should approve changes to master data. An agent can flag a likely duplicate vendor, suggest the correct account for a miscoded line or note a missing PO reference, with the evidence attached. A named person then approves the merge or correction in the ERP, which preserves the audit trail and segregation of duties, especially for sensitive fields such as bank details.
