Three-way match

What it does

Matches purchase orders to vendor invoices to receiving records — did the company order it, receive it, and get billed correctly for it — and rolls the exceptions up by vendor.

The control is old and well understood. What makes testing it valuable is that the failures are almost never random. Duplicate payments cluster around the same handful of vendors, because the cause is a process defect: an invoice submitted twice under slightly different numbers, a credit memo never applied, a PO closed and reopened. Price variances cluster too, because someone is invoicing off a stale price list. The pattern matters more than the individual exception, so the output is organised to make patterns visible rather than to produce a long flat list.

Duplicate detection runs four patterns, including same-amount-within-a-window and same-PO-line-billed-twice — the duplicates an exact invoice-number check misses.

What it proves

The population is proven before it is analysed:

• Every invoice is accounted for — matched invoices plus exceptions must equal the full invoice population, in count and in value. An invoice that quietly falls out of the middle of a matching routine is the one worth finding, so the script balances the population and refuses to report until it does.
• The population ties to a stated control total — the AP subledger or the GL purchases figure. Testing a filtered extract proves nothing about the account.
• No invoice is matched twice — a PO line consumed by one invoice is not available to another, otherwise a duplicate looks like a match.
• Tolerances are stated, not assumed — quantity and price tolerance come from the client's own policy and are recorded on the workpaper.

Where the client has no written tolerance policy, that is itself a finding: it runs at zero tolerance, says so, and reports the absence as a control observation.

What you get

Seven tabs:

1. Summary — population proof, tolerances used, outcome counts and values, recovery opportunity quantified, control observations. The page a controller reads.
2. Population Proof — matched plus exceptions equals the population in count and value, with the tie to the control total. The gate, shown.
3. Exceptions by Vendor — vendor rollup with counts, values, and the dominant exception type. Read before the detail.
4. Exception Detail — every exception line with PO, receipt and invoice figures, variance in units and dollars, and columns for investigation and disposition.
5. Duplicates — grouped, with which pattern caught each and the amount at risk.
6. GRNI — goods received not invoiced, with age, quantified as a period-end accrual.
7. Matched Detail — clean matches with the rule that matched them, for re-performance.

Where it stops

It reports attributes, not intent. Invoices repeatedly just below an approval threshold, a vendor whose bank details changed shortly before a payment, a vendor address matching an employee record, receiving records created after the invoice date near period end — each is stated as a fact with the supporting documents and escalated to the engagement. It does not characterise what it means.