Your finance team closed the books on Tuesday. The ERP had flagged the duplicate supplier invoice the previous Thursday — it just had no way to tell anyone and no authority to do anything about it. So the row sat there, correctly recorded and completely inert, until someone went looking.
That gap between knowing and doing is the whole pitch for agentic ERP.
A filing cabinet that finally answers back
For three decades ERP has been a system of record. You enter what happened, it stores what happened, and it produces reports about what happened. Excellent memory, zero initiative. Every action in the loop — chasing the approval, raising the PO, matching the payment — still runs through a person copying data from one screen into another.
Agentic ERP flips the direction. The system stops waiting to be asked. It reads the same tables it always did, notices the same exceptions it always could, and then actually does something: drafts the purchase order, routes it for approval, reconciles the line, escalates the one case it cannot resolve.
Same data. Different posture.
Fig. — Same ledger, different posture: recording versus acting on what was recorded.
What "agent" actually means here
The word is doing a lot of work in vendor marketing, so it is worth being precise. An agent is software that takes a goal, breaks it into steps, calls tools to execute those steps, and checks its own result — rather than following a fixed script someone wired up in advance.
The practical difference from the automation you already own: a workflow rule fires when condition X is true and does exactly Y, forever. An agent is handed "reconcile this statement" and works out the sequence itself, including the cases nobody anticipated when the rule was written.
That is the upside and the risk in the same sentence.
Where it pays for itself first
Start with work that is high-volume, rules-heavy, and quietly expensive.
Three-way matching is the obvious candidate. Purchase order, goods receipt, invoice — conceptually trivial, operationally miserable, because a meaningful share of the time something does not line up and a human has to work out why. An agent that clears the routine mismatches and escalates only the genuinely ambiguous ones drains most of that queue.
Procurement has the same shape. Stock dips below threshold, the agent checks the contracted supplier, drafts the order at the negotiated price, and puts it in front of whoever owns the budget. The person still decides. The typing disappears.
Month-end close is where finance teams feel it hardest. Most of the delay is not analysis — it is chasing accruals, hunting missing documents, and reconciling intercompany balances that refuse to match. Every one of those is a lookup-and-compare loop, which is exactly what an agent is good at.
None of this is exotic, and that is rather the point. The work is repetitive lookup, comparison and routing — the parts of finance done by people only because no software could hold enough context to do them safely. That constraint is the thing that changed, which is why the early wins tend to look boring rather than visionary.
The part nobody puts in the demo
An agent with write access to your general ledger is a new class of risk, and not a hypothetical one. Three questions need answers before anything touches production.
What can it do without a human? Draft-only is a genuinely different security posture from execute-and-notify. Most teams should start at draft-only and earn their way up, one process at a time, with evidence.
How do you audit it? Every agent action needs the same trail as a user action — who, what, when, under whose authority, and reversible. If your ERP cannot attribute a journal entry to an agent as cleanly as it attributes one to Priya in accounts payable, you are not ready.
What happens when it is confident and wrong? This is the failure mode that matters. A rules engine that breaks throws an error you notice. An agent that misreads an ambiguous invoice produces a plausible, well-formatted, entirely incorrect entry — and does it at machine speed across a hundred documents before anyone looks up.
Rate limits and human checkpoints are not friction. They are the design.
The prerequisite nobody wants to hear
Data quality decides whether any of this works. An agent reasoning over a master data file with four spellings of the same supplier will make four different decisions, each one confidently. Bolting agents onto a messy ERP does not clean it up; it industrialises the mess at speed.
So the honest sequence is unglamorous. Fix the master data first. Instrument one process end to end so you know what it currently costs in hours and errors. Then hand an agent that single process in draft-only mode and compare the numbers against your baseline.
Expect that comparison to be less flattering than the demo. A pilot that clears 70% of a queue and escalates the rest is a good result, not a disappointing one, because the 30% it declines to touch is where the expensive mistakes live. Teams that judge the first month on full autonomy usually conclude the technology does not work, when what they actually built was a pilot with no room to be careful.
If your ERP vendor ships this natively, take that path — the agent inherits the permissions model and the audit trail you already trust. On older systems the integration route means building both yourself, which is a real project rather than a plugin, and worth pricing honestly before you start.
Your ERP is getting agents either way. The question worth sitting with is which process you would trust one with first, and whether you could prove afterwards exactly what it did.
Wiring this kind of thing into a real stack is the sort of work we do at CODT.
