What is a three-way match in accounts payable?

A three-way match is the accounts payable control that pays a supplier invoice only when it agrees with two other records: the purchase order that authorized the buy on price and quantity, and the goods receipt that confirms what was actually received. The invoice price is compared to the order and the invoice quantity to the receipt, and payment follows only for the amount all three support. Enterprise systems also use a two-way match, comparing the order and the invoice, and a four-way match, which adds acceptance or inspection of the goods.

Why does the three-way match protect against invoice and payment fraud?

The invoice is the only one of the three documents that arrives from outside the company, so it is the one a fraudster can fabricate or spoof. The purchase order and the goods receipt are created inside your own operations, so a match that requires all three to agree rests on two records nobody outside can forge. A fabricated or inflated invoice has nothing to match against. The 2025 FBI Internet Crime Report recorded business email compromise, which targets businesses that pay suppliers, as the second largest loss category at more than three billion dollars, which is exactly the risk this control addresses.

What is the goods received not invoiced (GR/IR) account and why does it matter?

The goods received not invoiced account, also called GR/IR, is a clearing account that holds the liability from the moment goods are received until the supplier invoice posts. When every receipt has a matching invoice and every invoice a matching receipt, the account nets to zero. A residual balance signals goods received but not yet invoiced, which becomes a clean accrual at close, or an invoice with no receipt, which is a question worth asking early. Reconciling it every period is how the match shows up in the ledger.

What is the most common payment fraud the match alone does not stop?

The costliest miss is usually not a fake invoice, it is a real invoice paid to a changed bank account. A fraudster who changes the payment details on a genuine vendor sends a legitimate invoice to a thief, and a perfect three-way match still approves it because the purchase was real. That is why the vendor master is a companion control: any change to bank details should be verified independently through a channel you already trust, and every change logged, so a redirected payment is stopped before the run.

Digital

Finance

Team

Why The Invoice Alone Is Weak What The Match Checks The Purchase-To-Pay RecordPublished September 5, 2026

Let the purchase order and the goods receipt vouch for every invoice.

Q: How should a purchase-to-pay record be shaped for a reliable match?

Require a purchase order for the spend that can carry one, capture a goods receipt from actual delivery rather than from the invoice, and set price and quantity tolerances on purpose with a named owner. Block invoices outside tolerance into a review queue instead of paying and chasing, reconcile the goods received not invoiced account every period, and control vendor bank changes with independent verification. Prove readiness with one exception query over any invoice paid without an order or receipt, any overbill, any unverified bank change, and any aged clearing line.

The invoice is the one record in a purchase that arrives from outside, so it is the one a fraudster can fabricate. The purchase order and the goods receipt are made inside your own operations. A match that requires all three to agree rests on two records nobody outside can forge, and the same records that stop a bad payment give you a clean accrual and a faster close.

Article signals

Audience: Controllers and accounts payable leaders, procurement and receiving owners, treasury and payments teams, internal audit, and the ERP systems people who own purchase orders, goods receipts, invoice verification, and the vendor master
Trigger: Reported losses to business email compromise reached the second largest category in the 2025 FBI Internet Crime Report at more than three billion dollars, aimed squarely at businesses that pay suppliers, and generative tools now make a convincing fake invoice or payment request cheaper to produce
Published: September 5, 2026
Scope: Any business that buys goods or services against purchase orders and pays supplier invoices, and any finance team that wants a payment control that a forged document cannot defeat and a cleaner close as a side effect
The shift: The invoice is the one record in a purchase that arrives from outside, so it is the one a fraudster can fabricate. The purchase order and the goods receipt are created inside your own operations, so a match that requires all three to agree rests on two records nobody outside can forge
The artefact to build: A purchase-to-pay record where every payable is matched to its purchase order and goods receipt within set tolerances, the goods received not invoiced account nets to zero, vendor bank changes pass a controlled review, and one exception query lists every invoice paid without a matching order or receipt

The one document a stranger can send you.

Think about a single supplier payment and the records behind it. There is a purchase order, created inside your own company when someone with authority decided to buy something at an agreed price. There is a goods receipt, booked by your own people when the goods arrived or the service was confirmed. And there is an invoice, which came from the supplier. Two of those three records are yours. One of them is not, and that one is the only record a person outside your company can produce at will.

That is where the money goes. In its 2025 Internet Crime Report, the FBI Internet Crime Complaint Center put reported losses to business email compromise second only to investment fraud, more than three billion dollars across 24,768 complaints, with the funds leaving mostly by wire transfer or ACH. The report defines business email compromise plainly: it targets businesses working with suppliers and businesses that regularly perform wire transfer payments, and it works by compromising email to steer a legitimate payment to the wrong place. The same report notes that AI enabled synthetic content is getting easier to make, that more than 22,000 complaints carried an AI element, and that chat generators are already used to write official sounding requests to wire funds.

None of that is new in kind, only in scale and polish. The Association of Certified Fraud Examiners has been counting the same pattern for years. In its 2024 Report to the Nations, asset misappropriation showed up in 89 percent of occupational fraud cases, and the single most common form of it, tied at the top, was the billing scheme: a shell company, a non accomplice vendor, or a personal purchase run through the invoicing process. Billing schemes appeared in 22 percent of cases with a median loss of 100,000 dollars, and the typical fraud ran for about a year before anyone noticed. A convincing invoice, whether written by a criminal or generated in seconds, is the vehicle in almost all of it.

Here is the constructive part. The control that answers this is not new, not expensive, and not clever. It is the three-way match, the oldest discipline in accounts payable, and its whole power comes from the fact just noted: it refuses to pay an invoice unless the invoice agrees with the two records you created yourself. A fabricated bill can look perfect and still have nothing to match against, because there is no purchase order that authorized it and no goods receipt that confirms it. The rest of this piece walks through what the match actually checks, why the order and the receipt are the records worth trusting, and the purchase-to-pay record worth building so the control is real rather than nominal.

What the match checks, and what each record proves.

The mechanic is simple to state. A two-way match compares the invoice to the purchase order on price and quantity billed. A three-way match adds the goods receipt and checks that the quantity billed is no more than the quantity received. A four-way match goes further and adds acceptance or inspection of what arrived. Enterprise systems build this in and let you choose the level per category or supplier, so a stocked part with a physical receipt and a service with none each get the check that fits. The table below sets out the records, what each one asks, and what it should produce in the data a finance team owns.

The records in a three-way match, what each asks of your systems, and what each should produce in a finance team's data. Matching definitions follow the standard two-way, three-way, and four-way levels used in enterprise accounts payable; the fraud figures are read directly from the 2025 FBI Internet Crime Report and the ACFE 2024 Report to the Nations.
The record	What it carries	What the match asks	What it produces in your data
The purchase order authorized the buy	Price, quantity, terms, agreed before the invoice	A three-way match starts from a purchase order that says what was ordered, at what price, on what terms. It exists before any invoice arrives, and it is approved inside your own authorization limits, so it cannot be conjured by a supplier email.	A purchase order held as the first-class authorization for a spend, with the approver, the price, and the quantity captured, so the invoice is checked against an internal decision rather than trusted on its own.
The goods receipt confirms what arrived	Quantity received, date, condition, booked by receiving	The goods receipt records what your own people actually took in, and when. It is the record a remote fraudster cannot produce, because it depends on physical receipt or a confirmed service delivery inside your operations.	A goods receipt captured at the dock or on service completion, with quantity and date, so the match can ask whether the invoice bills for no more than what was genuinely received.
The invoice is compared, not trusted	Price and quantity billed versus order and receipt	The invoice is the third document, and the only one that came from outside. The match compares its price to the order and its quantity to the receipt, and it pays only what all three agree on, so an inflated or duplicate bill has nothing to match against.	An invoice that clears only when it agrees with the order on price and the receipt on quantity, so payment follows evidence the company created rather than a number a vendor asserted.
Tolerances decide pass, block, or review	Price and quantity variance limits, set on purpose	Small variances are normal, so the match uses tolerances. Within them an invoice passes; outside them it is blocked and routed for review. The tolerance is a governed number, not a default nobody set, because a loose tolerance is an open door.	Tolerance limits owned and reviewed, with every blocked invoice landing in a queue and a named owner, so a variance is investigated rather than waved through or silently paid.
The clearing account keeps the score	Goods received not invoiced nets to zero	Between receipt and invoice the liability sits in a goods received not invoiced clearing account. When every receipt has a matching invoice and every invoice a matching receipt, it nets to zero. A stale balance is a receipt with no bill or a bill with no receipt.	A goods received not invoiced account reconciled on a schedule, so an unbilled receipt becomes a clean accrual at close and an aged residual is a question asked early rather than a surprise found late.
The vendor master is the quiet control	Bank detail changes pass an independent review	The most common payment fraud does not fight the match, it moves the money. A changed bank account on a real vendor sends a genuine invoice to a thief. So the vendor master, and any change to payment details, needs a controlled and independently verified review.	A vendor master where bank detail changes are verified through a second channel and logged with who changed what and when, so a redirected payment is stopped before the run rather than chased after it.

The records in a three-way match, what each asks of your systems, and what each should produce in a finance team's data. Matching definitions follow the standard two-way, three-way, and four-way levels used in enterprise accounts payable; the fraud figures are read directly from the 2025 FBI Internet Crime Report and the ACFE 2024 Report to the Nations.

The theme worth sitting with runs down the middle. The purchase order proves the spend was authorized before the invoice existed. The goods receipt proves something actually arrived, and how much. Only then is the invoice compared, on price to the order and on quantity to the receipt, and only the amount all three support is paid. A padded quantity is caught by the receipt. An inflated price is caught by the order. A duplicate is caught because the receipt and the clearing account already show the delivery as settled. A phantom invoice for goods never bought is caught because there is nothing to match at all.

That last point is the answer to the fraud data. A business email compromise or a billing scheme rests on making a payment look legitimate, usually with a document that reads exactly like a real invoice. The match does not try to judge whether the invoice looks real, which is a losing game now that a convincing fake costs almost nothing to produce. It asks a different question that a forger cannot answer from outside: does this bill agree with an order we approved and a receipt we booked? When the answer has to come from records the company controls, the polish of the fake stops mattering.

The purchase-to-pay record, read as a governed control.

A worked example makes it concrete. A buyer raises a purchase order for 500 bearing assemblies at an agreed unit price. Receiving books a goods receipt when 480 arrive on the dock. Then an invoice comes in billing for 500. The price agrees with the order, so that check passes. The quantity does not agree with the receipt, 500 billed against 480 received, so that check blocks. The invoice does not get paid on the strength of looking correct; it stops, lands in a queue with an owner, and waits for the variance to be explained. The twenty units either arrive and get received, or the bill was wrong.

Here is that logic expressed as a record. The vendor carries a bank detail change control. The purchase order carries the authorization. The goods receipt carries what actually arrived. The invoice is compared, not trusted. The clearing account carries the goods received but not yet invoiced as an accrual. And an exception query at the end names the gaps that would make any of it untrustworthy.

A purchase-to-pay record shaped for a three-way match

# Purchase-to-pay record shaped for a three-way match
# Names, figures, and dates are placeholders for shape, not real values.

vendor:
  vendor_id: "V-10482"
  name: "Northwind Components"
  bank_account: "****3391"
  bank_change_control:
    last_changed: 2026-06-14
    verified_by: "AP control, second channel call to known contact"
    change_log: retained            # who, what, when, evidence

purchase_order:                     # created inside your authorization
  po_number: "PO-2026-55710"
  line: 1
  item: "Bearing assembly, 6204-2RS"
  quantity_ordered: 500
  unit_price: 3.10
  approved_by: "Ops buyer, within limit"
  terms: "Net 30, DDP"

goods_receipt:                      # what your people actually took in
  grn_number: "GRN-2026-88214"
  po_reference: "PO-2026-55710 / line 1"
  quantity_received: 480
  received_on: 2026-09-01
  condition: accepted

invoice:                            # the one record from outside
  invoice_number: "NW-77123"
  po_reference: "PO-2026-55710 / line 1"
  quantity_billed: 500
  unit_price: 3.10
  amount: 1550.00

match_result:
  price_check: pass                 # invoice price equals PO price
  quantity_check: blocked           # billed 500 > received 480
  tolerance_quantity: "0 over receipt"
  status: blocked_for_review        # sits in the queue, not paid
  owner: "AP analyst, GR/IR desk"

gr_ir_clearing:                     # goods received not invoiced
  received_value: 1488.00           # 480 units received, unbilled
  invoiced_value: 0.00              # nothing cleared yet
  residual: 1488.00                 # accrual at close until invoice clears

exception_query:                    # the readiness control, run on demand
  - invoice paid with no matching purchase order
  - invoice paid with no matching goods receipt
  - quantity billed greater than quantity received
  - vendor bank change with no independent verification on file
  - GR/IR line aged beyond the review threshold

The exception query is what keeps it honest. Matching every invoice to an order and a receipt means a phantom bill has nowhere to land. Reconciling the goods received not invoiced account means an unbilled receipt becomes a clean accrual at close rather than a surprise, and an aged residual is a question asked early rather than a loss found late. Controlling vendor bank changes means a real invoice cannot be paid to a stranger. None of this is elaborate. It is ordinary accounts payable discipline, pointed at the one record that arrives from outside and treated as the control it has quietly always been.

The purchase order and the goods receipt are created inside your own operations, so a match that requires all three records to agree rests on two documents nobody outside can forge. Within tolerance the invoice clears through the goods received not invoiced account; outside it, the invoice is blocked and reviewed. The vendor master control guards the payee, because the costliest miss is a real invoice paid to a changed account. The exception query is what keeps the control honest.

An implementation checklist.

1.Require a purchase order for the spend that can carry it. The match has nothing to compare against without an order, so define which categories must be bought on a purchase order and route the rest through a controlled non purchase order path with its own approval. The order is the internal authorization the invoice is checked against, so it has to exist before the invoice, not be created to clear one.
2.Capture a goods receipt at the point of receipt, not at invoice time. The goods receipt is the record a fraudster cannot forge, and it is only worth that if your own people book it when goods arrive or a service is confirmed, with quantity and date. A receipt keyed later from the invoice defeats the whole control, because then the invoice is checking itself.
3.Set price and quantity tolerances on purpose and own them. Decide the variance you will accept, per category if needed, and treat the number as a control that is reviewed, not a default left at install. A loose tolerance quietly turns a three-way match into a rubber stamp, so keep it tight enough that a real overbill is blocked and revisit it when prices move.
4.Block, queue, and resolve, rather than pay and chase. An invoice outside tolerance should stop and land in a work queue with a named owner, not slip through to payment on the theory that it can be corrected later. The whole value of the match is that the question is asked before the money leaves, when it can still be answered cheaply.
5.Reconcile the goods received not invoiced account on a schedule. The clearing account is the ledger view of the match: receipts waiting for invoices and invoices waiting for receipts. Reconcile it every period, book the unbilled receipts as a clean accrual, and investigate anything aged, so the balance is understood rather than carried as a mystery.
6.Control the vendor master, especially bank details. The fraud that beats a payment run is usually a changed bank account on a real supplier, so make any change to payment details pass an independent verification through a channel you already trust, and log who changed what and when. Verify a new payment instruction against a known contact, never against the number on the request that asked for it.
7.Run one exception query before you trust the control. Any invoice paid with no matching order, any invoice paid with no matching receipt, any bill for more than was received, any vendor bank change with no verification on file, and any aged clearing line is a gap. While that list has entries, the match is not yet the control you think it is, and the list is far cheaper to clear than a payment you cannot recover.

Failure modes, framed so you can avoid them.

Trusting the invoice because it looks right. A clean, official looking invoice is the easiest of the three documents to produce, and a spoofed supplier email that carries one is exactly what the 2025 fraud data describes. The point of the match is that looking right is not enough; the invoice has to agree with an order and a receipt the company itself created.
Creating the goods receipt from the invoice. If receiving books what the invoice says was delivered rather than what actually arrived, the three-way match collapses into the invoice checking itself. The receipt has to be an independent record of physical or confirmed delivery, or it adds no protection at all.
Setting tolerances so wide that nothing blocks. A tolerance is meant to absorb small, honest variances, not to let a padded quantity or an inflated price through. When the limit is loose enough that almost everything passes, the match still runs and still proves nothing, and the control exists only on the org chart.
Paying blocked invoices to keep the queue short. A blocked invoice is the control working, not a nuisance to clear by overriding it. Releasing holds under time pressure without resolving the variance turns the exception queue into a formality and hands back the protection the match was built to give.
Letting the goods received not invoiced account drift. An unreconciled clearing account hides both a missing invoice and a missing receipt, and an aged residual can sit for a year, which is close to the median time a fraud runs before anyone notices. A balance nobody reconciles is where a duplicate or a phantom receipt goes to hide.
Guarding the invoice while leaving the vendor master open. The costliest miss is not a fake bill, it is a real bill paid to a changed account. If bank details can be edited without an independent check, a perfect three-way match still sends the money to the wrong place, because the match verified the purchase and not the payee.
Treating a duplicate as a harmless slip. A second copy of a genuine invoice, paid because it matched a real order and receipt that were already cleared, is a straight loss that the match should catch through the clearing account and duplicate checks. Without those, the same delivery gets paid twice and the overpayment is found, if ever, at a later reconciliation.
Buying automation before the data is clean. Touchless matching is a real prize, but it multiplies whatever it sits on. Automating a process with missing receipts, loose tolerances, and an open vendor master just approves bad invoices faster, so the order of work is clean data first, then speed.

What this asks of the data model.

The purchase order is the internal authorization, held before the invoice. It records the approved price, quantity, and terms, and it is created inside your own limits, so the match checks each invoice against a decision the company already made rather than against the invoice alone.
The goods receipt is an independent record of receipt, not a copy of the invoice. It carries quantity, date, and condition from actual delivery, and it is the one document a remote party cannot fabricate, which is precisely why it belongs in the match.
The invoice is compared on defined fields, not accepted on trust. Price is matched to the order and quantity to the receipt, and the amount that clears is the amount all three support, so an inflated, padded, or duplicate invoice has nothing to rest on.
Tolerances are governed numbers with an owner. The permitted price and quantity variance is set on purpose, reviewed as prices change, and tight enough that a genuine overbill blocks, so the tolerance is a control rather than a default nobody chose.
The goods received not invoiced account is the ledger mirror of the match. It carries the liability from receipt to invoice, nets to zero when the two sides meet, and turns unbilled receipts into a clean accrual, so an aged balance is a signal rather than noise.
The vendor master is a controlled record, and bank details are its crown jewels. Payment instructions change only through an independent verification, and every change is logged, so a redirected payment is caught at the source rather than discovered when a supplier chases an unpaid invoice.
Matching level is a property of the purchase, set deliberately. Two-way, three-way, or four-way matching is chosen per category or supplier, so a service with no goods receipt and a stocked part with a physical one each get the check that fits, rather than a single rule that either blocks everything or protects nothing.
Completeness reduces to one exception query. Any invoice paid without an order or a receipt, any bill above the quantity received, any unverified bank change, and any aged clearing line is the exception list, and it can run before you rely on the control rather than surfacing in a loss.

The evidence to keep.

The purchase orders behind paid invoices, showing that each spend was authorized inside approval limits before the invoice arrived, so payment traces to an internal decision rather than to the invoice alone.
The goods receipts matched to invoices, evidencing that what was billed was checked against what your own receiving function recorded as delivered, with quantity and date.
The match results per invoice, showing the price and quantity checks, the tolerance applied, and whether the invoice passed, blocked, or was reviewed, so a reader can see the control ran on every payable.
The exception and hold queue with its resolutions, showing that blocked invoices were investigated and cleared with a reason, not released under pressure, and naming the owner who resolved each one.
The goods received not invoiced reconciliation, tracing the closing accrual to unbilled receipts and explaining any aged residual, so the clearing account is evidenced rather than carried as an unknown.
The vendor master change log for bank details, showing that each change was independently verified through a trusted channel and recording who changed what and when, so a redirected payment leaves a trail.
The duplicate payment checks, evidencing that a second copy of an invoice already matched and cleared is caught before it is paid, and that recoveries, if any, are tracked.
The exception query output, ideally empty, listing any invoice paid without an order or receipt, any overbill, any unverified bank change, and any aged clearing line, so the gaps were checked before the control was relied on.

Questions worth asking in your own review.

Can we show, for any paid invoice, the purchase order that authorized it and the goods receipt that confirms what arrived, or do some payments rest on the invoice alone?
Is the goods receipt booked from actual delivery by our own people, or is it sometimes created from the invoice, so the invoice ends up checking itself?
Who owns our price and quantity tolerances, when were they last reviewed, and are they tight enough that a padded quantity or an inflated price actually blocks?
When an invoice is blocked, does it stop and wait for a resolved variance, or can it be released to payment to keep the queue short?
Do we reconcile the goods received not invoiced account every period, book unbilled receipts as an accrual, and investigate anything aged?
Can a vendor bank account be changed without an independent verification through a channel we already trust, and is every change logged?
Do we check for duplicate invoices against orders and receipts already cleared, so the same delivery cannot be paid twice?
Could we produce, today, a list of every invoice paid with no matching order or receipt, every overbill, and every unverified bank change?

What this adds up to.

The fraud that costs businesses the most is aimed at the one record in a purchase that comes from outside, the invoice, and the tools to forge a convincing one have never been cheaper. The reassuring answer is that the control was built for exactly this, long before anyone could generate a flawless fake in seconds. A three-way match does not ask whether an invoice looks real. It asks whether the invoice agrees with an order you approved and a receipt you booked, and it pays only what all three support.

The build that makes it real is small and pays off twice. Require a purchase order where you can, capture a goods receipt from actual delivery rather than from the invoice, and set tolerances on purpose. Block invoices outside tolerance instead of paying and chasing, reconcile the goods received not invoiced account every period, and lock down changes to vendor bank details with an independent check. Do that and the same records that stop a bad payment give you a clean accrual, a faster close, and evidence an auditor can read without a scramble.

If there is one place to start, run the exception query against your own payables before you lean on the control: every invoice paid with no matching order, every one with no matching receipt, every bill for more than was received, every vendor bank change with no verification on file, and every aged clearing line. For a tidy operation that list is short and the work is a week. For a messy one it is the work, and it is far better found now, at the desk, than discovered in a payment that has already left and will not come back.

Sources.

The 2025 loss totals, the ranking and size of business email compromise, the share of funds leaving by wire or ACH, the definition of business email compromise, and the figures on AI in cybercrime were read directly from the FBI Internet Crime Complaint Center 2025 Internet Crime Report as a PDF, with the FBI business email compromise topic page used for the plain description and the guidance to verify payment and vendor detail changes through a second channel. The frequency and median loss of asset misappropriation, billing schemes, and check and payment tampering, and the finding on how long a fraud runs before detection, were read directly from the ACFE Occupational Fraud 2024: A Report to the Nations PDF. The two-way, three-way, and four-way matching definitions, the role of tolerances and holds, and the goods received not invoiced clearing account follow the standard behaviour documented by Oracle Payables and SAP Logistics Invoice Verification. No embedded posts from X appear here, because no public post on this topic could be verified as current, relevant, and authentic at the time of writing, and an unverified embed is worse than none. Nothing here is accounting, audit, or legal advice for a specific company. The figures, names, and dates in the worked example and the record are placeholders for shape rather than real values, and how a given company runs its match depends on its own systems, suppliers, and risk.