What Is Three-Way Matching? How POs, Goods Receipts & Bills Reconcile
Three-way matching means checking a purchase order, goods receipt, and vendor bill (what most ERPs call an invoice) against each other. Here's what happens the moment they don't agree, why that shouldn't mean an exception queue, and how the same purchase-order data sets reorder timing for a cannabis or CPG manufacturer's raw materials.
By Andy CaccavaroPublished August 11, 2026
A purchase order, a goods receipt, and a vendor bill (an invoice, in most other ERPs' vocabulary) each capture a different fact about the same purchase. The receipt is physical evidence: what actually arrived, counted at the dock. The bill is financial evidence: what the vendor is actually charging. When the bill's price doesn't match what the receipt assumed, most systems park the invoice in an exception queue until someone clears it by hand. Illumify trues up the lot's cost to the final invoiced price automatically instead. The receipt already settled the quantity, so there's nothing left to argue about but the number.
- What is three-way matching?
- What happens when the three records don't match?
- Two-way matching vs. three-way matching
- Why three separate records, not one
- Where the match happens, and where it doesn't
- When there's no purchase order to match against
- Matching across more than one facility
- What the same purchasing data does next
- Frequently asked questions
What is three-way matching?
Three-way matching is the practice of checking a purchase order, a goods receipt, and a vendor bill against each other before treating the cost as final: three independent accounts of the same purchase, none of them trusted alone.
The purchase order says what was ordered. The goods receipt says what physically arrived. The bill (an invoice, in most other ERPs' terms) says what the vendor actually charged. When all three describe the same event, the transaction closes clean. When they don't, that gap is exactly the discrepancy worth catching, before it becomes a wrong number on a shelf or a balance sheet.
For a cannabis or CPG manufacturer buying packaging, nutrients, ingredients, or outside processing across more than one facility, this isn't a finance nicety. It's the only reason a lot's cost is ever more than an estimate someone typed into a bill.
What happens when the three records don't match?
In the textbook, default-configuration version of three-way matching, a mismatch is where the process stops: the invoice drops into an exception queue and sits there, unpaid and unposted, until someone opens all three documents and manually clears it. Plenty of systems support tighter tolerance settings to cut down how often that happens, but even when the exception clears, the adjustment often lands in a P&L variance account and never makes it back to the actual inventory lot. The books reconcile. The lot's cost doesn't.
Illumify splits the question in two, because a price problem and a quantity problem aren't the same problem. The goods receipt is the physical record (what showed up, counted at the dock), and it's what quantity is checked against; a bill's quantity comes directly from the receipt it's tied to, not re-entered, so there's nothing for the invoice to relitigate on that front. Price is the open question: if the bill's price differs from what the receipt assumed, the system trues up the lot's cost automatically to the final invoiced amount. Nothing waits in a queue, and nothing gets decided by the invoice that the receipt had already settled.
Quantity is settled once, at receiving. Price trues up automatically when the bill differs, so nothing waits in an exception queue.
| Purchase order | 1,000 units × $0.50 = $500.00 expected |
| Goods receipt | 1,000 units physically received (quantity confirmed) |
| Bill | $525.00 invoiced |
| Result | Lot cost trues up automatically to $525.00 total ($0.525/unit) |
Quantity was never in question. The receipt already settled that. Only the $25 price difference needed resolving, and it resolved itself.
Two-way matching vs. three-way matching
Two-way matching (sometimes written 2-way matching) checks a bill against only the purchase order: did the vendor charge what was agreed? It catches a price problem, but it takes the vendor's word for quantity, because nothing independently confirms what actually arrived. Three-way matching adds the goods receipt as a second, physical witness: not just what the vendor says shipped, but what someone on your dock actually counted. For anything that becomes inventory, and in a regulated, lot-tracked operation that's almost everything, skipping the receipt means trusting the invoice to grade its own homework.
Why three separate records, not one
Each of the three answers a different question, from a different source, at a different moment, and none of them should be allowed to answer for the other two:
| Record | Answers | Written by, and when |
|---|---|---|
| Purchase order | What did we agree to buy, and at what price? | Your own team, before anything moves |
| Goods receipt | What actually arrived, and in what quantity? | Whoever received it, at the dock, not from memory later |
| Bill | What is the vendor actually charging? | The vendor, which may not match the PO if a price changed, or the receipt if the invoice bundles items differently |
A system that lets any one of these stand in for the other two is trusting a single account of what happened. That's exactly where cost errors, and quietly wrong lot-level inventory, hide.
Zoom out and the pattern is bigger than an accounting control. Illumify doesn't treat purchasing and accounting as separate workflows that get reconciled after the fact. The purchase order establishes expectation, the receipt establishes physical reality, and the bill establishes financial reality: each one layers onto the last as the truth actually becomes known, instead of being stitched together at month end.
Where the match happens, and where it doesn't
In a lot of cannabis and CPG operations, all three records already exist. They're just never actually placed next to each other. The purchase order lives in an email or a spreadsheet row. The goods receipt is whatever the receiving employee wrote on a packing slip, if anything got written down at all. The bill goes straight to accounts payable, coded by whoever's fastest, often without ever being checked against the other two.
Nothing here is technically missing. The problem is that these records were never designed to talk to each other. That's a process gap, not an accounting one, and it's the gap three-way matching exists to close.
When there's no purchase order to match against
Not every operator wants to run purchasing through formal orders, and Illumify doesn't require it. A bill can be entered directly: mark a line item “Received” to generate the receipt automatically, or skip it entirely for a purely financial charge with no inventory involved. Purchase-order matching is the more rigorous path for teams that want it, not a requirement standing between a vendor and getting paid.
Matching across more than one facility
Purchase orders live within the accounting company that placed them, with a facility allocation on the order itself, so one purchase order can supply more than one location without the match splintering into a separate record per facility. An operator buying packaging for three facilities from a single vendor still gets one match, not three to keep in sync by hand.
What the same purchasing data does next
The same purchase order and receipt data that powers matching also powers visibility: every outstanding order in one list, with status, what's been received, and what's still open, plus totals most teams have never had in one place before. Vendor and purchase-order documents (certificates, insurance, lab results) attach directly to the vendor record or the order itself, so compliance paperwork travels with the transaction instead of living in an inbox.
It also powers something matching wasn't built for: every goods receipt carries a date, and compared against when its purchase order was placed, that's a real, measured vendor lead time, not a guess. Illumify's forecasting engine uses exactly that signal to set reorder timing per vendor instead of a static buffer, off the same data three-way matching already captures.
To be direct about the limits: nothing here automatically blocks someone from placing a duplicate order, and nothing automatically checks whether a vendor's license is still active. What changes is that the records needed to catch either one (the open PO list, the vendor's document history) sit in one place instead of scattered across inboxes.
Frequently asked questions
Three-way matching is the practice of checking a purchase order, a goods receipt, and a vendor bill (an invoice) against each other before treating a cost as final. The receipt confirms quantity; the bill's price trues up the lot's cost automatically if it differs from what was expected.
No. A bill can be entered directly, with a line marked “Received” to generate a receipt automatically, or as a purely financial entry with no inventory impact. Purchase-order matching is available for teams that want that extra structure. It isn't a requirement standing between a vendor and getting paid.
A direct receipt covers that case: vendor, item, quantity, and cost captured at the moment of delivery, without a purchase order behind it. It produces the same outcome a matched PO would: a real cost tied to a real quantity, not a bill taken at face value.
Purchase orders live within the accounting company that placed them, with a facility allocation on the order itself, so one purchase order can supply more than one location without the match splintering into separate records per facility.
That's a partial or over receipt, tracked as its own status rather than treated as an error. A purchase order can move through Partial Received before Goods Received as shipments arrive in more than one delivery. The bill ties back to what was actually received, not what was originally ordered.
Not automatically. There's no auto-block on duplicate purchase orders today. What changes is visibility: an open purchase order list anyone can check before placing a new one.
Yes. Documents attach directly to the vendor record or the purchase order, so compliance paperwork travels with the transaction instead of living separately from it.
Two-way matching checks a bill against only the purchase order: confirming price, but taking the vendor's word for quantity. Three-way matching adds the goods receipt as an independent physical check on what actually arrived, which matters most for anything that becomes inventory.
Yes. The lead time between a purchase order and its goods receipt is a real, measured number, and Illumify's forecasting engine uses it to set reorder timing per vendor instead of a static buffer someone picked once. It runs on the same PO-to-receipt data three-way matching already captures.
For a receipt-backed bill, quantity comes directly from the goods receipt and isn't re-entered. Only the price is open at that stage. Physical count is settled once, at receiving, and isn't something an invoice gets to relitigate.
No. There's no dollar or percentage threshold to configure. Instead of deciding what variance counts as close enough to auto-approve, the system trues up the actual price difference to the lot's cost every time, so there's no threshold to tune and no small variance quietly written off.
See a cost that trues up on its own
Illumify checks every bill against the purchase order and goods receipt behind it, and trues up the lot's cost automatically the moment the price differs. No exception queue, no month-end scramble.
Request a DemoSources and further reading
Continue exploring Illumify's manufacturing knowledge hub with Vendor lead time and reorder points and Signs you have outgrown QuickBooks and spreadsheets.