A three-way match is a control with a very short definition: before you pay a bill, confirm that what you ordered, what arrived, and what you were billed for all say the same thing. Three documents. Purchase order, goods receipt, vendor bill.
If you close your books on QuickBooks Online or Xero, you have two of them.
The document that is missing
QuickBooks Online's Accounting API carries no item-receipt entity of any name. Item receipts are a QuickBooks Desktop feature; they did not come across to the online product, and there is no endpoint that returns one because there is nothing to return.
Xero looks closer at first glance, because it has a /Receipts endpoint. Read its own specification and the endpoint is for draft expense claim receipts — employee expenses, the coffee and the taxi fare, not goods arriving on a dock. Xero purchase orders go from AUTHORISED straight to BILLED, with no received state in between.
So on both of the ledgers a small book is actually kept on, the receiving event is simply not recorded anywhere. Not badly recorded. Not recorded in an awkward place. Not there.
Why that matters more than it sounds
Without the receipt, "three-way match" collapses into a two-way match: does the bill agree with the order? That catches a price that moved. It does not catch the failure the control exists for — being billed for goods that never arrived. Twenty-four cases on the order, twenty-four on the invoice, twenty-one on the pallet. Both documents agree with each other perfectly, and you are three cases short.
That is not an exotic case. It is short shipments, partial deliveries, damaged units sent back, and the ordinary noise of a supply chain. It is the reason auditors ask about three-way matching in the first place.
What people do instead
Three things, in roughly this order of honesty:
- A two-way match, described internally as a three-way match. The order and the bill agree, so the bill gets paid.
- The delivery-note folder, checked by hand against the bill for the invoices somebody remembered to check.
- Sampling — verify a portion, extrapolate the rest. This is the common one, and it is not a control.
None of these is negligence. They are what is available when the system of record does not hold the document.
What MatchRail does about it
It records the receipt itself.
That is the whole design decision, and it is why the product exists rather than being a report you could have written in your ledger. Purchase orders and bills are pulled out of QuickBooks or Xero, incrementally, since each rail's last watermark. What arrived is recorded in MatchRail, because there is nowhere else to put it. Payments come from Stripe, so money that left before the match passed is flagged rather than discovered later.
Then the three are compared, every night, line by line, in integer cents. What agrees inside tolerance is cleared and you never hear about it. What does not is queued with all three documents side by side and the disputed line marked in each.
MatchRail is not trying to replace your ledger. It has no bills of its own, no payment run and no chart of accounts. It holds exactly one document your ledger does not have, and uses it to answer one question your ledger cannot.
Sources: QuickBooks Online Accounting API entity list · Xero Accounting API — Receipts · Xero Accounting API — Purchase Orders