What is the difference between 2-way, 3-way, and 4-way matching?

Use 3-way where a receiving event is real and material: physical goods, inventory, capital equipment, anything where short-shipment or non-delivery is a live risk. Use 2-way where there's nothing to receive - software, subscriptions, professional services billed against an SOW - because forcing a "receipt" on intangible spend just manufactures a step someone fakes. Layer dollar thresholds on top (higher-value POs earn the extra leg) and tighten by vendor for chronic discrepancy offenders. The goal is that every match leg either prevents a real error or confirms a real event; a leg that does neither is overhead.

Header-level matching compares totals - invoice total against PO total - and passes if the bottom lines agree. Line-level matching compares each invoice line against its PO line: this item, this quantity, this rate. Header matching is faster but blind: it'll pass an invoice that's right in total but wrong line-by-line (overbilled on one item, under on another), which is exactly how overbilling hides. Line-level is the standard for any PO with multiple items, and it's what makes partial deliveries, progressive billing, and substitutions tractable. The cost is that line-level matching needs the invoice parsed to the line - which is where AI extraction earns its keep.

Rules-based matching applies fixed logic: exact PO number, exact line order, totals within a set tolerance. It works when invoices are clean and consistent and breaks the moment a vendor reorders lines, bundles items, uses different descriptions, or omits the PO number. AI-powered (cognitive) matching reads the invoice the way a person would - identifying the likely PO from vendor and content even without a quoted number, mapping invoice lines to PO lines by description, quantity, rate, and amount rather than position, and surfacing only the genuine discrepancies. It doesn't replace human judgment on exceptions; it removes the manual reconciliation on everything that should obviously match.

Match at the line level on content rather than position - description, quantity, and rate - so reordered or renamed lines still resolve, and route the genuine non-matches to exception review. Position-dependent matching breaks on the first vendor who formats differently; content-based (ideally AI-assisted) matching tolerates real-world invoices.

Allocate each invoice line to its originating PO and draw down each PO's balance accordingly. The matching system has to support many-POs-to-one-invoice, or AP ends up splitting the invoice manually; confirm this case explicitly in any tool evaluation because it's common and frequently unsupported.

Each invoice matches as a partial draw against the PO's remaining line availability, accumulating consumed quantity/amount until the PO is fully invoiced. Progressive matching requires the system to track remaining availability per line - which is also what tells you when a PO is over-billed.

Goods: 3-way, line-level, quantity-and-price against PO and receipt. Services: 2-way against the PO/SOW with a sign-off or milestone confirmation standing in for physical receipt. Don't impose goods-style quantity matching on services - match against contracted value and verified delivery instead.

Normalize units before matching - maintain conversion factors (one case = twelve eaches) so a PO in cases reconciles to an invoice in eaches. Unresolved UOM mismatches are a top source of false exceptions; fix them with conversion logic, not by loosening tolerances.

Compare invoiced quantity to received quantity (not just ordered): if you received less than billed, you have a short-ship or an over-bill, and the invoice should hold pending resolution. This is exactly the error 3-way matching exists to catch - the receipt is the arbiter.

Native ERP matching keeps data in one place but is often rigid (exact-match, position-dependent, weak on AI line mapping) and pushes exception work onto AP. An AP automation layer reads and matches invoices with more flexibility and AI assistance, then posts the result to the ERP as system of record. The deciding factor is your exception volume: clean PO-only spend can live in the ERP; exception-heavy or inconsistent-vendor environments benefit from a smarter layer.

PO creation with line detail, a recorded goods receipt against the PO, and invoice matching that compares all three before payment - with an exception path for variances. The minimum is that no inventory invoice posts without a receipt behind it and a documented resolution for any mismatch.

Either add estimated freight/tax lines (or header charges) to the PO so they match, or set tolerance and handling rules that accommodate predictable add-ons without forcing every invoice to exception. Charges that are knowable at PO time belong on the PO; truly variable ones belong in tolerance design.

Confirm receipt at delivery (so the received-quantity truth exists early), but run the binding three-way match at invoice entry, when all three documents are present and you're deciding whether to pay. Receiving feeds the match; the match happens when money is on the line.

Stampli performs automatic 2-way and 3-way matching at the line level inside an ERP-aligned AP workflow. When automated matching is enabled, Stampli AI detects the PO (including by vendor and content when no PO number is quoted), reads invoice lines, compares them to PO lines on description, quantity, rate, and amount, applies tolerance-based routing, and surfaces only the discrepancies that need judgment - so AP works exceptions instead of reconciling every line. Receiving status connects PO, receipt, and invoice context for 3-way scenarios, and all of it sits in the same platform as the PO and the budget, so a match isn't a cross-system reconciliation. This is part of Stampli AI's measured work - Stampli AI performs on average 87% of finance work across 2,700+ unique fields, with every suggestion subject to human review and approval before posting.