AI Invoice Processing: Where Extraction Ends and Judgement Begins

Quick answer: Extraction is the solved part of AI invoice processing. The product lives in what happens to the invoices that do not sail through: which exception types an agent can close on its own, which have to surface to a named human, and what evidence the system leaves behind for each decision. Judge a vendor on the exception path, not the demo.

Every AI invoice processing demo runs the same clean invoice. Fields light up, a match resolves, an approval fires. It is a fair demonstration of extraction and a poor demonstration of a product, because extraction is no longer where invoice processing goes wrong.

The gap the demo does not show

Two numbers from Ardent Partners' 2025 AP metrics report, drawn from 212 AP organisations, describe the real shape of the problem.

The exception rate is 14% — roughly one invoice in seven leaves the automated path. But straight-through processing sits at 32.6%, meaning only a third of invoices reach payment without a person touching them.

Put those together and the interesting number is neither of them. If 86% of invoices match cleanly and only 33% flow through untouched, then somewhere around half of all invoices are being handled by a human despite having nothing wrong with them. They are stopped by coding, routing, approval thresholds, or a queue that has no rule for them. That is the population a demo never shows, and it is larger than the exception population everyone argues about.

The same research puts average processing time at 9.2 days and cost per invoice at $9.40, and reports that only 5% of AP teams describe exception management as fully automated. Extraction accuracy is not what stands between those numbers and better ones.

What the agent is actually deciding

It helps to stop describing invoice processing as a pipeline of stages and start describing it as a sequence of decisions, each with a different amount of judgement in it.

Extraction covers the first two rows. Everything a vendor calls intelligence is a claim about the last four. When you evaluate an AI invoice processing product, you are evaluating how it behaves on rows three through six and how honestly it tells you which of those it is not doing.

The exception taxonomy, and who can close each one

Exceptions are not one category. They differ in what caused them, in how reversible the wrong answer is, and in who has the authority to fix them. Lumping them into a single review queue is why exception handling stays manual at 95% of the teams Ardent surveyed.

The row that matters most is the bank detail change, and it is the one most likely to be quietly automated because it looks like a data update. It is not. It is an irreversible payment decision wearing the costume of a master data edit, which is exactly the pattern described in our work on AI fraud detection in finance.

The calibration rule behind the table

The column headed "can an agent close it alone" is not a judgement call made per exception. It falls out of two questions asked once per exception type.

Is the decision reversible? If the wrong answer can be undone next cycle at ordinary cost, it is reversible. A miscoded invoice is reversible. A payment to a fraudulent account is not.

Is the outcome observable? If a wrong answer produces a signal you would actually notice — a variance report, a supplier complaint, a reconciliation that fails — it is observable. If the wrong answer looks exactly like the right answer until quarter end, it is not.

Those two questions produce four positions:

• Reversible and observable — delegate to the agent, audit a sample. Currency rounding, in-tolerance price variance, recurring non-PO patterns.
• Reversible but not observable — build the signal first, then delegate. Coding decisions usually sit here: nothing breaks visibly when the cost centre is wrong, so a monthly coding review has to exist before an agent is allowed to code unattended.
• Not reversible but observable — the agent recommends and a human approves. Over receipts, out-of-tolerance variances.
• Neither reversible nor observable — stays human, with verification outside the channel the request arrived on. Bank detail changes, first payments to new vendors.

This is the calibration work, and it is the part most vendors skip because it produces a smaller autonomy claim than the slide deck wants. A product that tells you which decisions it will not take is more credible than one that claims all of them. The same reasoning applies wherever agents touch operational decisions, which we set out in more detail in AI process mining and, for the pattern in general, in the human-in-the-loop AI definition.

Who owns an exception once it surfaces

An exception that surfaces to the wrong person has not been resolved, it has been queued. This is the mechanism behind a 9.2-day average that persists through every extraction upgrade: the invoice was read in four seconds and then waited six days for a buyer to answer an email.

Route each exception type to whoever can actually close it:

AP owns the queue, its ageing, and its escalation. AP does not own the answers, and a system that routes everything to AP has converted a distributed decision problem into a single-team backlog. Ardent puts AP staff time spent handling supplier inquiries at 21.8% — more than a fifth of the department explaining where invoices are. Much of that is the visible surface of an exception queue with no supplier-facing view and no owner outside the team.

Give every exception type an owner, an ageing clock, and an escalation path that fires without anyone remembering to chase. Then measure time-to-close per owner, because that is the number that moves cycle time.

The evidence trail an auditor will ask for

If an agent decides, the decision needs a record that survives the person who configured it. For each decision the system takes or proposes, the trail should carry:

• The source document and a hash of it, so the input is provably unchanged
• The extracted fields with per-field confidence
• The version of the rule set or model that made the call
• The commitment matched against, and the tolerance applied
• Whether a human approved, overrode, or never saw it
• Timestamps for each transition, and the identity of whoever acted

The test is simple and worth running before you sign anything: take one invoice paid six months ago and reconstruct the decision without asking a person. If the reconstruction needs an engineer to query a log, the trail is a debugging artefact rather than an audit record. If the system cannot say which model version made the call, it cannot answer the only question that matters after a bad decision, which is whether the same call would be made today.

Systems that write this record as they go can also answer the question in reverse: given a rule change, which past decisions would have gone differently. That is a stronger position than accuracy percentages, and far fewer products can do it. Where this sits relative to the ledger itself is covered in AI and ERP integration.

Three questions that separate a product from a demo

Ask these in the evaluation, and ask for artefacts rather than answers.

1. "Show me the live exception queue from a customer at our volume. What are the top five exception types, and what share does the system close without a human?" A product in production has this view and the numbers are unflattering, which is the point. A demo has no queue, or has one populated with the same clean invoices.

2. "When the agent is wrong, what breaks, and how do we find out?" You are asking for the reversibility and observability answer from the calibration section. A serious vendor will name the exception types they deliberately refuse to automate. A vendor who says the agent is not wrong is telling you they have no reversal metric.

3. "Reconstruct the decision on this specific invoice from six months ago." Do it on their system, with a real record, in the evaluation. Not a screenshot of an audit log.

A fourth is worth adding if the vendor leads with a touchless rate: what is that rate excluding invoices auto-approved below a threshold? Auto-approval under a dollar limit is a policy setting, not a capability, and it inflates the headline number by design.

Measure the exception path, not the extraction

Extraction accuracy is a vendor metric. It is high everywhere, it does not vary meaningfully between serious products, and it does not predict cycle time. Track these instead:

• Exception rate by type, not in aggregate — the mix tells you what to fix
• Agent close rate per exception type — where autonomy is actually earning
• Reversal rate — decisions later overturned by a human, per type. Rising reversal in a delegated type means the calibration was wrong
• Time-to-close by owner — the number that governs cycle time
• Share of clean invoices still touched by a person — the gap between 86% and 32.6% described at the top, measured in your own data

The first month of those five numbers will tell you more about whether AI invoice processing is working than any accuracy figure, and it will tell you which exception type to attack next. Teams that skip this step tend to hit the pattern described in why AI projects fail: a system that performs well on the population it was demonstrated against and stalls on the one it was bought for.

FAQ

What percentage of invoices become exceptions?

Around 14% on average, according to Ardent Partners' 2025 research across 212 AP organisations — roughly one in seven. The more useful figure is the same study's straight-through processing rate of 32.6%. Only a third of invoices reach payment untouched, so a large share of invoices with nothing wrong with them are still being handled manually because of coding, routing, or approval rules rather than genuine exceptions. Measure both in your own data before buying anything; the gap between them is usually where the fastest gains are.

Which invoice exceptions can an AI agent close on its own?

The ones where a wrong answer is both reversible and observable: currency and rounding differences, price variances inside a contracted tolerance, short receipts that resolve when the receipt posts, and established recurring non-PO patterns with a standing approver. Exceptions that are irreversible or invisible until much later should not be delegated — changed vendor bank details, first payments to new vendors, and over receipts among them. Coding decisions sit in between: reversible but rarely observed, so a review mechanism has to exist before an agent codes unattended.

Who should own AP exceptions?

The person who can close them, which is usually not accounts payable. Price and rate disputes belong to the buyer who signed the contract, receipt discrepancies to the receiving location, coding questions to the budget holder, and missing commitments to whoever made the purchase. AP owns the queue, its ageing, and its escalation. Routing every exception to AP converts a distributed decision problem into one team's backlog and is a common reason cycle times stay high even after extraction accuracy improves.

What audit evidence does AI invoice processing need to leave?

For every decision the system takes or proposes: the source document and its hash, the extracted fields with confidence scores, the version of the model or rule set that decided, the commitment matched and the tolerance applied, whether a human approved or overrode, and timestamped transitions with actor identity. The practical test is to pick a paid invoice from six months ago and reconstruct the decision without asking anyone. If that needs an engineer and a log query, the system has debugging output rather than an audit trail.