AI agents belong around an ERP, not above it: they read and write through the ERP's APIs, do the interpretation the ERP cannot do — reading documents, matching records, investigating discrepancies — and post their results back so the ERP remains the single source of truth. The agent supplies judgment; the system of record keeps custody of the facts. Get that division of labour right and agents remove a great deal of manual work around the ERP. Get it wrong — agents keeping their own version of the truth, or acting through screen-scraping — and you have built a second, less trustworthy system of record that will eventually disagree with the first.
This matters because in most mid-market operations the ERP (and its cousins — the CRM, the WMS, the accounting platform) is where reality is kept: what was ordered, received, invoiced, paid. Yet an enormous amount of daily labour happens in the gap between that system and the messy world feeding it — the supplier's PDF invoice, the emailed order amendment, the delivery note photographed at the gate. That gap is exactly where agents earn a place, and the broader case for them is set out in the pillar on AI agents in operations. This article is about the specific discipline of deploying them against a system of record.
Should agents use APIs or screen-scraping?
APIs, without serious exception. The older generation of automation — RPA bots driving the ERP's user interface, clicking where a human would click — was built for systems that offered no other door. It works until the vendor moves a button, and it acts through a channel designed for humans, which means its actions are hard to scope, hard to log distinctly, and hard to distinguish from a person's. The contrast between that model and agentic automation is drawn fully in AI agents versus RPA.
An agent integrated properly gets a service account of its own, with permissions cut to exactly the transactions it is allowed to touch — read purchase orders and goods receipts, create draft invoices in a staging state, and nothing else. Posting through the API means every entry passes the ERP's own validations (valid vendor, open period, matching currency) and lands in the ERP's audit log under the agent's identity. When something goes wrong, you can answer the only questions that matter: what did the agent do, when, under what authority, and against which records. A scraped UI answers none of them.
The same principle covers writes. An agent should write to the states the ERP already provides for unconfirmed work — draft documents, staging tables, parked entries — and let confirmation happen through the ERP's own posting step. The agent proposes; the system of record disposes.
What are the real use cases: matching and reconciliation
The highest-value agent work around an ERP is not exotic. It is the matching work that consumes accounts payable, procurement, and finance teams every day.
Three-way match. Purchase order, goods receipt, supplier invoice: three documents that should agree and frequently do not — quantities split across deliveries, prices changed since the PO, freight appearing on the invoice from nowhere, units of measure that differ between the supplier's document and the item master. The ERP can auto-match the clean cases; everything else falls out to a person. An agent is well suited to that fallout: it reads the invoice, pulls the PO and receipt from the ERP, works through the discrepancy — is this a partial delivery against line three, a tolerable price variance, a duplicate? — and either prepares the match for posting or escalates with its reasoning attached. The person who once assembled the puzzle now reviews a solved one.
Reconciliation. Supplier statements against the ledger, bank lines against open invoices, intercompany balances that refuse to agree. The work is the same shape: two lists that should correspond, differences that each need a small investigation. Agents can propose matches, chase the obvious explanations (timing, partial payment, currency rounding), and leave a person a short list of genuine exceptions instead of a spreadsheet of hundreds of rows. Across a supply chain, the same pattern extends to order confirmations, ASNs, and delivery documents — territory covered in AI in supply chain automation.
In both cases the economics are the ones that always govern document-and-data work: the cost was never the typing, it was the checking and correcting, as laid out in the cost of manual data entry. Agents attack exactly that layer.
Why master data hygiene comes first
An agent matching against the ERP is only as good as what the ERP holds. Master data — vendors, customers, items, price lists, units of measure — is the reference the agent resolves everything against, and in most real systems it is quietly dirty: the same supplier entered three times with three spellings, items described in free text, conversion factors that stopped being true two packaging changes ago.
Dirty master data does not make an agent slightly worse; it makes it wrong in the worst way — confidently. An agent asked to match an invoice from "Gulf Trading LLC" against a vendor master containing "Gulf Trading L.L.C.", "Gulf Trdg", and "GULF TRADING CO" will either drown you in exceptions or pick one, and the failure will surface weeks later as a payment against the wrong account. No prompt fixes this, because the ambiguity is in the data, not the model.
The practical sequence: before connecting an agent, clean the specific master data it will touch — deduplicate the vendors involved, standardise the units on the items in scope, fix the mappings the matching logic depends on. Then give the agent a standing rule: where master data is ambiguous, stop and flag, never guess. A useful side effect is that agents make data debt visible — every ambiguity becomes a logged exception with a named cause, which is a better clean-up backlog than any one-off audit.
Whose authority does the agent act under?
Every ERP-centric organisation already has a delegation of authority: who may approve a purchase at what value, who releases payments, who can change a price. Agents must be mapped into that structure, not around it. The clean rule is that an agent's autonomy must fit inside the authority of the human it works for — it can prepare anything, but it confirms only what falls within thresholds a named person has delegated, and everything above flows to that person for approval, exactly as it would today.
Concretely, this means the approval workflow the ERP already runs stays intact, with the agent as the preparer feeding it: matched invoices below the auto-approval threshold post; everything else arrives in the approver's queue with the agent's working attached — what matched, what did not, what it recommends. Approvers approve faster because the assembly is done, but the signature is still theirs. Placing those thresholds, and enforcing them in the workflow so they cannot be skipped on a busy day, is the substance of agent guardrail design. What you must not do is let the agent's limits drift upward informally because "it has been right for months" — authority changes should be as deliberate as they would be for a person being promoted.
Why the ERP stays the source of truth
The temptation, once agents work well, is to let intelligence accumulate outside the system of record — the agent's own database of "what we know about this supplier", corrections applied in the pipeline but never posted back, a parallel picture of open orders that is fresher than the ERP's. Resist all of it. The moment two systems both claim to know the truth, someone must reconcile them, and you have recreated — at higher cost — the exact leakage you set out to remove.
The durable arrangement is strict: the ERP holds every fact of record; agents hold nothing durable except logs of their own actions. If an agent learns something true — a corrected bank detail, a resolved duplicate, an updated conversion factor — the destination for that truth is the ERP, through the governed change process, not a sidecar store. Agents read fresh, act through the API, and forget.
Held to that discipline, agents do not threaten the ERP-centric operating model; they complete it. The system of record was always good at keeping facts and enforcing rules, and always blind to the unstructured world outside its forms. Agents give it eyes — reading, matching, investigating — while the ERP keeps doing what it has always done: being the one place where the truth lives.