A three way match in accounts payable compares the purchase order, the receiving record and the vendor invoice before anyone pays. If the items, quantities and prices agree within set tolerances, the invoice is approved. If not, it is held as an exception until someone fixes it. The final link is matching the approved invoice to the bank payment.
What does a three-way match compare in accounts payable?
A three-way match compares three documents: the purchase order, which records what the business agreed to buy and at what price; the receiving report, which records what actually arrived; and the vendor invoice, which records what the vendor is charging. Agreement between all three shows the business is paying only for goods it ordered and received.
Each document answers a different question. The purchase order answers "did we authorise this?" The receiving report answers "did we get it?" The invoice answers "what do they want for it?" A two-way match, which compares only the order and the invoice, answers the first and third but not the second. That gap is why receiving matters: without it, a vendor could bill for a full order when only half was delivered, and the invoice would still agree with the purchase order.
The three documents should come from three different people or functions. Purchasing raises the order, the warehouse or the requester records receipt, and accounts payable enters the invoice. When one person can do all three, the match proves very little, because the same person could create a matching set for a fictitious purchase.
The match runs before payment, not after. Its job is to stop an incorrect invoice reaching the payment run, which is far cheaper than recovering money afterwards.
Purchase order, receiving report and vendor invoice fields that must agree
The match compares fields line by line, not just the invoice total. For each line, the item or part number, the quantity, the unit price and the unit of measure should agree across all three documents. At the header level, the vendor, the purchase order number and the ship-to location should agree too.
A line-level comparison catches errors a total would hide. An invoice can total the same as the order while charging a higher price for one item and billing fewer units of another. Checking each line separately exposes both.
The fields worth comparing, and what a mismatch usually means:
| Field | Compared across | A mismatch usually means |
|---|---|---|
| Vendor | PO and invoice | Invoice from a related or different entity, or a typing error |
| PO number | All three | Invoice not tied to an order, or tied to the wrong one |
| Item or part number | All three | Substitute item shipped, or vendor's own code used |
| Quantity | Receipt and invoice | Short shipment, back order or billing ahead of delivery |
| Unit price | PO and invoice | Price increase, expired quote or wrong price list |
| Unit of measure | All three | Cases against units, which looks like a large quantity error |
| Freight and taxes | PO terms and invoice | Charges the order did not allow for |
Unit of measure deserves a note. A purchase order for 10 cases and a receipt of 120 units can both be correct, but an automated match will flag them unless the conversion is set up.
Price and quantity tolerances in a three-way match
A tolerance is the size of difference the match allows before holding an invoice. Most businesses set one for price, as a percentage or an amount per line, and one for quantity. Differences inside tolerance pass automatically; differences outside it stop the invoice for review. Tolerances should be small, written down and approved.
Tolerances exist because tiny differences are common and not worth a person's time: a few cents of rounding, a freight charge within an agreed range. Without them, the exception queue fills with noise and real problems get missed.
The risk runs the other way too. A tolerance that is too wide lets a vendor overcharge on every invoice without triggering a review. A price tolerance of a few percent on a large recurring purchase can add up to real money over a year. Set tolerances by looking at the size of the business's typical lines, and review the total value of differences passed under tolerance each quarter.
Quantity tolerances are usually tighter in one direction. Being billed for fewer units than were received is rarely a problem. Being billed for more units than were received should almost always stop the invoice, since the business would be paying for goods it does not have.
The example below runs one purchase order through the match. All values are made up for illustration, with a price tolerance of 2% per line and no tolerance for quantity billed above receipt.
| Line (example) | PO qty | PO price | Received | Invoiced qty | Invoiced price | Result |
|---|---|---|---|---|---|---|
| 1. Steel brackets | 200 | 4.50 | 200 | 200 | 4.55 | Pass: price 1.1% over, inside tolerance |
| 2. Hinges, box of 50 | 40 | 18.00 | 32 | 40 | 18.00 | Hold: billed 8 boxes not received |
| 3. Fasteners, case | 10 | 62.00 | 10 | 10 | 66.00 | Hold: price 6.5% over, outside tolerance |
| 4. Freight | 1 | 75.00 | 1 | 1 | 75.00 | Pass |
Line 2 goes back to receiving to confirm the short shipment, then to the vendor for a corrected invoice or a credit. Line 3 goes to purchasing to confirm whether the price increase was agreed. Lines 1 and 4 can be approved now if the system allows partial approval.
How should three-way match exceptions be resolved?
Each kind of mismatch has an owner. Purchasing resolves price and item differences with the vendor. Receiving confirms or corrects quantities. Accounts payable resolves entry errors and chases corrected invoices. An exception is closed only by a document: a revised order, a corrected receipt, a credit memo or a written approval.
The worst outcome is an exception closed by someone editing the purchase order to match the invoice. That makes the match pass while removing the evidence that anything was wrong. If an order needs changing, the change should go through the person who approved the original order, and the system should keep the history.
An exception log helps. Record each held invoice, the reason, the owner, the date raised and the date closed. Review it weekly. A vendor that appears again and again on the log has a pricing or shipping problem worth raising directly. An owner whose items sit for weeks is a bottleneck that will eventually lead to late payments and lost early-payment discounts.
Some exceptions are legitimate and recurring, such as a vendor that always ships in slightly different quantities. Fix those at the source by adjusting the order or the tolerance for that vendor, with approval, rather than overriding the hold each time.
Tying the matched invoice to the vendor payment on the bank statement
The three-way match approves an invoice; it does not prove the right money left the bank. Close the loop by matching each payment on the bank statement to the approved invoices it settles: same vendor, same amount, same remittance account. That last step catches payments to changed bank details and invoices paid twice.
Payments can go wrong after the match. A vendor's bank details may be changed before the run, sending money to a fraudster. The same invoice may be paid twice, once in a batch and once by a manual check. A payment may be made for an invoice that was still on hold. Each of these passes the three-way match and fails the payment tie-out.
Work from the bank side. List every vendor payment that cleared in the period, then trace each to its approved invoices in the payables ledger. Payments with no approved invoice, payments larger than the invoices they settle, and invoices paid more than once are the exceptions.
PreciseBankFlow helps on this side of the match: it extracts every payment from the statement, checks that each statement foots, and flags possible duplicates with the same payee and amount on close dates, so the tie-out starts from a complete list.
When a three-way match is the wrong accounts payable control
A three-way match only works where there are physical goods to receive against an order. Services, subscriptions, utilities, rent and payroll-related payments have no receiving report, so forcing them through the match creates fake receipts or endless exceptions. They need a different control suited to how they are billed.
Some common cases and what to use instead:
- Services and professional fees. Use a two-way match against a contract or statement of work, plus written approval from the person who received the service.
- Subscriptions and recurring software charges. Check each charge against the agreed plan and seat count. The routine for reconciling recurring billing to contracts and the bank covers the subscriber side, and the same logic applies when you are the one being billed.
- Utilities and rent. Compare against the lease or the prior period, and investigate unusual changes.
- Online marketplace purchases. Small orders paid by card at checkout are often reconciled to the card statement and order confirmations instead. The post on ecommerce reconciliation from orders to payouts covers how online orders and their payments are tied together.
- Payroll taxes and benefits. These follow from the payroll register, not a purchase order. Reconcile them to the liability accounts, as set out in the guide to reconciling payroll liabilities in QuickBooks.
Low-value purchases are another case. Running a three-way match on a $40 order costs more in staff time than the risk it removes. Many businesses use purchasing cards with a spending limit for small items, reviewed on the monthly card statement. Whichever controls are chosen, write down which spend goes through which control, so nothing ends up with none.