Every payables demonstration follows the same script. An invoice appears, a model reads it, and a confident green tick says matched. It is a good demonstration. It is also the wrong architecture, and the reason is not technical purity. It is that nobody can audit a tick.
Three way match is arithmetic. Compare the invoice against the purchase order and the goods receipt, apply the tolerance agreed with that supplier, and decide. There is no judgement in it, no ambiguity to resolve, no context to weigh. A rules engine does this in a millisecond, identically every time, and can show its working. A language model does the same job more slowly, more expensively, and with a small probability of being confidently wrong in a way that only surfaces after payment.
The question is not whether a model can do the match. It is what happens the day it does the match differently.
Where intelligence genuinely earns its place
This is not an argument against artificial intelligence in payables. It is an argument about placement. Reading a supplier invoice is a genuinely hard problem: layouts differ by vendor, line descriptions are inconsistent, tax is presented six ways, and half the documents are photographs of paper. That is exactly what a model is good at, and a rules engine is hopeless at.
So the line falls in a specific place:
- Extraction is intelligence. Header and line detail out of an unstructured document into a structured record.
- Retrieval is intelligence. Finding the right purchase order when the reference on the invoice is wrong, abbreviated or missing.
- Matching is arithmetic. Quantity, price, tax and value against tolerance. Deterministic, repeatable, explainable.
- Drafting is intelligence. Writing the supplier a clear note about a variance, in their language, from the actual numbers.
- Deciding is human. Nothing posts and nothing pays without a person, and the audit trail records who.
Put like that it sounds obvious. It is not what most implementations do, because the impressive part of the demonstration is the model saying matched, and the unimpressive part is a rules engine doing subtraction.
The tolerance is the whole conversation
A tolerance is not a technical setting. It is a commercial position, usually negotiated, often per supplier, and it changes. Five per cent for a commodity vendor with volatile freight. Half a per cent for a contract manufacturer on a fixed rate card. Zero for the supplier who has been over-invoicing for two quarters and is now on watch.
When the tolerance lives in code, changing it is a release. When it lives in a model prompt, nobody can tell you what it currently is. When it lives in a row in a table, changing it is a configuration change that takes effect on the next invoice, carries the name of whoever made it, and can be shown to an auditor with a timestamp. That last one is the only version that survives contact with a controls review.
You can see the difference on our home page. The match there runs in your browser. Move the tolerance from five per cent to one and a half, and invoices that passed a moment ago now break. Nothing was retrained. A number changed.
What a match break should produce
Most systems stop at the break. The invoice lands in an exception queue, a person opens it, works out what happened, then writes to the supplier. That last part is where the hours go, and it is where a model belongs again.
A useful exception carries three things. The reason code, so the queue can be reported on and the pattern can be seen. The actual variance in money, because a supplier argues with an accusation and concedes to a number. And a drafted reply that quotes both, ready for a person to read, edit and send.
The draft is written by a model. It is sent by a human. That distinction costs nothing to implement and it is the difference between an automation programme that passes a controls review and one that gets stopped in month four.
The test to apply
Before pointing a model at any step in a finance process, ask what you would say to an auditor who asks why this transaction was treated differently from that one. If the honest answer involves the word probably, the step belongs in a rules engine. If the honest answer is that a person looked at it and decided, the step belongs to a person.
Everything else, and it is a great deal, is where intelligence should be working.