A three-way match test that only looks at paid invoices misses the point of the control. The purchase order, the goods receipt and the invoice have to agree before payment, and the control's job is to hold the invoices that do not. So test the gate, not just the outcome: break the control into seven attributes with documented tolerances, request five documents per sample, and check each sample for the four exceptions below. Most of them hide in a quantity field or an approval limit, not anywhere obvious.
What the three-way match control actually verifies
The control stops payment for anything that was never ordered, never received, or billed at a price nobody agreed. It works only because three records, each created by a different team, have to agree:
- 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. Its quantity must agree to the receipt and its unit price to the PO 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.
Note
Some organizations run a two-way match (PO to invoice only) for indirect spend below a threshold. If a sample includes two-way match transactions, confirm that is the documented policy for that spend category before treating the missing receipt as an exception.
A failed match usually points to a weaker control upstream
The three-way match 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.
Start your 14-day free trial
Bring one control and its evidence. The trial includes 5 AI sample tests and 50 manual ones, no card needed.
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.
| Attribute | Pass criteria | Fail criteria |
|---|---|---|
| Match status | System or manual match status is recorded as Matched before the payment date | Status is unmatched, blocked, or missing at the time payment was made |
| Quantity match | Invoiced quantity agrees to received quantity within the documented tolerance | Quantity variance exceeds tolerance with no documented resolution |
| Price match | Invoiced unit price agrees to the PO price within the documented tolerance | Price variance exceeds tolerance with no documented resolution |
| Vendor match | Invoice vendor matches the PO vendor and the approved vendor master record | Invoice was paid to a different vendor than the PO, or to an unapproved vendor |
| Approval within DOA | Invoice was approved by someone whose delegation-of-authority limit covers the invoice amount | Approver's authorized limit is below the invoice amount, or no named approver is recorded |
| No duplicate invoice | Invoice number, amount, and vendor combination is unique in the payment period tested | Same invoice number, amount, and vendor (or a near match) appears more than once as paid |
| Payment timing | Payment date is on or after the date match status was recorded and approval was granted | Payment date precedes the recorded match or approval date |
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.
How many samples to pull depends on how often the control runs; see SOX sample sizes by control frequency. Missing any one of these documents 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
These are the four exceptions to look for in every sample, and the field where each one hides.
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.
Warning
Escalate a payment-before-approval exception even if you find only one. It can mean the payment run picks up unapproved invoices under some conditions, which is a design gap, not a one-off operating miss. The deficiency classification guide covers how to weigh it.
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 (how SOXLayer's AI testing works, and where AI should stop). 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.
Key takeaways
- The three-way match gates payment on agreement between the PO, the goods receipt, and the invoice, and testing needs to confirm the gate actually held, not just that paid invoices happened to match.
- A testable template breaks the control into distinct attributes: match status, quantity, price, vendor, DOA approval, duplicate check, and payment timing, each with a documented tolerance.
- A complete evidence set spans five documents per sample; missing any one of them usually means the sample is Insufficient, not Pass.
- The exceptions that show up most often are quantity variances, DOA tier breaches, duplicate payments, and payment recorded ahead of approval.
- A payment-before-approval exception is worth escalating even as a single instance, since it can point to a design gap rather than an isolated miss.
- AI-assisted review can test every attribute against all five documents at once and highlight exactly where an exception shows up, leaving the tester to judge the exception rather than hunt for it.
Sources and further reading
The standards and guidance behind this article. Your external auditor's methodology and your company's own policy still set the requirements for your program.
- PCAOB AS 1105, Audit Evidence: what makes evidence relevant and reliable.
- PCAOB AS 2315, Audit Sampling: how sample size, selection and evaluation are planned for tests of controls.
- COSO, Internal Control: Integrated Framework: the framework most companies use to design and evaluate ICFR.
Read these next
Interim vs roll-forward testing: how to plan the SOX year
How to set an interim cutoff, size roll forward samples proportionally, and plan a SOX year that avoids a year end crunch.
How many samples? A practical guide to SOX sample sizes by control frequency
A practical breakdown of SOX sample sizes by control frequency, with illustrative ranges, rounding rules and common testing mistakes.
AI in control testing: what it should and should not do
Why every AI verdict in SOX testing needs a quoted line and page, and why no AI result should change a test status until a person accepts it.