Accounts Payable & Invoice Agents

Know which invoice you are automating, because the two halves cost different amounts.

The public benchmarks are unusually good in this domain. Ardent Partners' AP metrics work puts best-in-class at roughly $2.78 per invoice and 3.1 days cycle time against an all-buyer average near $10.89 and 10.9 days, with touchless rates of about 49% best-in-class against roughly 33% average. Two readings of that spread matter here:

• The clean lane is already cheap. An invoice that arrives against an open PO, matches the receipt, and codes itself costs a few dollars to process at a mature shop and needs no model at all — a matching rule and an ERP integration handle it. Automating it again with an agent produces an impressive touchless number and a small saving.
• The exception is where the money and the days are. The gap between 3.1 and 10.9 days is not spread evenly across invoices; it is concentrated in the minority that stall. Every day of stall is a discount lost, a supplier calling your team, and a late-payment risk.

So the first design decision is not architectural. Pull last quarter's invoices, split them into straight-through and exception, and price both. If your straight-through lane is already 80% of volume and 20% of cost, the agent belongs entirely on the other side.

Extraction is table stakes; the three-way match is a data problem the agent cannot read its way out of.

Modern document extraction on a structured invoice is good enough that field accuracy is rarely the binding constraint — the parsing considerations are in document parsing, and everything on this page assumes you emit a validated schema rather than free text, per structured outputs. Getting the header, the totals and the line items off the page is the part vendors demo.

The match is the part that fails. A three-way match needs three documents to agree, and two of them are produced by other people:

• The PO may not exist. Non-PO spend — services, subscriptions, one-off purchases someone made with an email — is structurally unmatchable. No amount of reading skill produces a PO that was never raised.
• The receipt may be late. Goods arrived, nobody confirmed receipt in the system, and the invoice is now blocked on a warehouse task rather than an AP task.
• The units may differ legitimately. Partial deliveries, back-orders, price changes inside tolerance, freight and tax lines the PO never carried.

The agent's leverage is upstream of the match, and it is worth more than the match itself: detect at intake that this invoice has no PO and route it to the requester while the memory is fresh; detect that the block is a missing receipt and chase the receiver, not the buyer; detect a variance and say which line and by how much. That reframing — from "match the invoice" to "name the missing document and go get it" — is the whole job, and it is the same insight that makes procurement and sourcing agents work upstream of the PO rather than on it.

Build the exception taxonomy before you build the agent.

"Exception" is not one thing, and a queue that treats it as one is why AP teams keep a person whose job is deciding who to forward things to. Classify last quarter's exceptions by root cause first — typically five to eight buckets carry nearly all the volume — and you will find each has a different owner and a different resolution path:

• No PO → the requester, with a "was this ordered, and under what budget" question.
• Missing goods receipt → the receiving location, with a yes/no confirmation.
• Price variance within tolerance → auto-release under policy, no human.
• Price variance outside tolerance → the buyer, with the PO line and the delta stated.
• Quantity variance → partial delivery check, then either release or short-pay.
• Duplicate suspicion → AP review, never auto-release.
• Unknown supplier / new bank details → vendor master control, treated as fraud until proven otherwise.

Now the agent's task is well-posed: classify the exception, gather the one missing fact, ask exactly one person exactly one question, and close the loop. That is a task with a checkable outcome, which means you can evaluate it. "Handle the invoice" is not.

Gate on irreversibility, not on amount.

Almost every AP approval matrix is keyed to invoice value, which is the wrong axis for an agent because it is not correlated with whether a mistake can be undone. Sort the failure modes by recoverability instead:

• Duplicate payment — usually recoverable. The supplier holds a credit, you claw it back, it costs working capital and embarrassment. Detect it with fuzzy matching across supplier, amount, date and invoice number, and remember that duplicates most often enter through different channels: the same invoice emailed and posted, or resubmitted with a modified reference.
• Paying the wrong entity — usually not recoverable. Business email compromise in AP is overwhelmingly a vendor bank-detail change, arriving as a plausible email with a plausible letterhead. This is the control that matters most and it is not an AI control: a change to bank details on the vendor master must require out-of-band verification against a number you already held, and an agent must never be able to write that field.
• Paying for something never received — partly recoverable, and the reason the receipt half of the match exists at all.

The practical rule: the agent may release a payment where all three documents agree, the supplier is established, and the bank details are unchanged since the last successful payment. Anything touching the vendor master, any first payment to a new payee, and any bank-detail change goes to a human with a verification step — regardless of amount, because the $4,000 test invoice is exactly how the fraudulent payee gets established. This is the concrete form of the argument in ambient authority: scope the agent's write access to the payment run, never to the master data behind it.

Every release also needs to be idempotent. An agent that retries a timed-out ERP call has just invented a duplicate payment; keys and retry semantics belong exactly where idempotency and retries puts them, and in this domain a replayed write is a real financial loss rather than a duplicated row.

Let the agent propose the coding, and let the overrides teach it.

GL coding, cost-centre assignment and tax treatment are where an agent genuinely outperforms a rules engine, because the signal is textual and the precedent is historical: this supplier, this description, this requester, coded this way 340 times. Two things make it work in practice.

Propose with a confidence and abstain below a threshold. A confidently wrong GL code is worse than a blank one, because it survives review and surfaces at close. The agent should return its suggestion, the precedent it is relying on, and an honest confidence — and route to a human below the line rather than guessing. The calibration question is the subject of uncertainty and calibration, and the same "abstention beats confident error" principle drives data and analytics agents.

Treat every human override as labelled data. An accountant recoding an invoice is telling you the precedent was wrong or the policy changed; capture the before, the after, and the invoice features, and you have a growing evaluation set that costs nothing to collect. Override rate by supplier is also the single best early-warning signal you have: a supplier whose coding suddenly needs correcting has changed something about how it bills you.

Keep the audit trail at the field level. A finance auditor's question is not "did an AI do this" but "who approved this coding, on what basis, and can I see the invoice as it was at approval time" — the retention and evidentiary requirements are in audit trails, and AP is one of the few agent domains where an external auditor will actually read them.

Measure cost per invoice and exception cycle time. Never measure touchless rate alone.

Touchless rate is the metric every vendor quotes and the easiest one in this domain to move without doing anything useful, because it has a denominator you control. Narrow the scope to PO-backed invoices from your top twenty suppliers and the rate jumps; the exceptions did not go anywhere, they left the measurement. Report it alongside the numbers it cannot be gamed against:

• Fully loaded cost per invoice, including the agent's own token and platform cost, against your pre-agent baseline. This is the number the benchmarks are stated in, so you can place yourself against $2.78 and $10.89 rather than against a percentage.
• Cycle time at p50 and p90, not the mean. AP pain is a tail phenomenon: the median invoice was never the problem.
• Exception rate by root cause, trending. If "no PO" is 40% of your exceptions, the highest-value change is a procurement policy, not a better model.
• First-pass yield by supplier. This is the number that turns an AP metric into a supplier conversation, and it is where the durable gains are — a supplier that fixes its invoice format removes the exception permanently rather than automating it.
• Duplicate and misdirected payments caught versus escaped, reported as a count with the value attached. One prevented bank-detail fraud can exceed a year of processing savings, which is also how you should present the ROI — see measuring agent ROI.

Related: finance agents for the wider finance surface including reconciliation, procurement and sourcing agents for the upstream half of the same workflow, approval and confirmation UX for designing the gate people will actually read, and human in the loop for where to place it.