How to Automate Invoice Matching Without an AP Team
Every supplier invoice gets matched by hand against the PO and the goods you actually received, and it rarely lines up. Here is how mid-market distributors catch price and quantity mismatches without an AP team.
TL;DR
- Every supplier invoice gets checked by hand against the purchase order and against what actually arrived at the dock, and it almost never matches both.
- Two mismatches do most of the damage: the bill is for the full order when only part shipped (quantity), and the price billed is not the price agreed on the PO (price). Add duplicate bills and payment falling due while the goods are still on the water.
- Your ERP only checks at goods receipt, weeks later, and only for documents already keyed into it. It never reads the supplier bill the day it lands.
- aradus reads the bill the day it arrives, matches it against the PO and the goods received, flags the mismatch, versions the document, and raises one decision: pay what is right, hold the rest. Ambiguous calls go to a person.
- It is a layer on top of the ERP you already run, not an AP platform you adopt and operate, and it stops at the decision, not the payment. Book a working session.
The supplier bill is where the money leaves, and it is matched by hand
A supplier invoice arrives as a PDF or in the body of an email. Before anyone pays it, someone has to check it, line by line, against two other things: the purchase order that says what you agreed to buy and at what price, and the goods receipt that says what actually turned up at the dock. When all three agree, the bill is clean and the payment is easy. The trouble is that all three rarely agree.
Real life gets in the way in a few recognizable ways. The bill is for the full order, but only part of it shipped, so you are being asked to pay for goods that are still on the water or never came. The unit price on the invoice is not the price you agreed on the PO, off by a few percent, on one line out of forty, in a currency that moved. The same bill arrives twice, once as a proforma and once as a final, and nothing stops you paying both. And on credit terms, the invoice clock starts the day it is issued, so payment can fall due weeks before the container lands and before anyone has confirmed what actually arrived.
Each of those is a held decision. Someone has to notice it, pull up the PO and the receiving record, work out what is really owed, and either short-pay, query the supplier, or hold the balance. Miss it and you overpay, and the two that hurt most are the quiet ones. A short shipment invoiced in full is at least visible, the goods are missing. A price that is a little off is invisible: nothing is missing, the bill looks normal, and the margin just leaks, one line at a time, until someone happens to catch it.
Why this work never lived in your ERP
It is fair to ask why the ERP does not just handle this. Most ERPs can do a three-way match, comparing the PO, the goods receipt, and the invoice, and posting the ones that line up. But that match only works on documents already structured and sitting inside the ERP, and it only happens at goods receipt, which is often weeks after the bill first landed in someone's inbox. Getting the supplier bill out of a PDF and into the ERP in the first place, and resolving the exceptions when the numbers do not agree, is still manual.
That is the same pattern behind most of the work around a distribution business: your ERP was never going to do this. An ERP is a system of record. It keeps the truth once the truth is inside it. It does not go and read the bill the day it arrives, compare it to what you agreed and what you received, and raise the exception. Reading an inbound document and judging a mismatch is an action out in the world, and a system of record does not take actions in the world.
So the supplier bill sits in the gap around the ERP, the same gap where order entry, supplier chasing, and logistics already live. If creating the purchase order is the front of procure-to-pay, matching the supplier's bill against it is the back, and the back half is still done by hand.
How aradus connects
aradus sits on top of the systems you already run. It reads the purchase orders and the goods receipts already in your ERP, so it knows what you agreed to buy, at what price, and what actually arrived. Then it does the part the ERP cannot: it reads the supplier bill the day it lands, wherever it lands, and checks it against both.
How it works
It reads the bill the day it lands. The supplier invoice arrives as a PDF or an email, in whatever layout that supplier uses. aradus reads it and pulls the lines out, so the bill is understood on the day it arrives, not keyed by a person weeks later at goods receipt.
It matches against the PO and against what you received. aradus checks the bill two ways at once: against the PO for price and terms, and against the goods receipt for quantity. That is where the two mismatches get caught. Invoiced for the full order when only part shipped shows up against the receipt. Billed at a price that is not the agreed price shows up against the PO. Price variance is a first-class check here, not a footnote, because it is the one that leaks margin silently when nothing physical is missing. A duplicate or re-issued bill gets caught the same way, before it is paid twice. Catching the mismatch here, at goods receipt rather than after the cash has gone out, is the 1-10-100 rule applied to the money side.
It versions the document. Supplier bills get re-issued: a corrected invoice, a credit note, a proforma followed by a final. aradus keeps the versions linked so the trail is auditable and you are always matching against the current bill, not an old copy of it.
It raises one decision. For each bill, aradus surfaces one clear call with the mismatch laid out: pay what is right, hold the rest. Pay for what actually shipped and hold the balance. Query the line where the price does not match the PO. Reject the duplicate. You are deciding, not hunting.
It holds for a person when the call is not obvious. A small price difference might be an agreed surcharge, a partial shipment might be exactly what you asked for, a tolerance might be inside what you accept. When the right answer is not clear-cut, aradus does not guess and it does not auto-approve. It puts the decision, with the PO and the receipt alongside it, in front of a person. The routine matching gets automated. The judgment stays with you.
The manual desk next to aradus
| Matching supplier bills by hand | With aradus |
|---|---|
| The bill sits in an inbox until someone keys it at goods receipt, weeks later | The bill is read and understood the day it lands |
| A person pulls up the PO and the receiving record to compare, line by line | Matched against the PO (price, terms) and the goods receipt (quantity) automatically |
| Price variance slips through because nothing is physically missing | Price-not-agreed is a first-class flag, caught before payment |
| Duplicate and re-issued bills risk being paid twice | Versions linked, duplicates flagged |
| Every exception is a manual investigation | One clear decision per bill, the hard calls held for a person |
What aradus does not replace
aradus is not an accounts payable platform you adopt and run alongside your ERP, and it is not a payments tool. It does not cut the cheque, run the disbursement, or manage your customer-side receivables and collections. It reads and matches the supplier bill, flags what does not line up, and hands you the decision. The paying still happens where it happens today, in the ERP or the bank, once you have decided what is actually owed. It matches and flags on top of the ERP you already run.
What good automation needs first
This works when two things are true. First, your purchase orders and goods receipts actually live in your ERP, because that is what aradus matches the bill against. If what you agreed and what you received are not recorded anywhere, there is nothing to match to, and that is the thing to tidy first. Second, supplier bills reach a place aradus can read, one inbox or channel rather than five people's personal mailboxes. Both are smaller jobs than they sound, and they are the same foundations that make the rest of the back office automatable. Getting the bill matched is also the natural neighbor of getting the order into the ERP cleanly in the first place, because the PO you raised is the thing the bill has to match.
The matching does not have to be manual
The check will not stop being necessary. Every supplier bill still has to be reconciled against what you agreed and what you got. What can change is who does the reconciling. aradus takes the reading, the matching, and the flagging off a person's plate, and leaves them the one thing that needs a human: the decision on the bills that do not line up. If you want to see what that looks like against your own suppliers and your own POs, book a working session.