Three-way match test data: order, receipt, invoice
The three-way match is the oldest control in accounts payable: a purchase order, a goods receipt and a supplier invoice must agree before money moves. Testing it needs data where the chain is complete, where the exceptions are real exceptions, and where somebody has written down which is which. Production data fails the last two: nobody labelled it, and you cannot take it out of the building.
On SAP, the order sits in EKKO and EKPO, the goods movement in MSEG, the invoice in BKPF and BSEG, and the payment in PAYR with its cheque or transfer reference. On Oracle Cloud the same chain runs through PO_HEADERS and PO_LINES, receiving transactions, AP_INVOICES and AP_PAYMENTS. Every link resolves: no invoice points at a purchase order that does not exist, and no payment clears an invoice that was never entered.
Quantities are compared the way a system compares them, with a tolerance rather than an exact equality, so a delivery half a unit short is not an exception and a delivery thirty percent short is. Each line resolves to one of four states, and the state is computed from the documents rather than stored in a status column that would give the answer away.
A match failure vector plants invoices paid against receipts that never covered the ordered quantity, recorded in the ground-truth answer key at the moment it is planted. Beside them sit the innocent versions that make a real payables ledger messy: backorders billed at the value actually received, and a non-purchase-order expense desk where rent, utilities, insurance and telecom are invoiced with no order and no receipt because that is how those bills arrive. A rule that flags every invoice without a goods receipt will therefore be wrong, which is the point: it can be measured.
Matching is only half of the control. Orders carry release states with the release events recorded as change documents, invoices carry a block that has to be lifted by a named person on a dated event before a payment run touches them, and Oracle carries the equivalent as invoice holds with hold and release rows. Three approval schemes are planted on that trail, including self-approval above authority and a release recorded after the payment already cleared, each with an innocent member that looks identical in any status column and separates only through the event order.
In the hosted ERP environment you can open a purchase order the way a practitioner would, read its release history, follow it to the invoice and the block that held it, then to the payment run and finally to the bank statement line that cleared the cash. The same world downloads as a database and workbooks, up to a million documents per cycle on the SAP platforms, so what you verified by eye you can then test at scale.