# Three-Way Match

> The control that pays a vendor only when the invoice, the purchase order, and the receiving record all agree.

- Source: https://briq.ai/acu/object/three-way-match
- Department: Cost, Billing & Accounting (https://briq.ai/acu/department/cost)
- Catalog code: CST 209 · Level: Practitioner · Track: Finance · 10 min read
- Also known as: 3-Way Match, PO Matching, Invoice Matching, Purchase-Order Match

## Definition

A three-way match is the accounts-payable control that authorizes payment of a vendor invoice only when it agrees, within tolerance, with the purchase order that authorized the purchase and the receiving record that confirms the goods or services arrived. The three documents answer three distinct questions: did we agree to buy this and at this price, did we actually receive it, and is the vendor billing what was agreed. It is not merely comparing an invoice to a purchase order, which is a two-way match; the receiving leg is what distinguishes it and what stops payment for goods never delivered. The three-way match is the single most important preventive control in construction payables, sitting between a vendor's demand for money and the release of cash, and its rigor determines whether overbilling, phantom deliveries, and duplicate payments are caught or paid.

## Why it matters

The three-way match is the primary defense against paying for what was never received or never agreed. Without the receiving leg, a contractor pays whatever the vendor bills, exposing it to inflated quantities, prices above the purchase order, and deliveries that never arrived. The control converts trust into verification at the exact point cash leaves the company.

It protects the integrity of committed cost. Because the match ties the invoice back to the purchase order, it ensures invoices draw down the correct commitment and are coded consistently with the original authorization, so the job-cost report reflects what was actually bought rather than however the invoice happened to be keyed.

It is the control auditors and sureties expect to see enforced, alongside segregation of duties. A payables function that cannot demonstrate a working three-way match with defined tolerances is a control weakness that shows up in audits, bonding reviews, and fraud losses, because the absence of the match is the absence of the main preventive barrier in AP.

It reduces the cost of exceptions by catching problems before payment rather than after. Recovering an overpayment or a duplicate from a vendor is slow, contentious, and often incomplete, while blocking the payment at the match is immediate and clean, which is why mature teams tune tolerances to catch real problems without drowning in trivial variances.

## Lifecycle

1. **Purchase-order creation** — A purchase order records the agreed vendor, items, quantities, prices, and coding, establishing the first leg. A purchase raised without a PO cannot be three-way matched and defaults to manual review.
2. **Goods or service receipt** — Delivery is recorded against the PO, capturing quantity received and often condition. Weak or missing receiving is the leg most often absent in construction, where materials land on a site rather than a dock.
3. **Invoice capture** — The vendor invoice is captured and its header and line data extracted. The invoice must reference the PO for the match to run automatically.
4. **Matching and tolerance check** — The system compares invoice to PO to receipt on price and quantity within defined tolerances. Matches within tolerance pass; variances beyond tolerance become exceptions.
5. **Exception resolution** — Price differences, over-shipments, partial deliveries, and quantity mismatches are investigated and resolved with the vendor, the field, or purchasing. This is where the control does its real work.
6. **Approval and posting** — A clean or resolved match is approved and posted, drawing down the commitment and booking job cost consistent with the PO coding.
7. **Payment release** — Only matched, approved invoices are released for payment within terms. Nothing unmatched pays without a documented exception approval.
8. **Audit trail retention** — The matched set of invoice, PO, and receipt is retained as the evidence that the payment was authorized and received, the record auditors and sureties rely on.

## Anatomy

- **Purchase order number** — The authorization the invoice matches to. Its absence forces manual review and defeats automated matching.
- **PO line items and quantities** — What was agreed to be bought and how much, the baseline the invoice quantity is checked against.
- **PO unit prices** — The agreed pricing, compared to invoice pricing to catch billing above the authorized rate.
- **Receiving quantity** — How much was actually delivered, the leg that stops payment for undelivered goods and detects over-shipment.
- **Receiving condition and date** — Whether goods arrived acceptable and when, relevant to partial deliveries and to timing of the payable.
- **Invoice quantity and price** — What the vendor is billing, the values matched against PO and receipt within tolerance.
- **Price tolerance** — The allowed variance between invoice and PO price before an exception is raised, tuned to balance control against exception volume.
- **Quantity tolerance** — The allowed variance between invoiced, ordered, and received quantities, accommodating legitimate partial and over-shipments within limits.
- **Match status** — Whether the invoice matched cleanly, matched within tolerance, or failed to an exception, the field that gates payment.
- **Exception reason** — Why a match failed: price variance, quantity variance, missing receipt, missing PO, the categorization that routes resolution.
- **Commitment reference** — The commitment the PO draws against, so a matched invoice reduces the right commitment and updates job cost correctly.
- **Resolution and approver** — How an exception was resolved and who authorized the override, the audit record for any payment made outside a clean match.

## Failure modes

- **Missing receiving leg** — On construction sites, materials arrive without anyone recording receipt against the PO, so the match collapses to a two-way comparison and payment goes out with no proof the goods actually arrived. This is the most common way the control quietly fails in the field.
- **Tolerances set too loose** — Price and quantity tolerances are widened to reduce exception volume until the match passes variances large enough to hide real overbilling. The control still runs on paper but no longer catches the problems it exists to catch.
- **Tolerances too tight, exceptions ignored** — Tolerances are so tight that trivial variances flood the exception queue, staff learn to override without investigating, and a genuine overbill slips through in the noise. Over-tight control produces the same outcome as no control.
- **Blanket or no-PO purchases** — Field buys and blanket orders bypass the PO discipline, so a large share of spend cannot be matched and defaults to manual approval, where the preventive control is weakest and duplicates and overbills concentrate.
- **Override without documentation** — Exceptions are cleared under queue pressure by approving the invoice without recording why, so the audit trail shows a payment made outside a clean match with no basis, which is exactly what auditors flag and fraudsters exploit.
- **Partial deliveries mismatched to a full invoice** — A vendor invoices the full PO while only part was delivered, and without accurate receiving quantities the match cannot distinguish a legitimate partial from an overbill, so either the full amount is paid or a real delivery is wrongly held.

## Metrics

- **Auto-match rate** — Share of invoices that match cleanly within tolerance without manual intervention. The headline efficiency and data-quality metric for the control.
- **Exception rate and aging** — Portion of invoices falling to exception and how long they sit. High or aging exceptions signal upstream PO and receiving problems and delay payment.
- **No-PO spend** — Share of payables lacking a purchase order and therefore unmatched. Directly measures how much spend escapes the preventive control.
- **Receiving capture rate** — Portion of deliveries recorded against a PO. Low capture is the leading cause of a broken match in construction.
- **Tolerance breach recovery** — Value of overbilling and errors caught at the match before payment. Quantifies what the control actually saves.
- **Override documentation rate** — Share of exception overrides with a recorded reason and approver. Measures the health of the audit trail.

## The AI shift

- **Conversational** — You ask the payables data directly which invoices fail the match and why, which exceptions have aged past a threshold, how much spend is arriving without a purchase order, and where receiving is missing, so the weak points in the control are surfaced rather than buried in a queue.
- **Generative** — Match results and resolution drafts are produced automatically. Given an invoice, its purchase order, and receiving data, a model reports the match status, itemizes each price and quantity variance against tolerance, categorizes the exception reason, and drafts the resolution steps or the query to the vendor, so staff resolve rather than investigate from scratch.
- **Orchestrated** — The match is coordinated across purchasing, receiving, and payables. The invoice is matched to its PO and receipt, exceptions are routed to the party that can resolve them, resolved matches draw down the commitment and post to job cost, and receiving gaps are surfaced back to the field so the leg that construction most often misses gets filled.
- **Autonomous** — The match runs continuously inside guardrails: matching every PO-referenced invoice against its purchase order and receipt within set tolerances, passing clean matches to payment scheduling, and holding every variance and every missing leg as a documented exception. Tolerance settings, exception overrides, no-PO and no-receipt payments, and payments above a threshold all require a person.

## Prompts

### Conversational — Diagnosing why the payables exception queue keeps growing.

```text
Analyze our three-way-match exceptions over the last 90 days. Break them down by reason: price variance, quantity variance, missing receipt, and missing purchase order, and tell me the count and dollar value in each category. Identify which vendors and which jobs generate the most exceptions, and tell me how much of our total spend in the period arrived without a purchase order and therefore could not be matched. Flag any exceptions that were overridden and paid without a recorded reason. Summarize where the control is actually breaking and what upstream cause each pattern points to.
```

**Expected output:** An exception breakdown by reason, vendor, and job with dollar values, the no-PO spend share, and a diagnosis of the upstream causes, not a generic explanation of matching.

**Follow-ups:**

- Which of these are receiving-capture problems versus real overbilling?
- If I tightened the price tolerance by one point, how many more exceptions would that create?
- List the undocumented overrides so I can follow up on each.

### Generative — Running the match and drafting resolutions for a batch of invoices.

```text
Run the three-way match for this batch of invoices against their purchase orders and receiving records. For each invoice, report the match status and, where it fails, itemize the specific price and quantity variances against our tolerances and categorize the exception reason. For clean and within-tolerance matches, prepare them as payment-ready with the commitment they draw down. For each exception, draft the resolution: if it is a price variance, draft the query to the vendor citing the PO price; if it is a quantity or missing-receipt issue, draft the request to the field to confirm delivery. Do not propose paying any invoice with a missing receipt or missing PO; flag those for manual decision.
```

**Expected output:** Per-invoice match results with itemized variances, payment-ready clean matches, and drafted resolutions for exceptions, with no-PO and no-receipt invoices explicitly held for a human.

**Follow-ups:**

- Which exceptions are within tolerance and only need documentation to pass?
- Produce the vendor queries as ready-to-send messages.
- Show the total value held in exceptions versus cleared for payment.

### Orchestrated — Closing the receiving gap that keeps breaking the match in the field.

```text
Our match keeps failing because receiving is not being recorded on site. For this project, identify every invoice sitting in exception solely because there is no receiving record against the purchase order. For each, pull the delivery ticket or packing documentation if it exists, and prepare a request to the superintendent to confirm receipt of the specific items and quantities. Where a delivery ticket exists and matches the PO and invoice, prepare the receiving entry for confirmation so the match can complete. Produce a summary of how much value is stuck on missing receipts and which deliveries need field confirmation, and flag anything where the delivery ticket disagrees with the invoice.
```

**Expected output:** A list of receiving-gap exceptions with delivery evidence pulled, prepared receiving entries for confirmation, and a value-stuck summary, with any ticket-versus-invoice conflicts flagged.

**Follow-ups:**

- Which of these have delivery tickets that conflict with the billed quantity?
- Draft the standing request to the field for recording receipts going forward.
- How much payment value would clear if these receipts were confirmed today?

### Autonomous — Standing policy for operating the three-way match inside guardrails.

```text
Operate our three-way match continuously under these rules. For every PO-referenced invoice, match it against its purchase order and receiving record within the price and quantity tolerances I have set, pass clean and within-tolerance matches to payment scheduling with the correct commitment draw-down, and hold every variance beyond tolerance as a documented exception categorized by reason. Route price-variance exceptions to purchasing and quantity or missing-receipt exceptions to the field with a drafted query. Never pass an invoice with a missing purchase order or missing receiving record, never change a tolerance setting, never override an exception, and never release a payment above the threshold I set without my approval. Every override and every no-PO or no-receipt payment must be decided by me and recorded with a reason.
```

**Expected output:** A running match that pays only clean, in-tolerance, fully matched invoices, a documented exception queue routed to the right owners, and hard boundaries around tolerances, overrides, no-PO or no-receipt payments, and above-threshold releases.

**Follow-ups:**

- Show me this week's clean matches, held exceptions, and anything escalated.
- Which tolerance would you recommend adjusting based on the exception pattern, and why?

## Maturity ladder

- **Level 0 — Level 0 — Pay on invoice** — Invoices are paid on the vendor's word with no systematic comparison to a PO or receipt, so overbilling, phantom deliveries, and duplicates are caught only by accident.
- **Level 1 — Level 1 — Two-way match** — Invoices are compared to purchase orders but not to receiving, so pricing is checked while delivery is assumed, leaving the largest gap in the control open.
- **Level 2 — Level 2 — Full three-way with tolerances** — Invoice, PO, and receipt are matched within defined tolerances, exceptions are routed and resolved, and overrides are documented, so the preventive control genuinely functions.
- **Level 3 — Level 3 — Assisted matching and resolution** — Matching runs automatically with variances itemized, exceptions categorized, and resolutions and vendor queries drafted, while receiving gaps are surfaced back to the field for human action.
- **Level 4 — Level 4 — Operated** — Matching, tolerance checks, exception routing, and payment scheduling of clean matches run unattended inside guardrails, while people own tolerances, overrides, no-PO or no-receipt decisions, and above-threshold payments.

## FAQ

### What is the difference between a two-way and a three-way match?

A two-way match compares the invoice to the purchase order, confirming the vendor is billing the agreed items and prices. A three-way match adds the receiving record, confirming the goods or services were actually delivered. The receiving leg is what stops payment for undelivered or over-shipped goods, so a two-way match verifies the deal but not the delivery, which is a meaningful gap in a business where materials are billed before anyone confirms they arrived.

### Why does the three-way match break down on construction sites?

Because materials arrive at a job site rather than a controlled dock, receipt is frequently not recorded against the purchase order. Delivery tickets pile up in a trailer or get lost, so the receiving leg is missing and the match cannot complete. This is why receiving-capture rate is a critical metric and why disciplined recording of deliveries against POs, often using the delivery ticket, is the single biggest improvement most contractors can make to the control.

### How should matching tolerances be set?

Tolerances should be tight enough to catch overbilling that matters but loose enough that trivial variances, like rounding or minor freight differences, do not flood the exception queue. Set them too loose and real overbilling passes; set them too tight and staff override exceptions reflexively, which defeats the control just as thoroughly. The right level is tuned from the actual variance patterns in the data and revisited as those patterns change.

### What about purchases that never had a purchase order?

No-PO spend, such as field buys and some services, cannot be three-way matched and defaults to manual approval, which is where the preventive control is weakest and where duplicates and overbilling concentrate. The remedy is partly procedural, extending PO discipline to more spend including blanket orders, and partly compensating controls like stronger approval and duplicate detection on the unmatched remainder. Measuring no-PO spend tells you how much of your payables is outside the main control.

## Related objects

- [Accounts Payable Invoice](https://briq.ai/acu/object/ap-invoice)
- [Purchase Order](https://briq.ai/acu/object/purchase-order)
- [Commitment](https://briq.ai/acu/object/commitment)
- [Material Delivery Ticket](https://briq.ai/acu/object/material-delivery-ticket)
- [Job Cost Report](https://briq.ai/acu/object/job-cost-report)
- [Cost Code Structure & WBS](https://briq.ai/acu/object/cost-code-structure)