3-Way Matching: PO, GRN & Invoice — Stop Paying for What You Didn't Receive

2026-07-26

3-way matching reconciles the purchase order, goods receipt (GRN) and supplier invoice before payment. The three checks, tolerances, the match data model, and how to automate it so you never overpay a supplier.

3-way matching — purchase order, goods receipt note and supplier invoice reconciled before payment

Here's a quiet way manufacturing SMEs leak money: paying supplier invoices on trust. The invoice arrives, it looks about right, accounts pays it. Nobody checks it against what was actually ordered and what was actually received. Over-billing, short supply, price creep and duplicate invoices all slip through — not because anyone's dishonest, but because no one cross-checked. 3-way matching is the control that closes that gap: you pay an invoice only when the purchase order, the goods receipt and the invoice all agree. This post explains exactly what to match, the tolerances to set, and how to automate it so it isn't a manual chore.

What 3-way matching is

Three documents, each proving a different fact, reconciled before a payment is approved:

DOCUMENT              PROVES                          OWNED BY
--------------------  ------------------------------  -----------
Purchase Order (PO)   what you AGREED to buy, at      Procurement
                      what quantity and price
Goods Receipt (GRN)   what you actually RECEIVED,     Stores / QC
                      and passed inspection
Supplier Invoice      what you're being BILLED for    Accounts

The rule in one line: quantity billed ≤ quantity received ≤ quantity ordered, and the price billed = the price agreed. If all three tie out, the invoice is cleared for payment. If they don't, it's held as an exception until someone resolves it.

The three checks

Matching isn't just "do the totals look close." It's three specific comparisons per line item:

CHECK        COMPARE                          FAILS WHEN
-----------  -------------------------------  ------------------------------
Quantity     Invoice qty vs GRN qty           Billed for more than received
Price        Invoice rate vs PO rate          Rate crept up vs the agreed PO
Tax / total  Invoice tax & amount vs computed  GST rate or total is wrong

The GRN is the anchor. An invoice can only be paid for goods that were received and accepted — which is why the goods-receipt step matters so much. If your process skips a proper GRN, you have no independent proof of receipt and the match collapses to "the invoice vs itself." (See the GRN process, step by step and a ready GRN format.)

Where it breaks on paper

On paper, 3-way matching is a person shuffling three documents from three departments. The PO is in procurement's file, the GRN is in the store register, the invoice is on the accountant's desk. Matching means physically pulling all three together — so in practice it's done for large invoices and skipped for the rest. That's exactly where the leakage lives: the small, frequent invoices nobody bothered to match.

The match record: fields and status

Automating the match means turning those three documents into one match record — the same field-and-status thinking that makes any control auditable:

FIELD                      NOTES
-------------------------  ---------------------------------------------
PO no. + line              what was ordered (qty, rate)
GRN no. + line             what was received & accepted (qty)
Invoice no. + line         what's billed (qty, rate, tax)
Qty variance               received − billed
Price variance             PO rate − invoice rate
Status                     Matched / Qty variance / Price variance /
                           Awaiting GRN / Duplicate / Approved to pay
Approved by / date         who released the exception, when

Status flow: Awaiting GRN → Matched → Approved to pay, or it diverts to Qty variance / Price variance and waits for a human decision. Every release is stamped with who approved it — so an over-tolerance payment is a deliberate, recorded act, not an accident.

Tolerances and exceptions

Real supply isn't perfectly exact, so you set tolerances — small allowances within which a match auto-passes:

Quantity tolerance — e.g. ±2% or the weighment variance you accept on bulk material.
Price tolerance — usually near-zero; a price change should mean an amended PO, not a silently higher invoice.
Exceptions route to a person — anything outside tolerance holds the payment and flags it for procurement or the plant head to approve or reject.

Done well, the honest 98% of invoices flow straight through and your team's attention goes only to the 2% that actually need a decision.

How to automate it

The mechanics are simple once the three documents live in one system:

1. Raise the PO in the system — quantity and rate are captured, not just printed.

2. Book the GRN against the PO — received quantity attaches to the PO line; QC pass/fail recorded.

3. Enter the supplier bill against the PO/GRN — the system computes the three checks instantly and sets the status.

4. Only matched (or approved-exception) bills post to payables — unmatched invoices simply can't be paid until resolved.

This is the same connected-data idea behind moving off a bookkeeping-only tool — see why factories outgrow Tally. And because the match record captures price variance per supplier over time, it feeds straight into vendor performance tracking: who ships short, who creeps prices, who bills clean.

Flobri Insights links your purchase orders, goods receipts and supplier bills into one flow, so every invoice is 3-way matched automatically — quantity against the GRN, price against the PO — and only matched or explicitly-approved bills reach payables. The leakage from paying on trust simply stops. See how it works.