What is an invoice exception, when AI agents do the work?
An invoice exception is a supplier invoice that fails one or more of the validation checks an accounts payable system runs before payment – a price that disagrees with the purchase order, a quantity above what was received, a missing PO reference, a duplicate, a tax calculation that will not reconcile. The invoice drops out of automated processing into a hold queue, where someone has to establish what went wrong and whether it is safe to pay.
This wiki defines source-to-pay terms for a world where AI agents do the operational work – matching invoices, reading contracts, resolving exceptions – and people keep the judgment calls. Most glossaries describe an exception as a task waiting for a clerk; this page redefines it for a queue an agent works.
When an invoice arrives, the system attempts a three-way match – a line-by-line comparison of the invoice against the purchase order and the goods receipt. Invoices that match within tolerance, the variance band a company allows before requiring review, post and pay without anyone touching them; AP teams call this touchless processing. Invoices that fail any check become exceptions; the types of invoice exceptions page catalogs the failure modes, and three-way matching covers the match itself. The volume is substantial: Ardent Partners' State of ePayables 2025 research puts the average exception rate at 18.4% of invoices and average processing time at 8.2 days.
To an agent, an invoice exception is an unanswered question
A matching engine treats an exception as a terminal state. It ran its comparisons, one failed, and its work is over – the invoice gets a hold code and waits for a person. An AI agent operating across the procure-to-pay process treats the same event as a starting point. The match failed because the system could not prove the invoice correct, and in the large majority of cases the proof exists somewhere in the company's records. The exception is a question: why does this invoice say $3.04 per kilogram when the purchase order says $2.86? The answer might sit in a contract amendment, a commodity price index, a buyer's email thread, or last quarter's resolution of the identical mismatch.
Framed that way, exception resolution is a research task with a verifiable end state – work agents handle well. The agent gathers evidence until one of three things is established: the invoice is correct and can post, the invoice is wrong and needs a credit, or the case is a judgment call and goes to a person with the evidence attached.
How do AI agents resolve invoice exceptions?
In practice, resolution is a short investigation, and the clearest way to see it is one case walked end to end. A metals supplier invoices 12,000 kg of aluminum extrusions at $3.04/kg against a PO written at $2.86/kg. The variance is 6.3%; the tolerance policy allows 2%. The match fails, and $36,480 goes on hold over a $2,160 discrepancy.
An agent picks up the case and works the same chain a strong analyst would:
- Check the PO history in the ERP. No price change was posted to the PO, so the discrepancy is real rather than a timing artifact.
- Pull the supplier's contract from the repository. The pricing schedule carries an index-adjustment clause: the per-kg price resets quarterly against the LME aluminum average, plus a fixed conversion margin.
- Compute the clause. The agent retrieves the relevant quarter's index value, applies the formula, and gets $3.04 – the invoiced price to the cent.
- Check precedent. Resolution history shows the same supplier repriced under the same clause two quarters ago, and the category manager approved it.
- Check policy. The tolerance framework permits price-variance overrides when a contractual adjustment is documented.
- Clear the hold. The agent posts the match with an override code and attaches the rationale: clause reference, index value, calculation, and precedent.
The case closes in minutes with a complete audit trail, where the manual version of the same investigation usually spans days of queue time and an email round-trip with the buyer. The manual vs automated exception resolution page compares the two paths step by step.
The context that clears exceptions is scattered, and some of it is unwritten
Notice what the agent needed in that example: PO history from the ERP, a clause from a contract repository, a market index, resolution history, and a tolerance policy. None of those live in the same system, and the matching engine that raised the exception could see almost none of them. The general pattern holds across exception types. Tax mismatches resolve against the tax engine's determination logs. Quantity disputes resolve against receiving records and packing slips. Non-PO invoices – legal fees, facilities work, marketing services that never had a purchase order – resolve against statements of work and approval chains, because there is no PO to match in the first place.
The harder half of the context is tribal. Every AP team runs on knowledge that appears in no system of record: this supplier always bills freight as a separate line, so a freight-inclusive PO will mismatch every time. Plant 2100 books maintenance materials to a different cost center than every other plant. "BRKT ASSY LH" on a line description is a left-hand bracket assembly. An experienced analyst carries hundreds of these rules in their head, which is why exception resolution has resisted automation for so long. An agent has to acquire the same knowledge, partly by reading years of resolution history and partly by having its early mistakes corrected. The context problem in exception resolution page covers how that works.
Agents shrink the queue without lowering the exception rate
When agents work the queue, the numbers that move are the downstream ones. Resolution time falls from days to minutes for cases whose proof exists in the records. Aging stops compounding, because holds no longer sit untouched while analysts triage by dollar value. Early-payment discounts become capturable again, since invoices clear inside the discount window instead of three weeks after it. Quarter-end stops requiring overtime to flush the backlog.
The number that stays put is the exception rate itself. Exceptions are created upstream – by stale price masters, by suppliers who invoice before goods ship, by POs cut after the work started – and an agent resolving the resulting mismatches does nothing to the causes. The why exceptions never go to zero page works through those root causes; the short version is that resolution and prevention are separate projects, and a company running agents should expect a permanently faster queue rather than an empty one.
A good escalation arrives with the investigation already done
Some cases should reach a person: a supplier claiming a verbal agreement with a buyer, a clause that is ambiguous about which index applies, a variance large enough that policy requires sign-off regardless of evidence. These are judgment calls, and an agent that guesses at them creates new risk.
What changes with agents is the quality of the handoff. A rules-based workflow escalates by forwarding the symptom: "line 4 price mismatch, see attached," and the analyst starts the investigation from zero. An agent escalates by forwarding a completed workup – what it checked, what each record showed, the calculation that almost cleared the case, and the single open question that remains. The person receiving it makes a decision in two minutes instead of reconstructing evidence for two hours. Across a queue of thousands of monthly exceptions, that difference determines whether the human team spends its time on judgment or on lookup work.
Fragment builds AI agents that resolve invoice exceptions exactly this way – working the queue inside a company's existing SAP or Ariba environment, using the same contracts, resolution history, and policies an analyst would, with no rip and replace. See how the workflows run or request a demo.