Before you pay a supplier invoice, it should be checked against what you ordered and what you actually received. That check is called invoice matching, and for a Hong Kong trading business it is the difference between paying for goods that arrived at the price you agreed, and paying for a partial shipment at a quietly increased price because the numbers looked close enough.
This article explains purchase order and invoice matching in plain terms: the three documents involved, when two-way matching is enough and when you need three-way, how to handle partial deliveries and price differences, and how to run an exception queue so that mismatches go to a person for review instead of through automatically. It is an operational workflow guide, not accounting advice.
The three documents and what each one proves
The purchase order (PO) is what you agreed to buy: items, quantities and prices, before anything ships.
The delivery note is the supplier's statement of what they say they sent. Our practical recommendation is to treat it as a claim, not as independent proof of what you received and accepted, and to match against your own goods-received record. Separately, Microsoft's documentation on three-way matching policies describes three-way matching as comparing the invoiced quantity against the recorded product-receipt quantity — the quantity your team books in when goods arrive.
The invoice is what the supplier is charging you. Matching is the process of confirming these line up before payment, and where they do not, the differences are treated as matching discrepancies to be investigated — as described in Microsoft's accounts payable invoice matching overview.
Two-way or three-way
Two-way matching compares the invoice to the PO — prices and amounts. It suits cases where there is nothing physical to receive, such as a subscription, a retainer or professional fees. It is not automatically sufficient on its own: someone still has to confirm the service was actually delivered or performed, and an authorised person still has to approve payment.
Three-way matching adds the third check: the quantity you received and accepted against the quantity invoiced. Use it for physical goods. This check helps prevent payment for a case that never arrived.
Systems with configurable matching policies let you set tolerances — a small allowable difference, usually on price — so that trivial rounding does not create work. A tolerance is a business policy you decide on purpose. It is not a legal rule, and it is not permission to pay an invoice you know is wrong. Keep it tight enough that a real error still stops.
Getting the invoice into a form you can compare
Matching needs the invoice as structured data: supplier, invoice number, line items, quantities, prices, totals. Structured extraction tools can produce this from a PDF, and Microsoft's invoice processing model documentation shows the kind of fields such tools return, including line items. Use those extracted fields only as the input to matching. The matching logic — what counts as a pass, what goes to the exception queue — is your rules, not the tool's.
Worked example: a partial delivery with a price change
Illustrative example — 示範例子（非真實客戶資料）.
Purchase order KLN-5567
On a phone, scroll sideways to see the full table.
| Item | Qty ordered | Unit price (HK$) | Line total (HK$) |
|---|---|---|---|
| Item A | 50 | 40.00 | 2,000.00 |
| Item B | 30 | 120.00 | 3,600.00 |
| PO total | 5,600.00 |
Delivery note DN-8801: 50 × Item A, 20 × Item B (10 on back-order).
Your goods-received check: 50 × Item A accepted; 18 × Item B accepted (2 units damaged in transit, rejected).
Supplier invoice INV-3390
On a phone, scroll sideways to see the full table.
| Item | Qty invoiced | Unit price (HK$) | Line total (HK$) |
|---|---|---|---|
| Item A | 50 | 40.00 | 2,000.00 |
| Item B | 20 | 126.00 | 2,520.00 |
| Invoice total | 4,520.00 |
Matching result
- Item A: ordered 50, received 50, invoiced 50; price 40.00 = 40.00. Full match — a supported value of HK$2,000.00.
- Item B — quantity: invoiced 20, but only 18 were received and accepted. Exception on 2 units.
- Item B — price: invoiced 126.00 against a PO price of 120.00. That is HK$6.00 per unit, a 5% increase. Exception — needs sign-off from whoever owns the supplier relationship.
Value supported by accepted quantities at PO prices: Item B, 18 × 120.00 = HK$2,160.00; with Item A, 2,000.00 + 2,160.00 = HK$4,160.00. This figure is a reconciliation result, not an authorisation and not an entitlement to a partial payment. A designated person resolves the invoice with the supplier under agreed terms — a credit note, a revised invoice, or an approved partial payment — before anything is released.
What goes to the exception queue: invoice total 4,520.00 − supported value 4,160.00 = HK$360.00. That is 2 rejected units billed at the invoiced price (2 × 126.00 = 252.00) plus the price increase on the 18 accepted units ((126.00 − 120.00) × 18 = 108.00); 252.00 + 108.00 = 360.00.
The undisputed part is cleared for payment once the designated person has confirmed the terms; the HK$360.00 is held while they resolve it with the supplier — a credit note for the 2 rejected units, and a decision on whether the higher price is accepted.
The exception queue
Every mismatch becomes one dated row:
On a phone, scroll sideways to see the full table.
| PO / DN / invoice refs | Difference (qty / price / total) | Reason code | Owner | Resolve by |
|---|---|---|---|---|
| KLN-5567 / DN-8801 / INV-3390 | Item B: 2 rejected units; +HK$6.00/unit; HK$360.00 | REJECTED + PRICE-UP | Purchasing lead | 2026-09-12 |
Nothing is paid out of the exception queue automatically. Someone reads it, decides, and records the outcome.
Useful reason codes: PARTIAL (balance to follow), SHORT (fewer units delivered than invoiced), REJECTED (units delivered but not accepted — damaged or wrong — yet still billed), OVER (more delivered than ordered), PRICE-UP (unit price above PO), FREIGHT (charge added on the invoice but not the PO), FX (currency movement), DUP (possible duplicate invoice), QUERY (supplier contacted, awaiting reply).
What should go to review before payment
- The invoiced quantity is more than you received and accepted.
- A unit price is above the PO by more than your agreed tolerance.
- There is a line on the invoice that was never on the PO.
- A second invoice arrives with the same number, or the same supplier, amount and date — a possible duplicate to compare against the original, not to reject on sight.
Do not configure any of these to approve automatically, and do not release payment from the exception queue without a person deciding. Matching policies and tolerances like these are configurable business controls you choose, not legal rules.
For where this sits in a wider back-office, see our list of small-business tasks worth automating and a walk-through of working demos. If you want to map your own PO-to-payment process, tell us how your suppliers invoice you and we will show you where a matching step would catch the most.
FAQ
Is a supplier's delivery note enough proof that goods arrived? Treat it as their statement of what they sent, and match against your own record of what was received and accepted. Microsoft's three-way matching documentation describes three-way matching as using the recorded product-receipt quantity for this comparison.
What price tolerance should we set? That is a policy decision. One conservative starting policy is to allow no price tolerance beyond rounding, then widen it deliberately for specific suppliers if there is a reason to. A tolerance should never be wide enough to wave a real error through.
How do we handle freight or handling charges added on the invoice? Treat a charge that was not on the PO as an exception. Decide in advance who approves it and up to what amount.
Can the matching itself be automated? A project could compare extracted invoice lines against the PO and the goods-received record and sort them into "matched" and "exceptions" — as covered in the accounts payable matching overview. The exceptions still go to a person, and releasing a payment is always a human decision.