Three Way Matching in Procure to Pay: A Plain English Guide

A vendor sends you an invoice for $4,800. The bookkeeper queues it for payment. Two weeks later you find out the warehouse only received $3,200 of stuff. The vendor short-shipped a pallet, never told you, and invoiced for the full order. You already paid the difference. Now you are chasing a $1,600 credit memo from a vendor who is suddenly hard to reach.

This is the everyday reason three way matching exists. It is the boring control that catches the dollars you would otherwise lose to short shipments, double invoices, price disputes, and quietly inflated bills. Once you have it set up, the bookkeeper stops being a single-point check on every payable. The system catches the mismatches automatically and flags only the few invoices that need a human.

This post covers what three way matching actually is, the dollar math on a real example, the three documents involved, what gets blocked vs released, the variance handling that real businesses hit weekly, and how to run it without spreadsheets.

What three way matching means in plain English

Three way matching is the practice of comparing three documents before you pay a vendor invoice:

1. The purchase order (PO) you sent the vendor. This is what you ordered, the agreed price, and the agreed quantity.
2. The goods receipt (sometimes called a receiving note or GRN). This is what the warehouse actually unloaded from the truck, on what date, in what condition.
3. The vendor invoice the supplier sent you, asking for payment.

The system checks that all three documents agree on what was ordered, what was received, and what is being billed. If they match, the invoice is approved for payment with no human intervention. If they disagree, the invoice is flagged for review.

That is it. The whole concept fits in one paragraph. The reason it has a fancy name is that the controls around it (who can release a flagged invoice, what tolerances are allowed, what gets posted to the GL when there is a mismatch) are where real businesses lose or save real money.

A real dollar example, end to end

Let me walk you through one purchase from PO to payment with all three documents.

Step 1: you send a PO. You order 100 units of Widget X from Acme Co at $48 per unit. PO total: $4,800. Expected delivery: April 15.

Step 2: goods arrive. The truck shows up on April 17. The warehouse receives 80 units. The other 20 are on backorder. Receiving clerk creates the goods receipt: 80 units of Widget X received, condition OK.

Step 3: vendor invoice arrives. A week later, Acme sends Invoice #5512 for $4,800. The invoice claims 100 units shipped at $48 each.

The three way match runs:

Document	Quantity	Price	Total
PO	100	$48	$4,800
Receipt	80	n/a	n/a
Invoice	100	$48	$4,800

The PO and the invoice agree. The receipt does not. The system blocks payment and routes the invoice to AP for review.

The fix. AP calls Acme, confirms 20 units were not shipped, and asks for a corrected invoice for $3,840 (80 units at $48). Acme issues a credit memo or revised invoice. The new invoice matches the receipt. Three way match passes. Payment releases.

Without three way matching, the bookkeeper would have queued the original $4,800 invoice for payment, paid it, and discovered the short shipment a month later when somebody noticed the warehouse was 20 units short on Widget X. The $960 overpayment becomes a vendor credit chase that takes weeks to resolve. Some of those credits never get recovered.

This is the whole point of the control. Catch the mismatch before the wire goes out, not after.

The three documents, in detail

Let’s break down what each document is, who creates it, and what fields the match looks at.

The purchase order (PO)

Created by your purchasing team or auto-generated from a low-stock alert. It records:

• Vendor: who you are buying from
• Items and quantities: SKU, description, quantity ordered
• Agreed price per unit: what you negotiated
• Expected delivery date
• Total PO value
• Approval status: most companies require a manager to approve POs above a threshold

Once a PO is approved, it is the contract. The vendor agreed to ship what is on it at that price.

The goods receipt

Created by the warehouse or receiving team when the goods arrive. It records:

• Date received
• Items and quantities actually received (often less than ordered if there is a short ship)
• Condition: any damage, wrong items, missing parts
• Reference to the PO so the system knows which order this fulfills
• Receiver name for audit trail

The goods receipt is what your auditor uses to confirm you actually got what you paid for. If it does not exist, you cannot prove the goods were ever delivered.

The vendor invoice

Sent by the vendor, recorded by AP. It records:

• Invoice number (the vendor’s, not yours)
• Invoice date (drives payment terms)
• Items and quantities billed
• Price per unit billed
• Tax, shipping, discounts
• Total amount due
• Reference to the PO if the vendor included one (good vendors do)

AP enters the invoice into the system and the three way match runs automatically.

What the match actually checks

The match compares specific fields across the three documents. Different systems implement this slightly differently, but the core checks are universal:

Quantity match. Quantity invoiced must equal quantity received. If you received 80 and the vendor billed 100, the match fails. If you received 100 and the vendor billed 80, the match also fails (you actually owe more than they billed, but you should not pay until they correct the invoice).

Price match. Price per unit invoiced must equal price per unit on the PO. If your PO said $48 and the invoice says $52, the match fails. Vendors raise prices quietly all the time. Three way matching catches it.

Item match. The SKU on the invoice must match the SKU on the PO and the receipt. If the vendor swapped the item without telling you, the match fails.

Vendor match. The vendor on the invoice must match the vendor on the PO. Sounds obvious. It is not. Plenty of fraud cases involve a fake invoice from a lookalike vendor name routed through someone who does not check.

Tolerance check. Most companies allow a small variance, say 2% on price or 1 unit on quantity, to handle normal supplier variance. Anything inside the tolerance auto-approves. Anything outside flags for review.

When all four checks pass within tolerance, the invoice is released for payment. When any check fails, the invoice is held and routed to a queue.

The variances real businesses hit weekly

In a real business, a clean three way match is the exception, not the rule. Here are the variance types you will deal with constantly and how the system should handle each.

Price variance

Vendor billed $52 per unit but the PO said $48. Maybe a price increase, maybe an honest mistake, maybe a clerical error in their system.

Handling. AP calls the vendor or pulls up the contract. If the price increase was approved, AP updates the PO price (usually requires a manager) and the match passes. If the price was wrong, the vendor issues a corrected invoice.

The dollar number is real. A 10% silent price increase across 30% of your suppliers, undetected for a year, is a measurable hit to gross margin.

Quantity variance, short ship

Ordered 100, received 80, billed 100. Most common variance type.

Handling. Block the invoice. Receive the remaining 20 when they arrive (creating a second goods receipt against the same PO). Once total received hits 100, the original invoice matches and releases. If the remaining 20 will not ship, the vendor issues a credit memo for $960.

Quantity variance, over ship

Ordered 100, received 110, billed 100. Vendor accidentally shipped extra.

Handling. Decide whether to keep the extra (and pay for it, with an updated invoice from the vendor) or return it. Goods receipt records 110, AP holds the original invoice, AP either gets a new invoice for 110 or arranges a return.

Item substitution

Ordered Widget X but the receipt says Widget Y. Vendor substituted because Widget X was out of stock.

Handling. Block. Confirm with purchasing whether the substitute was authorized. If yes, change the PO. If no, return.

Freight or tax mismatch

PO totaled $4,800 in line items. Invoice is $4,920 because the vendor added freight or tax that was not on the PO.

Handling. This is where tolerance bands matter. Many companies set a freight tolerance of $200 or 5% of PO value to auto-pass freight charges that line up with the shipping terms.

Duplicate invoice

Vendor accidentally sent the same invoice number twice. Or sent the same charges with two different invoice numbers.

Handling. Most systems block on invoice number duplication automatically. The version with two different numbers is the dangerous one and is exactly what duplicate detection tools catch.

What the GL looks like in a three way match flow

The accounting moves through three GL postings, not one. This is the part most people skip past, and it is the part that matters most for clean books.

On goods receipt. The warehouse received goods you have not yet been billed for. You owe somebody for them, but you do not yet have an invoice. The system posts:

DR Inventory             $3,840
CR GR/IR (Goods Received Not Invoiced)  $3,840

GR/IR is a clearing account. It says “we owe somebody for these goods, vendor invoice pending.”

On invoice receipt and three way match pass. The invoice arrives, matches, releases. The system posts:

DR GR/IR              $3,840
CR Accounts Payable   $3,840

The GR/IR clearing account zeros out. The AP balance goes up by what you actually owe.

On payment. When you pay the invoice:

DR Accounts Payable   $3,840
CR Cash               $3,840

This three step flow gives you visibility into “what have we received but not yet been billed for” (the GR/IR balance), which is one of the most useful AP control numbers and one most small businesses never look at.

Why every business above $2M revenue needs this

Below roughly $2M revenue, most companies do not formally run three way matching. The CEO knows every PO. The bookkeeper checks every invoice. The warehouse is the founder’s brother. Controls are by relationship, not by process.

Above $2M, the wheels come off. Multiple people place orders. The warehouse hires a part-timer. The bookkeeper gets behind. Vendors quietly raise prices. Short shipments stop getting flagged. The first time you do a real inventory count and find $40,000 less stock than the books say, you realize the controls failed three months ago.

Three way matching is the cheapest insurance policy against that scenario. It does not require a CFO. It does not require a $5,000 a month AP automation tool. It requires a system that creates POs, records goods receipts, and matches them to invoices. Most ERPs include this.

How ERPClaw handles three way matching

ERPClaw is an open-source ERP with three way matching in the core. Here is the workflow:

Step 1: create the PO. Use the add-purchase-order action with vendor, items, quantities, prices. Manager approval required for POs over a configurable threshold.

Step 2: receive the goods. When the truck arrives, the warehouse runs add-goods-receipt referencing the PO. Records actual quantities received. The system posts the GR/IR journal entry automatically.

Step 3: enter the vendor invoice. AP runs add-purchase-invoice referencing the PO. The three way match runs automatically. If quantity, price, and item all match within tolerance, the invoice releases for payment. If any check fails, the invoice goes to a hold queue.

Step 4: review the hold queue. AP pulls up flagged invoices, reviews the variance, takes action (call the vendor, update the PO, issue a credit memo). Anything cleared releases for payment.

Step 5: pay. When invoices are due (per terms), the submit-payment-batch action generates payment files and posts the GL.

The whole flow uses the purchasing module plus the accounting module, both shipped in the core ERPClaw install. Free, MIT licensed, runs on SQLite or PostgreSQL.

What you save by running this in software vs spreadsheets

A lot of small businesses still run procure-to-pay in spreadsheets. POs in a Google Sheet, receipts in another sheet, invoices in QuickBooks, matching done by eyeballing. This is the worst possible setup because nothing is enforced.

Real businesses lose money this way. The dollar amounts are small per incident (a $200 short ship, a $50 silent price increase) but they happen weekly. Across a year, a $4M revenue company running this manually loses 0.5% to 1.5% of cost of goods to undetected variances. That is $20,000 to $60,000 a year in real money, gone, because the controls were not enforced.

Three way matching in software is one of the highest-ROI setups a small business can make. The implementation cost in ERPClaw is the time it takes to enter your existing vendors and one PO. The savings start the same week.

CTA

If you want three way matching in your business without paying QuickBooks Online Advanced ($235/mo) or NetSuite ($25,000+/yr) for it, ERPClaw includes it free in the core install.

• Install ERPClaw (5 minutes)
• Try the demo (browser, no install)
• See the QuickBooks alternative comparison
• Read about AI-native ERP architecture
• See pricing (it is $0)

ERPClaw is MIT licensed, AI-native, and ships with the procurement, inventory, and accounting modules in one shared database. No per-user fee, no upgrade tier behind a paywall, no enterprise gate.

FAQ

Is three way matching the same as four way matching?

Four way matching adds a fourth document, the inspection or quality check, to the three way match. You match PO + receipt + inspection + invoice. It is used in industries where goods can be received but later fail QC (regulated manufacturing, pharmaceuticals, food). Three way matching is enough for most small to mid-market businesses.

Do I need three way matching for service vendors?

Service invoices (consultants, software subscriptions, marketing agencies) usually do not have a goods receipt because nothing physical was delivered. For services, most systems use a two way match (PO + invoice) or a contract-based match (compare invoice to the SOW or recurring contract). Three way matching is for physical goods.

What is GR/IR and why does it matter?

GR/IR stands for “Goods Received but not Invoiced.” It is a clearing account that holds the value of goods you received before the vendor invoice arrives. The balance tells you “we have inventory we have not yet been billed for, dollar value $X.” It is one of the most useful control numbers in AP and one most spreadsheet-run businesses never see.

How tight should my tolerances be?

Common defaults are 2% on price, 1 unit or 1% on quantity, and 5% on freight. Tighter tolerances catch more variances but flag more invoices for human review. Looser tolerances release more invoices automatically but let small overcharges through. Most companies tune the tolerance per vendor based on supplier reliability.

Does ERPClaw three way matching work with PostgreSQL?

Yes. ERPClaw is database-agnostic via PyPika. SQLite is the default for install simplicity, but PostgreSQL is fully supported as an alternative backend. The same procurement actions run on either database.

Can I run three way matching without a formal warehouse?

Yes. The “warehouse” can be one person on the receiving dock, the office manager, or even the founder. The point is that whoever physically takes possession of the goods enters the goods receipt before AP processes the invoice. Even a one-person operation benefits because it forces a check before payment.

Does ERPClaw support backorders and partial receipts?

Yes. A PO can have multiple goods receipts against it. If you order 100 units and receive 80 today, 20 next week, you create two receipts. The system tracks remaining quantity automatically and the three way match runs against the cumulative received total.

Install ERPClaw and try a real three way match in your own data.