Three-Way Match: Invoice, PO, and Goods Receipt Matching

Three-way matching is a join across three finance documents. An invoice from the supplier. A purchase order from your procurement system. A goods receipt note from your warehouse or receiving team. If all three line up on supplier, amount, quantity, and item, the invoice passes for payment. If any one of them disagrees, the invoice becomes an exception that needs review.

The control exists for separation of duties. The buyer placed the order. The receiving team confirmed what arrived. The finance team is about to move money. Each document is generated by a different function, and the three-way join catches drift between them: short deliveries, price changes after the PO was cut, invoices for goods never received, or invoices issued twice against the same PO.

The join key is the PO number. Everything else hangs off that join. Vendor must agree across all three. Amount must agree between invoice and PO within a tolerance band. Quantity must agree between invoice and goods receipt. Line description is the soft check that catches outright substitutions when other fields happen to line up.

Skipping three-way match does not feel expensive until it is. The four losses compound: duplicate payments, vendor fraud, audit findings, and working capital trapped in disputes.

Duplicate payment. A supplier sends the same invoice twice, intentionally or not. Duplicate-invoice checks should compare the supplier, invoice number, amount, and supporting records before payment. A PO number alone is not unique: one purchase order can legitimately have several invoices, including partial deliveries.

Vendor fraud surface. An invoice can claim payment for goods never delivered. Checking an independently recorded goods receipt helps detect that discrepancy before approval, alongside supplier verification, segregation of duties, and other payment controls.

Audit findings. External auditors test three-way match evidence on sampled invoices. Inability to produce the goods receipt for a paid invoice is a recurring control finding in internal audit reports, even for companies with otherwise tight controls.

Working capital leakage. Amount and quantity variances that go unflagged at invoice receipt show up months later as supplier credits, debit notes, and disputed balances. Each one ties up cash and costs reconciliation time.

The matcher above classifies every invoice into one of eight states: matched, or one of seven exception types. Each exception is a real-world failure mode an AP team sees weekly.

1. Amount variance. Invoice and PO agree on supplier and line items but the amount differs beyond the tolerance band. Common causes: pricing was renegotiated after the PO was issued, freight or fuel surcharges were added, or the supplier billed at a higher rate than agreed.
2. Quantity variance. The supplier billed for more than the goods-receipt note confirms. Either the warehouse under-counted, the supplier shipped short, or the supplier billed before the full shipment arrived.
3. Missing PO. An invoice arrives referencing a PO number your procurement system has no record of. Often a rogue spend pattern: someone in the business committed to a supplier without raising a PO first. Sometimes a typo on the supplier's invoice.
4. Missing GR. Invoice and PO match, but no goods receipt has been logged. Either the receiving team has not posted the receipt yet, or the goods were never delivered and the invoice is fraudulent.
5. Vendor mismatch. The invoice and PO carry the same PO number but are from different suppliers. Most often a data-entry error on the supplier's side, occasionally a fraud signal where a fake supplier piggybacks on a real PO number.
6. Line-item substitution. The supplier delivered something different from what was ordered. The PO is for office chairs, the invoice and goods receipt are for executive desks. Often legitimate (back-order substitution) but always requires approval.
7. Duplicate invoice. The same PO appears on two or more invoices. The classic AP control gap. The duplicate may be intentional fraud, or the supplier's billing system mis-fired. Either way payment must be held until the duplicate is investigated.

Manual three-way match works at small scale and breaks slowly. A two-person AP team handling 200 invoices a month can hold the three documents side by side in a spreadsheet, eyeball the join, and clear the queue in a day. Five-hundred invoices and the spreadsheet becomes a multi-tab artifact that one person fully understands. A thousand and the team starts skipping the GR leg, then the amount tolerance, then the duplicate check.

Each shortcut is rational at the moment it is taken. None of them are visible from outside the team. The audit finding shows up two quarters later, the duplicate payment surfaces when the supplier asks for a credit, and the fraud, if there was any, was paid out months ago.

Automation does not eliminate exceptions. It surfaces them. A well-built three-way match agent runs every invoice against the full rule set, flags the 5 to 15 percent that need review, and shows the reviewer exactly why each one was flagged. The reviewer's time goes from chasing 100% of invoices through three spreadsheets to making a judgment call on the 10% the agent could not clear.

The matcher on this page is honest about its limits. It runs in your browser, takes structured rows as input, joins them on PO number, and applies fixed rules. That is enough to demonstrate every canonical exception type. It is not enough to run against your real AP workflow.

Real AP workflows feed three-way match with messy inputs. Invoices arrive as PDFs, sometimes scanned, sometimes machine-generated, sometimes embedded in email bodies with no attachment. POs sit in an ERP behind export jobs that drop fields silently. Goods receipt notes are often handwritten and photographed by the receiving team.

A production three-way match system has to handle three classes of work the client-side tool cannot:

• Document intelligence. OCR the invoice PDF, extract line items, vendor metadata, totals, and tax. Same for the goods receipt note. The match runs on the extracted fields, not on a spreadsheet someone typed.
• Fuzzy normalization. “Acme Corp” on the invoice, “Acme Corporation Inc.” on the PO, and “ACME CORP” in the vendor master may refer to the same supplier. Confirm identity against verified supplier records; similar names alone do not establish that two businesses are the same.
• Agentic exception routing. A flagged invoice does not stop with a flag. An agent decides whether to ask the buyer for approval evidence, request a corrected invoice from the supplier, hold for receiving to post the GR, or route to a human reviewer with the full context attached. Each decision is policy-driven and logged for audit.

The client-side tool above demonstrates the matching logic. The full system wraps it with the document intake, the normalization layer, and the routing agent.

We scope matching around your purchase orders, receipts, invoices, approval rules and accounting-system interfaces. Available exports and APIs determine the integration approach; a named accounting platform is not a promise of an existing connector.

Price, delivery time, support and acceptance criteria are agreed after reviewing that scope. The browser demonstration is not a packaged production AP system.

Related case study for the kind of regulatory document workflows this style of build handles: we shipped the EU TRACES platform integration for a client's sustainability compliance program. Public review from Matthew Baldwin: “Aditi and her team did an excellent job with the development of an API with the EU's TRACES platform for our business. They are extremely professional, and we were very impressed by their skills, knowledge and reactivity.” That project is evidence of regulatory integration work, not a production three-way-match implementation or proof of AP outcomes.

• Workflow automation: the full control-layer model
• Invoice Extractor: extract structured fields from PDF invoices
• Accounts Payable Controls Checklist: payment-release and approval checks