AP automation software or custom AI agents for accounts payable?
Buy AP software if your process looks like everyone else's. Build on your ERP if it doesn't, or if approvals and data need to stay where your team already works.
Mid-market companies that already use AI have budget for it. In RSM's July 2026 survey of 1,030 such companies in the US and Canada, 58% plan to spend $1M or more on AI in 2026. Among those with only moderate or limited pilot success, the top blockers were data quality (53%) and integration (47%), and accounts payable has plenty of both. Invoices arrive in every layout your vendors can invent, and whatever the AI reads has to land correctly in the ERP.
Packaged AP software moves your invoices and approvals into its own tool. If your invoices are standard and your approvers will happily log into another system, that's a reasonable trade. We'll say so in a Deployment Diagnostic (2-3 weeks, $7,500 fixed) instead of selling you a build.
A custom agent on your ERP makes sense when:
- Approvers live in Slack or Microsoft Teams and won't adopt another tool.
- Your invoices are unusual: construction pay applications, freight bills with surcharges, utility bills split across sites, intercompany charges.
- Most of AP already lives in your ERP, and the gap is reading documents and routing exceptions.
- AP is tangled with other work, such as project costing or client billing, and a separate tool would split the data.
- You'd rather own the logic than rent it.
Whichever way you lean, test with your own invoices. A demo on a vendor's sample PDFs tells you nothing about your vendors.
The AP workflow, step by step: delete it, plain code, agent or human
Sort every AP step before anyone writes a prompt.
| AP step | Sort it into | What that looks like |
|---|---|---|
| Intake from many senders and formats | Plain code, and delete the paper route | A shared AP mailbox and forwarding rules collect emailed invoices, and portal downloads run as a scheduled job. Vendors who still mail paper get asked to send PDFs, so nobody has to scan. |
| Extraction | Agent | Every vendor's layout is different. The agent reads the PDF or the email body and returns each field with where it found it and how confident it is. |
| Vendor match | Plain code, with the agent on fuzzy names | Code matches on tax ID or remit-to address. When the name on the invoice doesn't match the vendor master, the agent proposes a match and explains why. New vendors go to a person. |
| PO and receipt matching | Plain code | Comparing quantities and prices with the purchase order and the goods receipt is arithmetic, with tolerances your controller sets. Don't pay a model to subtract. |
| GL coding | Agent suggests, person confirms | For invoices without a PO, the agent proposes the GL account and cost center from the vendor's history and the line description. Recurring bills get a fixed rule in code. |
| Exceptions | Agent drafts, person decides | The agent explains what doesn't match, such as a price that moved or a receipt that never arrived, and drafts the note to the buyer or the vendor. A person decides what happens next. |
| Approvals | Human decision | Code routes each invoice by amount and department, straight from your approval matrix. The approval itself belongs to a person, wherever they already work. |
| Payment run | Human decision | Code builds the proposed run and checks it for duplicates. A person with payment rights reviews and releases it. The agent never releases a payment. |
| Vendor questions | Agent | "Where's my payment?" emails get a reply drafted from the payment status in the ERP. Anything about bank details goes to a person. |
| Bank-detail changes | Human decision, always | A person verifies every change by calling the vendor on a number already on file. An email is never enough, however convincing. |
| Status spreadsheets and re-keying | Delete it | Copying invoice data into a tracker, or keying it into another system, exists only because systems don't talk. As soon as the agent writes to the ERP, retire the tracker. |
Invoice processing automation goes wrong when the model gets jobs that arithmetic does better. The model is the most expensive and least predictable part of the system, so code checks everything it produces before anything reaches the ERP. If an earlier AP pilot stalled, run it against our pilot-to-production checklist before you try again.
Accounting firms that run bill pay for clients face the same split for every client on their books. We cover that version in AI for accounting firms.
What to measure in accounts payable automation
Before you put AI in accounts payable, measure the numbers below, then measure them again after go-live. Without the before, nobody can say whether the automation worked.
- Cost per invoice. AP team hours times their loaded hourly cost, plus software and bank fees, divided by the invoices processed in the same period.
- Cycle time. From arrival to approval, and from arrival to payment. Track both, because they break for different reasons.
- Touchless rate. The share of invoices that reach approval with nobody editing a field. Approval clicks don't count as touches, since a person should always make them.
- Exception rate. The share of invoices that need a person to resolve a mismatch, split by reason. That split tells you what to fix next.
- Duplicates caught. Count and amount, stopped before payment.
- Discounts captured. Early-payment discounts taken, against discounts offered. Slow approvals are where these go missing.
Add a number for the agent itself: how often its extracted fields and GL codes match what your team would have entered. Score it on the eval set before launch and again during shadow mode.
We won't quote a touchless rate before we've seen your invoices. It depends on your vendor mix and on how many invoices come with a PO, so any figure promised up front is a guess.
AP controls: what an AI agent must never do alone
An AP agent never releases a payment and never changes vendor bank details. Everything else it does leaves a record your auditors can read.
A person approves every payment. The agent can prepare the payment run. A person with payment rights releases it, in the ERP or the bank portal, the way they do today.
Bank-detail changes always go to a person. A request to change where a vendor gets paid is a classic fraud move, and email makes it easy to fake. The agent flags any invoice whose remit-to details differ from the vendor master, and it never updates bank details itself. A person verifies the change by calling the vendor on a number already on file, not the number in the email.
An audit trail for every invoice. What arrived, what the agent extracted and where on the page it found it, its confidence, the model version, the GL code it proposed, and who approved what and when. All of it stays in your systems.
Segregation of duties, applied to the agent. Give the agent its own system account with the narrowest rights the workflow allows. It can't approve or pay, and it can read the vendor master but never edit it. Treat it like a new hire your auditors haven't met yet.
Integration paths: NetSuite, QuickBooks Online, Dynamics and the AP inbox
The agent works inside systems you already run. It reads from the ERP and the AP inbox, and it writes back through the ERP's own APIs under an account that can't approve or pay.
The AP inbox. Start at the shared mailbox in Microsoft 365 or Google Workspace. The agent reads each message and files the attachment against the right vendor. It replies to vendors only where you've allowed it to.
NetSuite. NetSuite's AI Connector Service lets AI assistants read and write NetSuite records over MCP, within the user's role. We use it for lookups, such as a PO's status or a vendor's payment history. Writes, like creating a vendor bill, go through NetSuite's standard APIs under a role that can do that and nothing else.
QuickBooks Online. The agent reads vendors and accounts through the QuickBooks Online API and records bills there. Paying a bill stays with a person.
Microsoft Dynamics. Same pattern, through its own APIs. If a partner configured your instance, we bring them in early, because they know where the customizations are.
Approvals in Slack or Teams. The approver gets a message with the invoice and the match result, plus the GL code the agent proposed and why. Approve or reject from the message. The decision is recorded under the approver's own name, in the ERP and in the audit trail.
AI accounts payable automation: timeline and price
One AP workflow takes a 2-3 week Deployment Diagnostic and a 6-8 week Production Sprint, both at fixed prices.
Deployment Diagnostic, 2-3 weeks, $7,500 fixed. A senior engineer sits with your AP team and maps how invoices really move, exceptions included, with access to the ERP and the AP inbox. You get the baseline numbers above, the step sorting for your process, an eval plan and a fixed quote. The $7,500 is credited against the Production Sprint if you go ahead.
Production Sprint, 6-8 weeks, $25,000-$60,000 fixed. One AP workflow goes live inside your existing tools. Before go-live it runs in shadow mode next to your team, so you see its numbers against the baseline. It comes with evals, an audit trail, human approval on payments and a written handover. How many systems and legal entities it touches moves the price within that range.
After launch. Vendors change their layouts and model providers release new versions, so someone has to rerun the evals and fix what drifts. Our AI Team retainer keeps it running, from $3,000 per month.
If you'd rather keep a senior engineer inside finance operations for longer, our Embedded Engineer option does that 2-3 days a week, with the studio behind them, for $16,000-$20,000 per month. That's our forward-deployed engineering model, and it's how we run AI implementation work: the engineer sits in your systems, next to the people who process the invoices.