The three-way match control: how to test it well

The three-way match is one of the most heavily relied on controls in the procure-to-pay cycle, and one of the easiest to test poorly. On paper it is simple: before an invoice gets paid, the purchase order, the goods receipt, and the invoice itself all have to agree. In practice, testing it well means chasing down three separate documents per sample, checking several attributes against each, and catching exceptions that often hide in a quantity field or an approval limit rather than anywhere obvious. This post walks through what the control is actually verifying, how to build a test template that holds up under review, what evidence to request, and the exceptions testers run into most often.

Because the control sits directly in front of a cash disbursement, it usually gets flagged as a key control in any SOX program that scopes procure-to-pay, and it tends to draw more scrutiny from external auditors than most other spend controls. A three-way match that is well designed but poorly tested is still a gap in the evidence trail, even if the control itself is operating fine.

What the three-way match control actually verifies

The control exists to prevent payment for goods or services that were never ordered, never received, or never priced the way they were agreed. It does this by requiring agreement across three independent records, each created by a different part of the process:

• Purchase order (PO): what was ordered, at what price, and from which vendor, authorized before the spend occurred.
• Goods receipt (or service confirmation): evidence that what was ordered actually arrived, in the quantity received, confirmed by someone independent of the person who placed the order.
• Invoice: what the vendor is billing for, which should reconcile to both the PO and the receipt before payment is released.

When all three agree within an organization's defined tolerances, the system or the accounts payable team releases the invoice for payment. When they do not agree, the invoice should be held until someone resolves the discrepancy. That hold is the entire point of the control: it is a gate, not a formality, and testing needs to confirm the gate actually stopped invoices that did not match, not just that matched invoices got paid.

Why it matters as a key control

Procure-to-pay is one of the few cycles where the risk of loss is direct: a control failure here does not just create a misstatement risk, it can mean money actually leaves the company for something that was never received or never approved at the right level. That is why the three-way match is almost always in scope as a key control wherever the RCM covers purchasing, accounts payable, or disbursements, and why it is frequently tied to the existence and valuation assertions for accounts payable and expense balances.

It is also a control that touches several other controls at once. A breakdown in the three-way match often points to a weaker control somewhere upstream, such as PO approval limits not being enforced, receiving not being performed independently, or vendor master data allowing duplicate records. Testers who only check the match status and stop there tend to miss those upstream signals.

Attributes a good test template defines

A three-way match test template should break the control into distinct, checkable attributes rather than a single pass or fail judgment on "did it match." Each attribute needs its own pass and fail criteria so a tester (or an AI doing the first pass) knows exactly what to check and a reviewer can see exactly what was checked.

Tolerances matter here more than in most controls. A test template that just says "quantities and prices must match" without stating the tolerance (a fixed dollar amount, a percentage, or zero tolerance for certain spend categories) leaves the tester guessing, and different testers will apply different judgment calls to the same sample. Document the tolerance in the RCM and carry it into the test template, not just in a policy document nobody pulls up during testing.

Evidence to request for each sample

Because the control spans three (or four, counting approval and payment) separate systems or documents, evidence collection for a three-way match sample is naturally heavier than for a single-approver control. A complete evidence set per sample should include:

• The purchase order, showing vendor, item or service description, quantity, unit price, and the approver who authorized it.
• The goods receipt or service confirmation, showing quantity received, date received, and who confirmed receipt.
• The vendor invoice, showing invoice number, invoice date, quantity billed, unit price, and total amount.
• The approval record for the invoice, showing who approved payment and the date of approval.
• The payment record, showing payment date, amount, and method, tying back to the invoice number.
• System-generated match status output, if the ERP performs the match automatically, or the manual matching worksheet if it does not.

Missing any one of these is usually enough to make a sample Insufficient rather than Pass, since the tester cannot actually confirm agreement across all three records without all three documents in hand. This is also where testing time tends to balloon: chasing a missing goods receipt from a warehouse team or a scanned invoice buried in an email thread is often the slowest part of the test, not the comparison itself.

Common exceptions testers actually find

A handful of exception patterns show up repeatedly across three-way match testing, and it helps to know what they look like before a sample lands on a desk.

Quantity variances

The invoice bills for more units than the receipt confirms, often because a partial shipment was invoiced in full, or because a receiving clerk logged the wrong quantity. These are usually caught quickly if the tolerance is documented and applied consistently, but they get missed when the tester eyeballs "close enough" without checking against the actual policy tolerance.

Delegation-of-authority tier breaches

An invoice gets approved by someone whose authorized limit is below the invoice amount, either because the approval routing did not enforce the tier correctly or because someone approved outside their normal role during a vacation or transition period. This exception is easy to miss unless the tester actually cross-references the approver's name against the current DOA table for the date of approval, not just checks that an approval exists.

Duplicate payments

The same invoice, or a near-identical one (same vendor, same amount, a slightly altered invoice number), gets paid twice, usually because it was submitted through two different channels or resubmitted after an initial rejection without the first payment being reversed. Testing for this usually requires looking across the broader payment population for the vendor, not just at the single sample in isolation.

Payment made before proper approval was recorded

The payment date on the record precedes the date the approval or the match status was actually recorded, which suggests the payment ran ahead of the control rather than after it. This is one of the more serious exceptions because it points to a sequencing failure in the control itself, not just a documentation gap.

Where AI-assisted evidence review helps

Testing a three-way match sample by hand means holding four or five documents open at once and cross-checking values across all of them, attribute by attribute. That is exactly the kind of comparison AI can do on the first pass: reading the PO, receipt, invoice, approval record, and payment record together, testing every attribute in the template, and proposing a Pass, Fail, Insufficient, or N/A for each one with a confidence score and the exact quote and page it relied on. Where a quantity or price falls outside tolerance, or an approver's name does not match the current DOA table, SOXLayer draws the exception directly on the source document rather than leaving the tester to find it by scanning line items. A duplicate invoice number gets flagged with a citation to both instances, and a segregation-of-duties conflict, such as the same person requesting and approving the same invoice, gets surfaced live rather than discovered during review.

The tester still has to accept, edit, or override every proposed result, and a low confidence read gets escalated rather than guessed at. What changes is where the tester's time goes: less of it spent hunting for the field that does not match, more of it spent judging whether the flagged exception is actually a control failure or an explainable variance worth documenting and moving past.

SOXLayer Team

Product