How Do You Three-Way Match an Invoice Before Paying It?

What a three-way match actually decides

The question underneath the paperwork is narrow: do ordered, received, and invoiced facts agree within tolerances you chose in advance? A match that answers something broader — whether the supplier is trustworthy, whether the budget allows it — has stopped being a match and started being a guess.

Most mismatches are boring and line-specific: one SKU received in two deliveries and invoiced once, a unit price that drifted past tolerance, an invoice for a line that was never ordered. The value of the review is keeping those causes separate instead of collapsing them into one total that explains nothing.

What to bring

Bring the invoice, the purchase order, and every goods receipt for the project, in whatever form you have them. Bring the tolerances and currency rules the controller wants enforced — quantity tolerance, unit-price tolerance, and whether conversion is ever allowed.

If a receipt exists only as a paper delivery note, transcribe it first. The match can only compare documents that exist; it will not invent one to close a gap.

Step 1: Fix the identifiers before anything else

Linking happens only through explicit purchase-order IDs and line SKUs. If an invoice references a PO number that does not exist, that is already an exception worth naming — not a lookup problem to solve by guessing which order was meant.

Step 2: Sum receipts per SKU

Received quantities are summed across receipt lines per SKU, because partial deliveries are normal and a single-receipt assumption manufactures false variances. Keep original currencies throughout; a price comparison across currencies is not a comparison.

Step 3: Compare quantities and prices against tolerances

For each PO line, compare invoiced quantity against summed receipts, and invoiced unit price against the ordered price. A finding enters the report only when the variance exceeds the tolerance you supplied — inside tolerance is matched, not suspicious.

Step 4: Read the holds, not just the totals

Every hold carries its reason from a closed list: already-processed, receipt-missing, currency-conflict, invoice-line-missing, quantity-variance, unit-price-variance. Duplicate invoice IDs short-circuit the whole match and come back as duplicates with no second path.

Step 5: Hand off for the controller decision

The report ends the review; it does not pay anyone. MatchHold never approves, schedules, or records a payment — releasing money stays with the people authorized to release it. What changes is that the decision starts from named facts instead of a stack of PDFs.

Verification

A second reviewer can take the report and trace any line back to its source values: SKU, both quantities, both prices, variance, tolerance. If a claim on the report cannot be traced to a document you supplied, the review failed — nothing should be there that the sources did not support.

Limits that stay in this job

Missing receipts stay holds; they are not inferred or filled in. A clean result means only that the compared fields matched — it is a finding, not a payment approval. MatchHold never approves, schedules, or records a payment.

Currency conflicts are reported, never converted silently. Cross-project documents are rejected even under the same organization. The review uses only the tolerances present in the input; none are invented.

What MatchHold does in this workflow

MatchHold is a conversation-led AP review workspace. You supply the invoice, purchase-order, and receipt files for one project plus the tolerances to enforce; it links them by purchase-order ID and SKU, runs the comparisons, and returns the exceptions-only report with document IDs, line findings, and hold reasons.

You still decide what gets paid. The workspace holds the line between a completed review and a released payment.