Can three-way matching be automated with AI?

Yes, and it is one of the few finance workflows where automation can realistically run end to end. Three-way matching compares an invoice against the purchase order and the goods receipt or delivery note: the inputs are documents, the decision is a comparison against rules you set, and the output is binary — approve for payment, or raise an exception. An AI pipeline reads all three documents, normalises them against your master data, matches line by line within your tolerances, and sends only exceptions to a person.

We have run this in production: 10,000+ invoices processed, 100% automation on the delivered flow, and real fraud found and confirmed. This article covers where matching actually breaks — which is not where most people expect — and how the pipeline is built.

Why does three-way matching consume so much time by hand?

Because the comparison is easy and the preparation is not. Someone has to find the order, find the delivery note, line the three documents up, and translate between the way three different systems describe the same goods. On a single invoice that is a few minutes. Across a few thousand invoices a year it is a job, and it is a job nobody enjoys, which is why in most companies it quietly degrades into spot checks.

Spot checks are where the money leaks. An invoice that is 4% above the agreed price passes every time, because nobody is comparing it to anything.

Where does automated matching actually fail?

Not at reading the documents. Modern extraction handles real invoices well. Matching fails at normalisation — making three descriptions of the same transaction comparable:

• Units of measure. The order says 10 boxes, the delivery note says 240 pieces, the invoice says 20 kg. Nothing is wrong; nothing matches either until someone knows the conversion.
• Part number variants. Your code, the supplier's code, and the code printed on the invoice are three different strings for the same item.
• Partial and split deliveries. One order, four deliveries, two invoices. Line-level matching has to accumulate across documents instead of comparing one to one.
• Freight, discounts and surcharges. Lines that exist on the invoice and on no other document, and are perfectly legitimate.
• Rounding and currency. Cent-level differences that a human waves through and a naive rule engine escalates a thousand times a month.

This is why matching projects are won or lost on your master data, not on the model. It is also why the first days of any serious engagement go on documents and master data rather than on technology choices.

What does the pipeline look like?

Six stages, all of which run in a cloud account you own, so invoices never leave your accounts:

• Capture — invoices arrive by email, portal or scan and enter the pipeline automatically, attachments included.
• Extraction — OCR plus a model running in your own cloud account read the document and return structured lines: item, quantity, unit, unit price, totals, tax, references to order and delivery note.
• Normalisation — units, part numbers and supplier identities are mapped to your master data. This is the layer that decides whether matching works at all.
• Matching — invoice lines are matched to purchase order lines and to goods receipts, accumulating across partial deliveries, within tolerances you define.
• Decision — inside tolerance, the invoice is approved for posting. Outside it, it becomes an exception with the reason and the candidate documents attached.
• Exception handling — finance sees a queue of anomalies with the evidence, not a pile of PDFs. People judge; the system prepares the judgement.

Tolerances are the real design decision, and they belong to finance rather than to engineering. Wide tolerances produce a quiet system that misses things. Narrow ones produce an exception queue nobody works. The right setting is the one your team already applies informally, written down and enforced consistently.

What does matching catch once it runs on every invoice?

Five categories, in rough order of how often they show up:

• Duplicate invoices — the same document submitted twice, or once as PDF and once as a scan with a different number.
• Quantity billed above quantity received, including the version that hides inside a split delivery.
• Unit prices above the agreed order price, including small increments that pass a human eye at line level.
• Line items that appear on no order — services added to a goods invoice, phantom charges, unagreed surcharges.
• Changes to supplier bank details relative to the master record — the single highest-value check in the whole flow.

Most of what a matching system finds is error rather than fraud. That is fine: an overpayment costs the same either way, and the controls that catch honest mistakes are the same ones that catch deliberate ones.

What has this produced in production?

On the delivered system, more than 10,000 invoices have been processed with full automation of the reconciliation flow, and the checks surfaced fraud that manual spot-checking had not. Measured numbers from a running system, not a projection.

What are the honest limits?

Three-way matching needs three documents. If goods receipts are not recorded, or orders are placed by phone and confirmed by email, there is nothing to match against and the first project is to capture the missing document, not to buy AI.

Volume matters too. A few hundred invoices a year will not repay a build. A matching pipeline is usually a Bottlenose — there is a database, an exception dashboard and integrations to build, and the flow runs supervised — from €5,000 / $5,900 plus a €300–700/month maintenance fee. The free 30-minute intro call is where the volumes get checked — and if they do not justify a build, we say so before anyone signs anything.

How many invoices do you check properly?

Take the free AI Audit: five minutes, and you will know whether matching is your best first automation or whether something upstream comes first. Then book a call. See also: where AP leaks money.