How finance teams run AI agents on top of SAP, Oracle, NetSuite, or Dynamics: integration patterns, approval gates, audit trails, and where to start.
Most finance teams that want AI agents already have an ERP they spent years configuring. The ledger, the chart of accounts, the approval hierarchy and the audit history all live there. Replacing it just to get automation would mean a multi-year project with a long payback, and it isn't necessary.
The ERP stays the authoritative System of Record (SOR) for balances, vendors and postings. The agent does the coordination work that currently happens between these systems: chasing a missing receipt, matching an invoice that arrived as a PDF, checking a contract before a purchase order goes out, or explaining a reconciliation break.
An invoice arrives by email. The purchase order sits in the ERP. The receipt lives in procurement software. Approval happens in a chat thread, and the final entry goes back into accounting. Every one of those systems may have its own automation, and a person still carries the case from one to the next.
An agent overlay takes on that handoff work. It's also why the ERP vendors' own AI features cover only part of the job: they work best on data already inside the ERP, and the messy inputs usually arrive from outside it.
Every major ERP vendor now ships its own finance agents, and they are worth evaluating first because they come with your existing licence and data model:
If your process starts and ends inside one ERP instance, a native agent may be enough. The gap appears when the process spans several ERPs after an acquisition, depends on supplier portals with no API, or needs context from contracts, inboxes and spreadsheets that the ERP never sees.
The design choices below decide whether an overlay is safe enough for a controller to sign off on.
Start with the agent reading ERP records and assembling cases: the invoice, the PO, the receipt, the vendor master entry. Write access comes later, one permission at a time. Zamp's operating model separates permissions into read, propose, attach, comment, update, submit, post and release, and grants them separately rather than as one broad role (see AI for finance operations).
An agent can reach an ERP through:
Test every action the job needs before trusting an integration. A connection can read records and still fail to attach a document, select the right entity or confirm a posting.
Cases outside policy, above a threshold or below a confidence level pause for a named reviewer before any write. The reviewer should get the source records, the agent's findings, the rule applied and one specific decision to make.
Every case should record what the agent saw, checked, decided, attempted and changed, plus the approval state at each step. After each write, the agent reads the record back from the ERP and compares the actual state with the expected one. In one Zamp procurement deployment, the agent writes its full reasoning for each decision directly inside SAP Ariba, so reviewers can check it where they already work (case study).
Give each agent its own identity rather than a shared human login, and keep preparing, approving, posting, changing vendor master data and releasing payments as separate permissions. The same segregation of duties rules that apply to your staff should apply to the agent.
Approach | Where it runs | Strengths | Limits | Best fit |
|---|---|---|---|---|
ERP-native AI agents (SAP Joule, Oracle Fusion agents, NetSuite SuiteAgents, Dynamics 365) | Inside the ERP | Uses the ERP's data model, roles and licence; no new vendor | Limited reach outside that ERP; multi-ERP estates need one per system | Processes that start and end inside a single ERP |
RPA bots | On top of screens | Mature tooling, works without APIs | Breaks when screens or document layouts change; no judgment on exceptions (AI agents vs RPA) | Stable, high-volume, rules-only steps |
Standalone AP or close tools | Separate SaaS that syncs to the ERP | Deep features for one function, fast to deploy | One function each; exceptions still move between tools by hand | A single well-defined function such as invoice capture |
AI employee overlay (for example, Zamp) | Beside the ERP, across systems | Owns a full job across email, portals, documents and one or more ERPs; approval gates and audit trail built in | Needs a defined job, a process owner and scoped access before it adds value | Cross-system jobs with many exceptions, multi-ERP estates |
Many teams combine them, using native ERP agents for in-ERP tasks and an overlay for work that crosses system boundaries.
Two Zamp deployments run this way, with no system replaced:
Data location often decides the shortlist. Zamp runs as multi-tenant SaaS, inside the customer's own cloud (BYOC) on AWS, Azure or GCP, or fully on-premises, and the integration options are the same in all three (deployment models). For teams with data-residency rules, BYOC keeps ERP data inside infrastructure they already control.
Skip the overlay if the process has no owner, the policy is disputed, the agent cannot reach the source records, or nobody can verify the output without trusting the agent's own summary. Fix the process or choose a narrower job first. If the whole job lives inside one ERP and the vendor's native agent covers it, start there.
For the full operating model behind finance agents, read AI for finance operations. For AP specifically, see AI agents for accounts payable, and for close work, see automated reconciliation.
