## TL;DR

3-way matching verifies the invoice against two independent facts: what was ordered (PO) and what arrived (goods receipt). Match on quantity and price within tolerances across all three documents; only matched invoices post automatically, and mismatches route to the buyer or receiver with the specific variance. This is the core control against paying for unordered or undelivered goods.

## Steps

1. Capture the PO: lines, quantities, unit prices.
   Expected: The order baseline.
2. Capture the goods receipt: received quantities per line.
   Expected: The delivery fact.
3. Capture the invoice: billed quantities and prices.
   Expected: The claim.
4. Compare all three within price and quantity tolerances.
   Expected: A match verdict per line.
5. Post matches; route mismatches with the variance detailed.
   Expected: Clean posting plus targeted exceptions.

## When to use

- Goods purchases with receiving
- Designing AP controls
- ERP PO-to-pay flows

## When not to use

- Service invoices (use 2-way)
- Non-PO spend
- Payment execution

## Compatibility

ERP-agnostic; implemented in NetSuite, SAP, Oracle, Coupa, and AP tools.

## Variant phrasings

### 3-way match AP

### PO receipt invoice matching

### three way matching process

## Root cause

Each document alone can be wrong: POs change, receipts miscount, invoices overbill. Three independent sources agreeing is the control; any disagreement is the exception signal.

## Edge cases

- Partial receipts need line-level matching, not header-level
- Drop shipments skip the receipt; fall back to 2-way with acknowledgment
- Returns after matching need credit-memo linkage

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Zh59z08K0jLVRUR0e3Xp7g