AI for Accounts Payable: What It Reliably Does, What It Cannot Decide, and How to Tell the Difference in a Demo

Quick Answer: The useful line is not how advanced the model is. It is where the answer lives. When the answer to a task is present on the document — what the invoice number is, what the line items total to, whether this arithmetic is right, whether we have seen this document before — a model is dependable, and you should automate it. When the answer depends on a fact held somewhere else — was this price renegotiated, did the goods actually arrive, is this freight charge contractual, should we pay a supplier in dispute — a model can only produce a recommendation, however confidently it phrases it. Every vendor claim worth testing sits at that boundary, and you locate it by asking what the model would have to know that is not on the page.

The claim every vendor is making

Every AP demo you sit through this quarter will show the same arc. An invoice arrives. Fields populate themselves. A match runs. Something routes. A number at the bottom right says the touchless rate is high.

You already know extraction works. That is not the part you are being asked to approve budget for. What you cannot tell from the demo is where reading a document stops and making a judgement that carries liability begins — because the interface presents both as the same green tick.

This page is a map of that boundary, and a set of questions that finds it in about twenty minutes.

The principle: is the answer in the input?

A model's ceiling on any task is set by whether the information needed to answer it is present in what the model can see.

Extraction is a perception problem. The invoice number is on the page. There is a right answer, it is visible, and the model's job is to read it. Errors here are measurable against ground truth and improve with better models.

Approving a price variance is not a perception problem. Whether $12.40 is acceptable when the purchase order says $12.00 depends on whether procurement agreed a new price — a fact that lives in someone's inbox, or in a conversation, or nowhere at all. No amount of model capability recovers information that was never in the input. A model asked to decide this is not reasoning; it is guessing from priors, and it will guess fluently.

This is why "our AI approves invoices" and "our AI reads invoices" are not two points on one scale. They are different kinds of claim, and only one of them can be validated against a right answer.

The capability map

Three bands. The distinction between them is where the ground truth lives.

Band 1 — the answer is on the page

Automate these. They are reliable, checkable, and the failure modes are visible.

Task	Why it is reliable
Header field extraction	Invoice number, dates, totals, currency, tax registration are printed on the document
Line item extraction	Structure varies but the content is present; see the continuation-page caveat below
Document classification	Invoice, credit note, statement and remittance are distinguishable from the document itself
Arithmetic validation	Do the lines sum to the subtotal, does subtotal plus tax equal the total. Pure computation
Duplicate detection	Comparison against your own history, with a definite answer
Match arithmetic	Comparing PO, receipt and invoice quantities and values is computation, not judgement
Tolerance application	Once a tolerance is set by a human, applying it is deterministic

Two cautions inside Band 1. Extraction fails quietly on documents whose logical structure disagrees with their visual structure — a line-item table spanning a page break with a carried-forward subtotal is the classic case, and it produces a well-formed wrong answer rather than an error. And duplicate detection is only as good as its definition: the same invoice re-sent with a different invoice number is a duplicate in substance and not in data, so ask what the vendor compares.

Band 2 — the answer is in your history, not on the page

These are learnable, genuinely useful, and recommendations rather than decisions. They need a feedback loop and a measurable acceptance rate.

Task	What it actually is	What it needs to work
GL coding	Predicting from your past coding of similar invoices	A correction loop; accuracy is a property of your history's consistency, not of the model
Cost centre assignment	The same, with more organisational drift	Somebody noticing when a reorg silently invalidates the pattern
Vendor resolution	Matching a printed name to a row in your vendor master	The registration number as the join key, and an explicit "unsure" state
Exception routing	Predicting who resolved this shape of problem before	A taxonomy that distinguishes waiting-on-a-fact from waiting-on-a-signature
Payment timing suggestions	Optimising against terms and discounts you have recorded	Correct terms in the master, which is usually the weak link

The honest framing for Band 2 is that these are good suggestions with a known hit rate. A vendor who can tell you their coding acceptance rate on a customer of your shape, and how it is measured, is describing something real. One who says it "learns your patterns" without a number is describing an intention.

Band 3 — the answer is not available to the model at all

These should surface to a person regardless of confidence, because the missing information is not in any system the model can read.

Decision	The fact that is missing
Accepting a price variance	Whether a new price was actually agreed
Accepting a quantity variance	Whether the delivery was genuinely short, or receiving miscounted
Accepting an unrecognised charge	Whether the contract permits it
Changing vendor bank details	Whether the request is genuine
Releasing payment to a disputed supplier	A commercial position held by a person
Approving spend above a threshold	Authority, which is a governance property and not a prediction

Band 3 is not a statement about current model quality. It is structural: these decisions are the point at which the organisation accepts liability, and delegation of that is a governance choice with a signature attached, not an accuracy question. The delegation of authority matrix is where those lines are drawn, and an AP system's job is to enforce it rather than to replace it.

The bank-detail case deserves separating out. It is the one where an accurate model makes things worse: the model can read the new account number perfectly, and the document itself can still be fraudulent. Accuracy is the wrong control entirely.

Where most teams draw the line wrongly

Two mistakes, in opposite directions.

Automating Band 3 because the confidence score is high. A confidence score reports how sure the model is about what it read, not whether the value belongs in that field and certainly not whether the decision is correct. A price variance approved at 99% confidence is a well-formed guess.

Refusing to automate Band 1 because "finance needs to review everything." This is the more common and more expensive error. A team reviewing every extracted field spends its attention uniformly across a queue where the risk is wildly uneven, which trains everyone to click. The point of automating Band 1 is precisely to concentrate human attention on Band 3, where it is actually load-bearing.

The correct posture is aggressive on Band 1, instrumented on Band 2, firm on Band 3.

What "touchless rate" is actually measuring

Nearly every vendor leads with a touchless or straight-through processing percentage. It is a real metric and it answers a narrower question than it appears to.

Touchless rate measures how much of your volume is Band 1 and Band 2 shaped. A supplier base sending clean PO-backed invoices with consistent coding will produce a high number on almost any competent platform. A supplier base sending non-PO services invoices with variable coding will not, and that is a fact about your invoices rather than about the software.

So the number is not comparable between vendors unless it is measured on the same document mix — which it never is, because each vendor reports it from their own customer base. Ask instead: on our invoices, what fraction do you expect to be touchless, and which of ours would not be? A vendor who has looked at a sample of yours can answer that. There is more on how the metric behaves in touchless invoice processing.

The demo script

Bring twenty of your own invoices. The composition matters far more than the count.

Include	What it tests
Five ordinary PO-backed invoices	The Band 1 baseline. If these are not clean, stop.
A credit note	Sign handling. Does it come back negative, or positive and silently reversing?
A multi-page invoice with a carried-forward subtotal	Whether the subtotal is counted as a line item
An invoice with two tax rates	Whether the second rate survives extraction at all
A duplicate re-sent under a different invoice number	Band 1 duplicate detection versus substance
A non-PO services invoice	Band 2 coding, with no PO to anchor against
An invoice from a vendor you have never processed	Vendor resolution behaviour and whether it says "unsure"
A short delivery against an open PO	Whether it raises the right exception type, not just an exception
An invoice with an unexplained freight line	Band 3. It should surface, not resolve
A bank-detail change request	It must stop. If anything else happens, the demo is over

Then ask four questions.

1. For each of these, what did the system decide versus recommend? The interface should distinguish them. If everything is one green tick, the boundary is invisible to your team in production too.
2. Show me the audit record for one automated action. It should name what ran, on what input, at what time, and be distinguishable from a human action. Detail in AP audit trail.
3. How is this reversed? Every automated action needs a defined reversal path, and reversal should itself be a recorded event.
4. Show me a case where the model was wrong in production and what happened next. The most informative question on the list, and the one vendors are least prepared for. An honest answer describes a detection mechanism. A vendor with no such story either has no production customers or is not measuring.

The liability test

Three properties decide whether an automated AP decision is defensible after the fact.

Attribution. The record names what made the decision, on what inputs, under which version. "The system approved it" is not attribution.

Distinguishability. A person reading the audit trail six months later can tell a human judgement from a model action without knowing the product. If they cannot, every automated decision inherits the credibility of a human one it never had.

Reversibility. There is a defined path back, and taking it is itself recorded.

If a vendor cannot demonstrate all three, treat every band as advisory regardless of what the model can do. This is the same discipline that makes the three-way match a control rather than a formality, and it is what turns exception handling into evidence rather than activity.

Sequencing: what to do first

Automating the whole map at once is how these projects stall. A workable order:

1. Band 1 extraction and validation, with arithmetic checks. Immediate, measurable, and it shrinks the queue.
2. Duplicate detection, which pays for itself on its own and is trivially auditable.
3. Match arithmetic and tolerances, once the tolerances are derived from your own closed exceptions rather than adopted from a benchmark — the method is in PO matching exceptions handling.
4. Band 2 coding, instrumented from day one with an acceptance rate you actually watch.
5. Routing, only after the exception taxonomy is right. Routing a badly classified exception faster does not help.

Band 3 does not get a step. It gets a policy, and the system enforces it.

A caveat on sequencing: if your AP queue is slow because approvals sit with people rather than because documents are slow to process, none of this touches the constraint. Measure before you sequence — the same argument applies upstream in purchase order process automation.

Where Ken fits

Ken works Band 1 and Band 2 and refuses Band 3. Invoices arrive in Slack, get extracted, checked against your history for duplicates, matched against the PO and receipt, coded from your past coding, and routed to the person who can resolve whatever does not agree. Every action is attributable and reversible.

What Ken does not do is approve a payment. Not because the extraction is not good enough, but because approval is where liability attaches, and the fact that settles most AP exceptions — was this agreed, did it arrive, is it contractual — is not in the document Ken is reading. Any vendor telling you otherwise is describing a confident guess.

FAQ

What can AI reliably do in accounts payable?

Anything where the answer is present on the document or computable from your own records: extracting header fields and line items, classifying document type, validating that the arithmetic adds up, detecting duplicates against your history, and performing the comparison arithmetic in a three-way match. These have a checkable right answer, which is what makes them safe to automate.

What should AI never decide in accounts payable?

Anything whose answer depends on a fact not available to it: accepting a price or quantity variance, accepting an unrecognised charge, changing vendor bank details, releasing payment to a disputed supplier, or approving spend above an authority threshold. These are governance decisions with liability attached, and a model asked to make them produces a fluent guess rather than a judgement.

How do I test AI AP claims in a vendor demo?

Bring twenty of your own invoices including a credit note, a multi-page invoice with a carried subtotal, a two-tax-rate invoice, a duplicate re-sent under a new number, a non-PO services invoice, an unseen vendor, a short delivery, an unexplained freight charge and a bank-detail change request. Then ask what the system decided versus recommended, show me one audit record, how is it reversed, and show me a case where the model was wrong in production.

Is a high touchless rate a good comparison between AP vendors?

Not on its own, because each vendor measures it on their own customer base and it is largely a property of your supplier mix rather than of the software. A supplier base of clean PO-backed invoices scores well anywhere. Ask instead which of your specific invoices the vendor expects would not be touchless, and why.

Does high extraction confidence mean an invoice can be auto-approved?

No. A confidence score describes certainty about what was read, not whether the value belongs in that field, and certainly not whether the resulting decision is correct. Approval depends on facts held outside the document, so confidence is the wrong control for it entirely.