AI Agents in ERP Systems

The ERP handles the rules. People handle the rest.

An ERP is very good at the happy path. An order with a known customer, a price from the price list and stock in the warehouse flows straight through. The trouble is everything else: the invoice that does not match the purchase order by two pounds, the goods received note entered against the wrong line, the customer on credit hold who has just paid. Each lands in an exception queue, and those queues are where finance and operations teams spend their days.

That is where AI agents fit inside ERP systems. Not replacing the ERP, and not chatting on top of it for the sake of a demo, but working through exceptions that need someone to look in three places and make a sensible judgement.

Exceptions agents handle well

• Three-way match failures. Invoice, purchase order and goods receipt disagree. The agent finds the cause: partial delivery, price change, unit of measure, a duplicate.
• Unapplied cash. A payment arrives with a vague reference. The agent matches it to open invoices using amounts, remittance emails and customer history.
• Order holds. Credit or pricing holds where the agent gathers the facts the credit controller needs to release or keep the hold.
• Stock discrepancies. Counts that disagree with system stock. The agent traces recent movements and suggests the likely error.
• Master data problems. Duplicate customers, suppliers with inconsistent details, items missing attributes.

Take a distributor with 2,000 supplier invoices a month where a tenth fail matching. At ten minutes each, that is over 30 hours a month of investigation. An agent that resolves the obvious ones and hands over a clear explanation for the rest makes a visible dent, even if a person still approves every correction.

Read widely, write narrowly

The design principle that keeps ledgers safe is to give the agent broad read access and very narrow write access.

All writes go through the ERP's own API or business logic, so the ERP's validations, period locks and audit trail still apply. We never let an agent write to ERP database tables directly. It bypasses the rules the ERP exists to enforce.

Which ERPs this works with

Most modern cloud ERPs, including the platforms mid-sized UK and US businesses commonly run, expose APIs good enough for an agent to read transactions and create draft documents. Older on-premise systems vary: some have usable APIs, some only database access, some only screens. Our guide to AI integration with ERP systems covers the integration options by type.

Many ERP vendors also now ship their own built-in assistants and agents. They are worth trying first for tasks entirely inside the ERP. A custom agent earns its place when the investigation crosses systems, such as the ERP plus email, a warehouse system and a bank feed, or when the process is specific to your business.

A realistic rollout

1. Pick one exception type with high volume and clear resolution rules, usually invoice matching
2. Pull six months of resolved exceptions and how they were resolved, which becomes the evaluation set
3. Build read-only tools and an agent that explains the likely cause, with no write access at all
4. Measure how often its explanation matches what the team actually did
5. Add draft corrections for review, and track how often reviewers accept them unchanged
6. Allow automatic posting only for narrow, low-value categories with strong evidence, and keep it reversible

Steps three and four often deliver most of the benefit. An accurate explanation attached to every exception halves the time spent investigating, before the agent has changed a single figure.

Controls finance and auditors will ask about

• Segregation of duties: the agent's service account must not both propose and approve
• A complete log of what the agent read, what it proposed, who approved it and when
• Period-end behaviour, so the agent does not draft entries into closed periods
• Materiality thresholds that force human review above a set value
• Regular sampling of approved agent corrections by someone independent

Build these in from the first release. Retrofitting them after an auditor asks is slower and more awkward. The wider governance picture is in our post on AI governance and compliance.

When not to put an agent in your ERP

If exception volumes are low, a well-organised queue and a clear procedure will serve you better. If your ERP data is badly inconsistent, an agent will reason confidently over bad data, and a data clean-up is the right first project. And if the ERP is due to be replaced within a year, build the agent against the new system rather than the old one.

At SpiderHunts we tend to begin ERP agent work with a two-week look at exception data before proposing anything, because the numbers usually point to the right starting point. Larger multi-entity deployments sit within our enterprise AI work, and the purchasing side connects with agents for purchase approvals.

Frequently asked questions