Invoice matching: automate routine checks and route exceptions
Compare invoices with purchase orders and receipts, set defensible tolerances, and give every mismatch a clear owner.
Qonnex Editorial · Business operations and AI consulting
A supplier bills for 100 units. The purchase order also says 100. The warehouse has recorded 80. An invoice automation workflow can read every field correctly and still make the wrong decision if it treats those records as equivalent.
Invoice matching gives accounts payable a way to compare the invoice against the purchase order and, where required, the receiving record. It also gives the team a way to explain why an invoice was held. The useful question is whether the system can make the routine comparisons consistently and send the rest to someone who has the evidence to resolve them.
What invoice matching checks
A purchase order records what the buyer authorized. A receipt records what the buyer accepted or received. The invoice records what the supplier requests to be paid. Those three records answer different questions. A match policy specifies which records and fields must agree, how much variance is allowed, and what happens when they do not.
Microsoft’s invoice matching documentation illustrates checks for line prices, totals, charges, and receipt quantities. Oracle’s invoice match approval levels distinguish matching choices and approval requirements in its platform. The fields and screens depend on your software. Write down the control before configuring it.
| Check | Evidence compared | What it can uncover |
|---|---|---|
| Two-way | Invoice and purchase order | Price or quantity on the invoice differs from what was ordered. |
| Three-way | Invoice, purchase order, and receipt | The invoice bills for units that the buyer has not yet recorded as received. |
| Non-PO review | Invoice and approved supporting evidence | Missing coding, authorization, or evidence required by the separate non-PO process. |
The two-way or three-way choice is a finance policy decision. A service purchase might have a different form of acceptance evidence from a shipment of goods. Define what counts as receipt or acceptance for that category before asking software to check it.
Work through a partial delivery
Suppose a fictional purchase order, PO-1042, authorizes 100 units at $12 each. The warehouse posts a receipt for 80 units. The supplier sends an invoice for all 100 at the agreed unit price.
A comparison with the purchase order can confirm the unit price and the ordered quantity. A receipt check still has a question: the invoice bills 20 more units than the receiving record supports. The next action depends on the contract and finance policy. The receiving team may confirm that the last 20 were delivered and the receipt is late. Procurement may confirm that the supplier should bill only the first shipment. Accounts payable (AP) may be authorized to process the received portion separately if its system and policy allow it.
Record the original invoice and the matched lines before any correction. If an invoice is split or replaced, reconcile the total billed against the purchase order and prior payments so the same units do not get processed again. The point of the hold is to obtain evidence and a decision. A missing receipt can reflect an ordinary timing difference.
Match lines before interpreting totals
Invoice totals can agree while individual lines differ. A price increase on one item can offset a price decrease on another. A case of 12 billed as a single unit can also look wrong if the two systems disagree about units of measure. Compare the lines that represent the same purchase before interpreting a header total.
Start with the legal entity, vendor, and purchase order reference. Then confirm line identity, unit of measure, currency, net unit price, and quantity. Map freight, discounts, and taxes to the checks your policy actually requires. Keep invoice extraction confidence visible if you use software to read incoming documents. A reviewer needs to know whether a discrepancy came from the supplier's record or a misread field. The broader invoice automation implementation guide covers capture, exception ownership, and rollout.
Consider which record owns each field. If purchasing maintains unit conversions while AP maintains vendor aliases, a resolution in one system should not silently rewrite the other. The CRM–ERP integration guide describes how to assign authority and test handoffs between systems.
Set tolerances that finance can defend
A tolerance defines how much variance a comparison can accept. It can use an amount, a percentage, or a rule combining the two where your system supports it. Choose thresholds from finance policy, the value and risk of the purchase, and the cost of investigating routine differences. An example threshold in vendor documentation is an illustration for that product.
Test boundary cases as well as obvious mismatches. If a fictional policy allows a rounding difference of up to $0.50 on a line, test $0.49, $0.50, and $0.51. Then check how the system handles multiple individually acceptable differences on one invoice. Define who can change thresholds and where the effective rule version is recorded. A changed rule should be explainable when someone audits an invoice approved last month.
Keep unknown vendor identities, conflicting currencies, missing required evidence, and suspected duplicates on distinct paths. A permissive dollar threshold cannot establish that the right vendor was paid or that a receipt exists.
Route the exception to the person who can resolve it
A useful queue shows the invoice and order references, affected line, expected and observed values, and missing evidence. Each reason has a named owner and an escalation path.
| Reason for the hold | First reviewer | Evidence needed |
|---|---|---|
| Required receipt missing | Receiving or service owner | Posted receipt, signed acceptance, or confirmation the delivery is still open. |
| Invoice price differs from the order | Procurement | Agreed price, authorized order change, or supplier correction. |
| Invoice field appears misread | AP or intake reviewer | Original document and corrected field value. |
| Possible duplicate | AP reviewer | Vendor and invoice history, prior posting or payment, and supporting documents. |
Log who resolved the hold, what changed, and the underlying evidence. Keep an unresolved item visible if a downstream response is missing. An uncertain outcome needs reconciliation before another invoice or transaction is created.
Prove the workflow before relying on it
Run a limited pilot with a representative invoice population. Include exact matches, partial deliveries, missing receipts, differences near a tolerance, disputed prices, non-PO invoices, and duplicates. For each test, specify which record wins, the expected status, the reviewer, and the next action. Ask finance to trace accepted and held invoices through the resulting audit record.
Track manual touch time, exception rate by reason, time to resolution, and incorrect automatic passes. Break the figures out by supplier or document class if the mix changes. A written savings baseline makes the comparison useful, while measuring automation returns requires counting the new review work too.
If a large share of holds comes from missing receipts, improve how receipt evidence is posted before relaxing the match. Give AP a reliable rule for what can proceed and a clear record of what needs human judgment. That is a practical starting point for operational efficiency work.