Once a company buys against purchase orders, the slow part of accounts payable stops being the typing. It’s the checking. Someone pulls up the PO, asks the warehouse whether the delivery actually arrived, notices the price has gone up since the order and emails the buyer about it. Then they do it again for the next invoice, and the one after that.
We’ve already written about automating invoice processing with AI: getting invoices in, having AI read them, filing and recording them, as we did for the client in our invoice automation case study. This article starts where that one stops, at the decision. Does this invoice match what we ordered and what we received? We wrote the matching rules and ran seven invoices for a made-up bakery group through them, so you can see exactly what comes out.
Two-way, three-way, and why the third leg matters
| Check | Compares | Catches |
|---|---|---|
| Two-way match | Invoice against purchase order | Wrong prices, items nobody ordered, invoices against the wrong PO |
| Three-way match | Invoice against PO and goods receipt | All of the above, plus billing for goods that never arrived or arrived short |
| Non-PO approval | Invoice against a budget owner’s sign-off | Services, utilities and subscriptions that never had a PO |
Most small finance teams do a two-way match by eye, if they match at all. The goods receipt is the leg that gets skipped, because it lives with the warehouse or the kitchen manager rather than with finance. It’s also the leg that catches the most expensive mistakes: paying in full for a delivery that came four bags short.
Where AI fits, and where it doesn’t
The AI step has one job: turn a PDF, photo or scan into fields. Vendor, invoice number, PO number, each line with its quantity and unit price, tax and total. Current models do this well, and in the client project above Gemini handled it. What the model doesn’t do is decide whether to pay. That decision belongs to rules your finance team can read, argue about and change without calling a developer.
Keeping the two apart also makes the whole thing testable. If an invoice is rejected, you can see whether the model misread it or the rule caught a real problem.
The rules, in the order they run
- Is the vendor one we know?
- Do the lines plus tax add up to the total on the invoice?
- Have we already processed this vendor and invoice number?
- Does the PO exist, and is it for this vendor?
- Is every line on the invoice also on the PO?
- Has the quantity billed so far, including this invoice, stayed within what was received?
- Is each unit price within the agreed tolerance of the PO price?
An invoice without a PO number skips the matching and goes to whoever owns that budget. An invoice that fails any rule goes to a review queue with the reason written next to it. Everything else is matched.
What our test run caught
We set up four purchase orders, their goods receipts and seven invoices for a fictional bakery group buying packaging, flour and an oven part. The invoice fields were typed in by hand to stand in for the AI reading step, since that part is well covered elsewhere. The matching rules ran for real, and this is their output:
The flour invoice is the one a two-way match would have paid. Price and items matched the PO exactly, but the warehouse had logged 36 bags, not 40. The oven element had gone up 4.6% since the order, which might be fine, but it’s the buyer’s call, not the automation’s. The rye flour was 0.8% up, inside tolerance, so it went through with a note.
The last two rows show why the running count matters. When Harlow resent H-20417, the duplicate check caught it. Even with a new invoice number it would have failed, because all 500 boxes on the PO had already been billed. H-20466 failed twice: its total was $10 more than its lines and tax, and it billed for boxes that had already been paid for.
Send each exception to the right person
A review queue only saves time if the right person sees each item. Price differences go to the buyer who raised the PO. Quantity problems go to whoever books deliveries in. Duplicates and math errors stay with accounts payable, since the answer is usually a quick email to the vendor.
Whoever resolves an exception records what they decided: approved with a note, credit note requested, waiting for the rest of the delivery. That history is what lets you loosen the rules later with confidence. The queue itself can be a simple internal tool with the invoice PDF, the PO and the receipt side by side.
Posting to the accounting system
Matched invoices become bills in your accounting system, with the PDF attached and the PO number in the reference. In Xero we’d create them as drafts at first, so your accountant approves them in the tool they already use. The same applies to QuickBooks or any system with an API.
After a few months of matched invoices that nobody had to correct, you can let matched invoices under an agreed amount go straight to approved. Exceptions and non-PO invoices keep their human step.
What you need in place first
Purchase orders need to live somewhere a workflow can read: your accounting system, an inventory tool or a database. POs sent as Word documents over email won’t work. Goods receipts need recording too, even if it’s a shared sheet the warehouse updates when deliveries arrive. And you need a vendor list with consistent names, so “Harlow Packaging Ltd” and “Harlow Packaging” are the same supplier.
If receipts aren’t recorded anywhere yet, start with a two-way match and add the third leg once deliveries are being logged. It still removes most of the manual checking.
For the workflow itself, n8n suits higher volumes or data that has to stay on your own servers, and Zapier or Make.com is plenty for moderate volumes. We compare them in n8n vs Make.com vs Zapier.
Mistakes to avoid
Questions we often hear
What is three-way matching in accounts payable?
Checking each invoice against the purchase order (what you agreed to buy, at what price) and the goods receipt (what actually arrived) before it’s paid. If all three agree within your tolerances, the invoice is matched.
Do we need an ERP to do this?
No. Purchase orders and receipts can live in your accounting system, an inventory tool, a database or even a well-kept shared sheet. The workflow just needs to be able to read them.
What happens when an invoice has no PO number?
It goes to the budget owner for approval instead of being matched. If the vendor usually works against POs, the workflow can list their open POs to help the reviewer pick the right one.
Can AI read the line items accurately?
On clear, typed invoices, yes. Poor scans and handwriting are less reliable, which is exactly why the math and matching checks sit after the AI step rather than trusting it.
Will this work with Xero or QuickBooks?
Yes. Matched invoices are created as bills through the accounting system’s API, as drafts at first, with the PDF attached.
