Three way matching is the oldest control in accounts payable and the most widely skipped.
The idea is simple and correct. Before an invoice is paid, check it against 2 other documents: the purchase order, which says what was agreed, and the goods receipt, which says what actually arrived. If all 3 agree on quantity and amount, the invoice is real, authorised and delivered. If they disagree, something is wrong and paying would be a mistake.
Nobody argues with the logic. What happens in practice is that the control gets applied to the invoices somebody had time for, which is not the same control at all.
documents that have to agree: the purchase order, the goods receipt and the invoice
line invoices parsed and coded accurately at ControlPlane, per its CFO
to process a multi-line invoice at Oper Credits, down from 10 to 15 minutes
Why it degrades
A manual three way match is 3 lookups and a comparison, repeated for every invoice. At 40 invoices a month it is a discipline. At 400 it becomes a policy that exists in the controls documentation and a practice that exists for invoices above a threshold, or from new vendors, or when something looks odd.
That is a rational response to a real constraint, and it produces a specific failure mode. The threshold is public inside the company. The invoices that never get matched are the small, routine, familiar ones, which is exactly the profile of a duplicate payment, a quiet price creep, or a vendor billing for a quantity nobody received.
The other degradation is the goods receipt itself. Purchase orders are finance documents and usually exist. Goods receipts require somebody outside finance to confirm delivery, and when that confirmation is an email to a shared inbox, the third leg of the three way match quietly becomes optional.
There is a harder version of the problem, and Too Good To Go has it: almost none of its bills arrive carrying a purchase order number at all. Nothing auto-matches, because there is nothing on the document to match against. A control cannot degrade gracefully when its input is missing, which is why the fix has to start upstream at how the commitment gets raised rather than downstream at how the invoice gets checked.
What changes when it runs on everything
Matching is not judgment. It is comparison, which is the kind of work that does not degrade with volume once a person stops doing it.
In Light a bill matches against its purchase order by amount. The person who ordered the goods confirms they arrived, so the goods receipt is a real confirmation from the requester rather than an inference. Duplicates are caught before approval rather than after payment. Vendor contracts are checked, and conditional routing sends genuine exceptions to a person while everything that reconciles simply posts.
The control did not get automated in the sense of running faster. It moved off a human's attention budget and onto the transaction, where it applies to the 400th invoice exactly as it applies to the 1st.
"It's the only product I've seen that can accurately parse and code our 100+ line invoices from Perk."
Ben Fotheringham, CFO, ControlPlane
In practice
Matched by exception
The control is documented for all invoices and applied to large ones, new vendors and anything that looks unusual. Routine invoices pass unchecked.
In Light
Matched by default
PO match by amount, goods receipt confirmed by the requester, duplicates caught before approval, contract terms checked. Exceptions route to a person.
The difference
Population, not sample
A control applied to every invoice is testable as a fact about the system rather than an assertion about the process.
The speed is a side effect
At Oper Credits a multi-line invoice took 10 to 15 minutes to process and now takes under a minute, with employees submitting by photo in Slack. At All Gravy, bills arrive by email and Light's AI reads and codes them on arrival, so nobody opens them at all.
Those numbers get quoted as efficiency, and they are, but the more interesting consequence is that the control is now cheaper to apply than to skip. Every incentive that used to erode three way matching pointed the same direction: matching costs time, skipping costs nothing today. When the match happens automatically and the exception is what generates work, the incentive reverses.
What an auditor sees
Three way matching is a standard control and gets tested as one. Traditionally that means selecting a sample of invoices and inspecting the supporting documents for each, which tests whether the control operated on those items and infers the rest.
When the match runs on the full population and every step is logged, the testing changes. The auditor pulls 100% of the journal population through the API, sees the match result on every invoice rather than a sample of them, and tests the mechanism instead of reconstructing instances. Audit agents verify the work continuously against policy and produce a monthly control report of what was checked, what passed and what was flagged. Customers at $500M ARR have completed audits on this basis.
A control that provably ran on everything earns reliance. Reliance narrows scope. That is the economic argument for automating a control that most companies already claim to have.
The uncomfortable version
Most finance teams reading this already have three way matching in their controls documentation. The question is not whether to adopt it. It is what percentage of invoices it actually touched last month, and whether anybody could produce that number on request.
If the honest answer is a threshold rather than a percentage, the control is a policy rather than a practice. The gap between those 2 things is where duplicate payments live.
See how Light automates bills end to end, or book a demo.