AI in accounts payable — from OCR to autonomous invoice matching

Accounts payable is where most businesses meet AI for the first time, because it is the most mechanical thing finance does: a document arrives, somebody types its contents into a system, somebody else checks it against a purchase order, somebody approves it, and money moves.

Every step there is a candidate for automation, and vendors have been promising to automate it since the 1990s. The promise finally mostly landed — but not evenly, and not in the way the brochures said. Here is what actually changed, era by era.

Era one: template OCR (1990s–2000s)

The first wave could read text off a scanned page. That was genuinely hard and genuinely useful, and it came with a catch that defined the next twenty years: it needed to be told where to look.

You configured a template per supplier. Invoice number lives in this rectangle. Total lives in that one. Get a hundred suppliers set up and the system hummed.

Then supplier 101 arrived. Or supplier 12 redesigned their invoice. Or someone photographed a delivery order at an angle. Every one of those broke the template, and fixing it was a small IT project.

The result was a system that worked beautifully for the twenty suppliers you had bothered to configure, and not at all for the long tail — which, in most businesses, is most of the invoices. Teams ended up with automation for the easy cases and manual entry for everything else. The maths rarely justified it below a certain volume, which is why most small businesses skipped this era entirely and kept typing.

Era two: machine-learning extraction (2010s)

The second wave stopped asking where to look and started learning what an invoice looks like. Trained on enough documents, a model could find the total on a layout it had never seen, because totals tend to sit in total-ish places and have total-ish characteristics.

This was a real jump. Template maintenance largely disappeared, and accuracy on the long tail became tolerable rather than hopeless.

It had two limits. It needed training data — the model was only as good as the corpus behind it, which favoured big vendors with big customers. And it extracted fields, not meaning. It could tell you the number next to "Total" was 4,820.00. It could not tell you that this invoice was for the job the site supervisor cancelled last Tuesday.

Era three: language models (2020s)

The current wave reads the document the way a person does — context and all. No template. No per-supplier training. A layout it has never encountered is not a special case; it is Tuesday.

More importantly, extraction stopped being the interesting part. When the system can read an invoice and the PO and the delivery note and the email thread attached to it, the question changes from "what does this document say?" to "does this document make sense?"

That is a different job. That is the job AP staff were actually doing all along.

What "autonomous matching" actually means

The phrase gets used loosely, so here is the concrete version.

Classic three-way matching compares the invoice against the purchase order and the goods receipt. If all three agree, pay it. The theory is thirty years old; the practice was manual because the three documents lived in different places, in different formats, and matching them required judgement about what counts as agreement.

Autonomous matching means the system does the comparison and reasons about the gaps:

• The invoice says 100 units. The receipt says 98. Is that a short delivery, a counting error, or a partial shipment with the rest to follow?
• The invoice is RM4,820. The PO was RM4,800. Is that RM20 a delivery charge you agreed on the phone, or a supplier quietly repricing?
• This invoice number resembles one you paid in March. Duplicate, or a legitimate re-issue?

A system that handles the clean cases and escalates the rest is what people mean by touchless processing. The honest number to ask a vendor is not their accuracy rate — it is what proportion of your invoices go end-to-end without a human, and what happens to the rest.

The part nobody demos: exceptions are the job

Here is the uncomfortable truth about AP automation at every era.

The clean invoices were never the problem. An invoice that matches its PO exactly takes a competent clerk a few seconds. Automating a few seconds is nice but it is not why AP is painful.

AP is painful because of the minority that do not match — and those are exactly the ones automation struggles with, because "does not match" is not one problem. It is fifty problems wearing a trenchcoat. Wrong quantity, wrong price, missing receipt, part-delivered, credit note pending, wrong entity, argued about in a WhatsApp thread nobody logged.

So be suspicious of any demo run on clean data. The value is not in the matching. It is in the exception handling — how the system routes a mismatch to the right person, gives them the context to decide in ten seconds instead of ten minutes, and remembers the decision next time. A tool that automates the easy majority and dumps the hard remainder in an inbox has moved your problem, not solved it.

Guardrails are not optional here

This is a system that decides whether to pay people money. Two failure modes matter, and both are worse in the AI era.

Plausible-but-wrong. A language model produces confident output. If it misreads 4,820 as 4,320 it will not flag uncertainty in a way an untrained eye catches. The mitigation is not a better model — it is structural: a human approves anything above a threshold, always, and the approval is logged.

Fraud gets more convincing. Invoice fraud has always worked by looking legitimate. A model trained to accept things that look legitimate is not, by itself, a defence. Supplier bank-detail changes should require out-of-band verification. That is a process rule, not an AI feature, and no model removes the need for it.

The non-negotiables for any AP automation touching real money:

• An immutable audit trail — who or what did each step, and when.
• Approval thresholds with a named human above them.
• Duplicate detection that runs independently of the extraction.
• Out-of-band verification for changes to payment details.
• The ability to explain why something was matched, in terms a person can check.

We build these as first-class parts of the system rather than settings, for the reason set out in what is an AI-native ERP: when generation is cheap, governance is what keeps you solvent.

Common questions

What is three-way matching, and can software do it on its own?

Three-way matching compares the invoice against the purchase order and the goods receipt, and pays it if all three agree. The theory is thirty years old; the practice stayed manual because the documents lived in different places and different formats, and matching them required judgement about what counts as agreement. Autonomous matching means the system does the comparison and reasons about the gaps — a short delivery, a price difference, a possible duplicate — then escalates whatever it cannot settle.

Can AI read an invoice from a supplier it has never seen before?

Yes. Template OCR had to be told where to look on each supplier's layout, so a new supplier, a redesign or a photograph taken at an angle broke it. Language models read the document the way a person does, context and all, with no template and no per-supplier training. The bigger shift is that the system can read the invoice, the purchase order, the delivery note and the email thread together, and ask whether the whole thing makes sense.

Do I still need human approval if the extraction is accurate?

Yes. This is a system that decides whether to pay people money, and a language model produces confident output — if it misreads a figure it will not flag uncertainty in a way an untrained eye catches. The mitigation is structural rather than a better model: a human approves anything above a threshold, always, and the approval is logged. Changes to supplier bank details should require out-of-band verification, which is a process rule no model removes.

Why does AP automation disappoint after the demo?

Because demos run on clean data, and clean invoices were never the problem — one that matches its purchase order exactly takes a competent clerk a few seconds. The pain is the minority that do not match, and "does not match" is not one problem: wrong quantity, wrong price, missing receipt, part-delivered, credit note pending, wrong entity, argued about in a WhatsApp thread nobody logged. A tool that automates the easy majority and dumps the rest in an inbox has moved your problem.

Count your invoices before you automate anything

Not with a full AP overhaul.

Start by measuring what you actually have: how many invoices a month, how many suppliers, what proportion match cleanly today, and where the time goes. Most finance teams are surprised — they assume data entry is the cost, and it is usually chasing.

Then automate capture and matching for the clean path, and put real effort into the exception queue, because that is where your hours are. If a vendor wants to talk about extraction accuracy and not about exceptions, you are being shown the easy majority.

If you want the mechanics of the document side, that is Document AI. If you are weighing this against your existing accounting package, the finance sector page has the fuller picture: Accounting & Finance.

Related: natural language replaced the ERP consultant — mostly, and AI-native ERP vs traditional ERP.

Also worth reading: a modelled AP scenario for a multi-entity group.