Running Accounts Payable and Receivable With Agents Inside Your ERP

Can AI agents actually run accounts payable and receivable inside SAP, Oracle, NetSuite, or Dynamics without breaking the sub-ledger? Yes, for the predictable majority — invoice capture, three-way match, cash application, remittance parsing, routine dunning — provided every write is idempotent, posting keys stay intact, and a person sits on every tier-two exception.

The interesting work is no longer document capture. It is the mapping between an agent's tool calls and the ERP's own posting, locking, and period-close rules, where a careless automation turns a $40,000 invoice into a duplicate payment and a tidy demo into an audit finding.

Where Agents Fit in the AP Flow

AP is six sub-workflows stacked on each other: capture, validate, three-way match, exception coding, approval, post. Each one has a different autonomy ceiling.

Capture and classification run fully autonomous once you have reliable vendor master data and a tolerable duplicate-detection hash. A three-way match agent compares invoice lines to the PO and the goods receipt inside a tolerance group — the pricing, quantity, and date tolerances defined per vendor class. When everything lines up, the agent posts through the standard BAPI or REST call that the ERP exposes and writes back the document number. When it does not, the agent routes the exception with structured context, not a screenshot.

Coding exceptions are the sub-workflow where vendors overpromise. Missing cost centers, blocked GL accounts, split-across-projects invoices — these need a retrieval layer over prior postings plus a rules engine. An agent that learns from the last twelve months of your postings resolves most of them, but the long tail is why AP is still the right first workflow rather than a solved one.

The ERP Mechanics Agents Must Respect

An agent that cannot read a posting key, a tolerance group, or a closed-period status will quietly corrupt the sub-ledger before anyone notices. Each ERP exposes these rules differently.

• SAP S/4HANA. Posting keys determine debit/credit side per line; tolerance groups gate auto-posting per user and per vendor; MM and FI period locks run on separate clocks. Agents post via MIRO / FB60 BAPIs, never by UI scraping, and check T001B before every write.
• Oracle Fusion / EBS. Invoice holds, distribution sets, and approval groups live in Payables; period status is per ledger and per module. Agents use the REST Payables Invoice API and respect the hold types before release.
• NetSuite. Vendor Bill records carry matching rules against the item receipt; closed periods are enforced per subsidiary. Agents call SuiteTalk or RESTlets and must verify the accounting period is open for the transaction date, not today's date.
• Dynamics 365 F&O. Posting profiles, approval journals, and vendor invoice workflows all route through the Data Management Framework. Agents should use the invoice journal entity, not direct SQL.

The common requirement across all four: the agent needs an idempotency key on every write (vendor + invoice number + line hash is the usual shape) so that a retry after a network blip does not re-post the same document. Without it, you get the duplicate-payment class of incident that ERP automation projects fail on.

45%

Feared layoffs in 2025

27%

Feared layoffs in 2024

69%

Expect positive automation impact

Where Agents Fit in the AR Flow

AR inverts the problem. The agent is reading unstructured remittance — PDFs, portals, emails, ACH addenda — and matching it against open invoices with partial payments, deductions, and short-pays. Cash application is the highest-value action because most middle-market AR teams still do it by hand, and 83% of firms have yet to fully automate the function, with mid-market firms losing an average of $19 million in annual revenue to delayed payments.

A cash application agent parses the remittance, matches at the invoice-line level, writes a receipt into AR, and codes the deduction with the right reason code (shortage, pricing dispute, promotion). When confidence is below threshold, it opens a dispute ticket with the matched candidates attached. Dunning agents segment by aging, promise-to-pay history, and credit risk, then send escalations that are different from the generic weekly email blast.

Three constraints keep the AR agent from going rogue. Credit limit changes stay human. Write-offs above a threshold stay human. Any change to a customer bank account is treated the same as an AP bank change, because the inbound-fraud attack surface is the same as the outbound one.

Approval Gates and Idempotent Writes

The architecture that separates a production AP/AR agent from a demo is the approval gate topology. Every action maps to a tier: autonomous below a dollar threshold, single-approver in the middle band, dual-approver above, and bank-detail or vendor-master changes always routed to a human regardless of amount. Which agent actions actually need approval is a separate decision from how the approval itself is captured, which should land in the ERP's own workflow rather than a shadow tool.

The fraud surface is the reason the gates are non-negotiable. The FBI's 2024 IC3 report logged business email compromise as a multi-billion-dollar category that targets exactly the vendor-change and payment-release flows AP agents touch.

Idempotency sits underneath the gates. Every tool call carries a client-generated key the agent framework persists before the ERP write. If the write succeeds and the ack is lost, the retry returns the same document number instead of creating a second one. This is not optional, it is the single mechanism that lets you run the agent at an unattended cadence without a reconciliation team behind it.

What Changes Over the Next Year

The decision facing a platform team in 2026 is no longer whether to build an AP capture agent. The ERP vendors are shipping their own. Workday's Illuminate Document Driven Accounting Agent is targeted for general availability in early 2026, SAP Joule has AP agents in preview, and Oracle's Fusion AR agents are shipping into cash application. Deloitte's view of the agentic-ERP shift is that the sub-ledger itself becomes an agent surface, not an endpoint.

That reframes the question. The next twelve months are about deciding where the ERP's native agent ends and where a custom agent takes over — exception coding against your own GL structure, deduction reason codes against your own trade terms, dunning that reflects your actual credit policy. Pick those boundaries now, write them into the agent's tool registry, and the ERP-native agents become a layer you compose against rather than a decision you have to redo when the next release lands.