How to match invoices to purchase orders

A purchase order is a promise to buy; an invoice is a request to be paid. Matching them answers one question — is this invoice asking for exactly what we agreed to? — across four dimensions: the supplier, the items, the quantities, and the unit prices. A fifth, the totals, is a consequence of the other four and is the least useful thing to check on its own.

The reason totals are a weak check is that they agree by accident more often than you would expect. An invoice that bills ten units at $12 instead of twelve units at $10 has the right total and the wrong everything else. Header-level matching catches the invoice with no PO; only line-level matching catches the invoice with the wrong lines.

Two-way matching compares the invoice against the purchase order. It confirms you agreed to buy this, at this price. It does not confirm you received it, which is why it is usually reserved for services, subscriptions, and low-value goods where the cost of a receiving step outweighs the risk.

Three-way matching adds the goods-received note — the delivery note, packing slip, or warehouse receipt that records what physically arrived. Now the invoice has to agree with both what was ordered and what was received. A supplier that ships eight and bills ten is caught here and nowhere else. It is the standard for physical goods, and most audit frameworks expect it above a materiality threshold.

Some teams talk about four-way matching, adding an inspection or quality-acceptance record. It is the same idea with one more document, and the same mechanics apply.

The purchase order is structured — it came out of your own system. The invoice is not. It arrived as a PDF from the supplier's system, in the supplier's layout, with the supplier's part numbers and the supplier's description of each item. Before any comparison can happen, someone has to read that PDF and translate it into the same shape as the PO. In most accounts-payable teams that translation is a person with two windows open.

That is where the errors get in. The comparison itself is not hard; a spreadsheet can do it. The transcription is hard, because it is repetitive, the layouts differ per supplier, and a wrong quantity looks exactly like a right one. The matching failure most companies experience is not a failure of matching logic. It is a failure of data entry upstream of it.

• Supplier part numbers differ from internal SKUs, so line pairing needs a lookup table nobody maintains.
• Descriptions differ in wording — "Blue widget 10pk" against "WIDGET-BLU x10" — so exact-text matching fails on items that are the same.
• Unit of measure and pack size change the arithmetic: 1 case of 12 versus 12 units.
• Partial deliveries and split invoices mean one PO maps to several invoices and the match is many-to-one.
• Freight, surcharges and taxes appear on the invoice but not on the PO, and need to be classified as acceptable differences rather than mismatches.

No real-world match is exact. Prices are quoted before a currency moves; suppliers round; freight is estimated. A matching process that stops every invoice with a one-cent difference will be switched off within a month. The fix is a tolerance policy: a rule, agreed in advance, for how much variance is acceptable per dimension before the invoice is held.

Typical policies allow a small percentage or absolute variance on unit price, zero variance on quantity for physical goods, and a separate allowance for freight and surcharge lines. What matters is that the rule is written down and applied by the system, not decided by whoever is matching that day. The invoices inside tolerance flow through; the ones outside it stop and go to a person.

Automation does not start with matching software. It starts with getting both documents into the same structured shape, so that the comparison is a query rather than a read.

• Define one field schema for order documents: PO number, supplier, line SKU, description, quantity, unit price, line amount, total. Use it for POs, invoices and delivery notes alike.
• Extract every incoming invoice into that schema. This is the step most teams skip, and it is the step that makes everything downstream possible.
• Normalise supplier part numbers to your SKUs with a lookup against your item master; where no mapping exists, pair lines by semantic similarity of the description rather than exact text.
• Verify the invoice against itself first: does unit price times quantity equal the line amount, and do the lines sum to the total? Arithmetic errors are the cheapest to catch and the most embarrassing to pay.
• Match header fields on the PO number, then match lines within the matched PO. Apply your tolerance policy per dimension.
• Route only the exceptions to a reviewer, with the invoice, the PO and the specific disagreement in front of them. Post the matches straight to the ERP.
• Keep an audit trail of who approved what and when. Auditors ask for it; so does the supplier when they dispute a short payment.