Every accounts payable team can describe the three-way match in a sentence. Compare the invoice to the purchase order and to the goods receipt, and if the three agree, pay. Put that way it sounds like a comparison problem, and comparison problems are the kind computers have handled comfortably for decades.
Yet accounts payable remains one of the most stubbornly manual functions in the enterprise. That should tell us the description is wrong.
The work is in the disagreement
When the three documents agree, almost nothing needs to happen, and in most organisations that path is already reasonably automated. The cost concentrates in the cases where they do not agree, and those cases are not rare.
A delivery arrives split across two shipments, so one receipt covers part of an invoice. A supplier bills freight that was never on the purchase order. A price was renegotiated after the order was raised. A unit of measure differs between the order and the invoice, so quantities look wrong but are not. Someone received goods against the wrong line. The invoice arrives before the receipt because the plant is behind on confirmations.
None of these are matching failures. They are ordinary operational reality, and resolving each one requires knowing something that is not written on any of the three documents.
Why generic automation plateaus
Rules-based tools handle the clean lane well and then stop. Each exception type needs its own rule, the rules interact, and after a few hundred of them the configuration becomes something nobody is willing to change. Teams end up with high automation rates on the transactions that were never expensive and no movement at all on the ones that were.
The published benchmarks on accounts payable cost per invoice, including the long-running work by Ardent Partners, consistently show the same shape. The gap between top performers and everyone else is not explained by capture technology. It is explained by how much human intervention the exception path demands.
What an agent needs in order to help
To resolve an exception the way an experienced clerk does, an automation needs four things, and most deployments provide only the first.
- The documents. Necessary, and the easy part.
- The surrounding context. The rest of the purchase order, the supplier's history, prior invoices, open receipts, the contract terms.
- The organisation's own tolerances. Not generic thresholds but the ones configured in this system, for this plant, for this commodity.
- Somewhere to act. The ability to post, to route for approval, or to raise a query, inside the system of record and under the existing authorisation model.
The measure that matters
If you are assessing an automation programme, the headline capture accuracy is close to meaningless on its own. Ask instead what proportion of exceptions are resolved without a person, and how long the remainder wait. That single pair of numbers tends to explain most of the difference between a programme that changed the cost base and one that produced a good dashboard.
Matching was never the bottleneck. Judgement was.
