Three-way match: automating PO, goods receipt and invoice matching with tolerances

Many overpayments are visible on paper before the money leaves. The supplier bills 600 cases, receiving logged 540, and nobody compares the two until the supplier statement fails to reconcile at month end. Checking an invoice against the order and the receipt is repetitive work that people do last, under pressure. It is also work software can do first, once the rules and the owners are agreed. This guide is written for accounts payable teams at companies of roughly 20 to 200 people, and the legal references are US ones.

What does three-way match involve?

Three-way match is an accounts payable control that compares three documents for the same purchase before an invoice is approved:

• Purchase order (PO): what the buyer ordered, at what price, quantity and terms.
• Goods receipt (GRN or receiving report): what physically arrived and when.
• Supplier invoice: what the supplier now asks to be paid.

If the three agree, within limits you set, the invoice is cleared for payment. If not, it is held and someone investigates. The control is often called three-way matching, and it has two close relatives, two-way match and four-way match, compared in the next section.

Two-way vs three-way vs four-way match

The three match types differ in how many documents are compared before an invoice is cleared for payment.

Carrier freight bills follow different contracts and a legal dispute clock, which freight invoice audit covers.

Do US rules require a three-way match?

US federal agencies are required to support invoice payments with receiving documentation, and private companies set their own matching policy.

The US federal government writes this control into its payment rules. 5 CFR 1315.9 says agencies must ensure payment documentation is established to support payment of invoices, including a proper invoice (with vendor name, invoice date, description, price and quantity) and information from receiving reports, delivery tickets and evaluated receipts, such as quantities received and the dates goods were delivered and accepted (5 CFR 1315.9). FAR 32.905 says payment "will be based on receipt of a proper invoice and satisfactory contract performance" and that invoice payments must be supported by a receiving report or other documentation authorizing payment (FAR 32.905). Those rules bind federal agencies, so a private company's matching policy and tolerances are its own to set.

Which fields have to agree?

A match is a set of field checks, not one comparison. These are the ones that catch most real problems.

The FAR also lists unit of measure, unit price, extended price, the order and line item number, and any discount for prompt payment terms as parts of a proper invoice (FAR 32.905).

How do price and quantity tolerances work in three-way match?

Price and quantity tolerances turn an all-or-nothing comparison into a usable control, because they let small, expected differences pass without a person and stop the rest. Set them as a percentage and as an absolute amount together. Dynamics 365 Finance, for example, lets you base price matching on a percentage, an amount, or both (Microsoft Learn). Each fails alone: 2% of a $40,000 line is $800, which is too much to pass unseen, while a flat amount alone floods the queue with pennies on high-volume items.

Set separate limits for quantity, price and charges such as freight, and treat direction differently: an invoice below the PO price rarely needs a person, while one above it often does. Some conditions are hard stops with no tolerance: an unknown supplier, a duplicate invoice number, a goods line with no receipt, or changed bank details.

Which cases break a simple match?

Partial receipts. A PO for 600 cases may arrive in three deliveries. Each invoice has to match what was received so far, not the full order.

Invoice before receipt. The invoice often arrives before the goods are logged. Hold it until the receipt posts rather than rejecting it, and set a time limit after which a person checks whether the goods actually arrived.

Services with no receipt. There is nothing to receive, so use a two-way match plus approval by the budget owner who confirms the work was done.

Blanket POs and releases. One PO covers many deliveries over time, so the match has to work against the remaining balance and the release, not the PO total.

Price changes not yet on the PO. A supplier raises a price by letter and the PO still shows the old one. The invoice fails the match for a legitimate reason, and the fix is updating the PO after the buyer agrees.

Where do three-way match documents and data come from?

The PO lives in your ERP, whether that is NetSuite, SAP, Microsoft Dynamics 365 or Oracle. So does the goods receipt, under different names: an item receipt in NetSuite, a product receipt in Dynamics 365, or a goods receipt posted in SAP, where the value waits in the GR/IR clearing account until the invoice is posted (SAP Help).

An advance ship notice (ASN, EDI 856) tells you what the supplier says is on the way, but it is not proof of receipt. Only the receiving record shows what actually arrived.

Invoices arrive in every format: EDI 810, PDF by email, a supplier portal or a scanned paper copy. SPS Commerce notes that the EDI 810 carries the PO number and that buyers can reconcile it against orders and shipments to verify invoice amounts (SPS Commerce). Structured invoices are the easiest to match. The others must be read first, as covered in AI document processing for invoices, contracts and forms.

What can automation and AI do with a match?

In a three-way match, automation prepares the case and people approve the payment. A workflow reads each invoice into the same fields as the PO and receipt, links it to the right PO and line, and calculates the variances. It applies your tolerances by supplier, category or item. Invoices that match within tolerance continue to your ERP's normal posting and approval path. Invoices that arrive before receipt wait. Everything else becomes a routed exception, listing both values, the variance and the source page.

AI is most useful in the reading and the linking: extracting line items from a PDF, recognizing that "CS", "case" and "12/ct" describe the same pack, and proposing the likely PO when the reference is missing. The comparison and the tolerance arithmetic are ordinary logic. Keeping the two apart makes the results easier to audit.

Microsoft's Dynamics 365 Finance guidance shows the shape of a good exception flow: an invoice with a quantity difference can be saved and matched later to a different receipt, and one with a price outside tolerance can be held until it is approved or a correction arrives (Microsoft Learn). Automation's job in a three-way match is to get each case to the right person with the evidence attached.

Who should receive each three-way match exception?

Name the owner for each exception type before building anything, and attach a deadline tied to a real date.

1. AP specialist: invoice data problems, missing PO references and duplicates. Resolve before the next payment run and before any early payment discount date.
2. Buyer or purchasing: price variances against the PO. Decide before the payment due date: approve and update the PO, or request a credit memo.
3. Receiving or warehouse: receipts that are missing or short. Confirm within the agreed number of working hours, and well before month-end close so accruals are right.
4. Requester or budget owner: confirmation that services were performed. Respond before the payment due date and before month-end cut-off.
5. Vendor master team: any change to remit-to address or bank details. Verify with the supplier through a known contact before anything is paid to the new details.
6. Controller: tolerance overrides, exceptions that have aged past terms and the tolerance policy itself. Review weekly, and before each close.

Escalate on the clock: an exception that sits past the discount date or due date has already cost money.

What should stay with people in a three-way match?

A match prepares a payment decision. It should not make the ones that carry financial responsibility.

Approving payment above tolerance. Paying more than the PO supports is a judgment about the relationship, the goods and the cost.

Accepting a price variance. Only a buyer or budget owner with authority can decide that a higher price is justified, and then the PO should be updated.

Changing supplier bank details. Bank detail changes are a common route for payment fraud. Verification and approval stay with people, and the person who approves payments should not be the one who can change the vendor master.

Write-offs and supplier disputes. Settling a disputed amount, a short delivery or a pricing disagreement is a commercial decision that involves the relationship.

Setting tolerance policy. Finance leadership decides how much variance the business will accept unseen.

Illustrative example: Consider a regional food distributor whose supplier terms are 2/10 net 30. For one PO, the supplier invoices 600 cases at $18.90. The PO price is $18.40, and receiving logged 540 cases, one pallet short. A workflow ties the invoice to the PO and receipt, and finds two exceptions on one invoice. The quantity variance (60 cases) goes to receiving, and the price variance ($0.50 per case, about 2.7%, against tolerances of 1% and $25 per line) goes to the buyer. The invoice is held, not rejected. Receiving confirms the pallet was short shipped, and the buyer confirms no price increase was agreed. The supplier sends a corrected invoice for 540 cases at $18.40, or $9,936 instead of $11,340, before the day 10 discount date, and AP pays that, avoiding $1,404 of overpayment.

How do you know three-way match automation is working?

The useful measures show money kept and errors stopped, not invoices touched.

Overpayments and duplicates caught before payment is the share of billing errors stopped ahead of the payment run, compared with those found later by a statement reconciliation or an audit.

Early payment discounts lost to unresolved exceptions shows whether the queue is costing you money.

Exceptions aged past terms shows whether routing and deadlines work, and which owner or supplier is the bottleneck.

Tolerance overrides and false alarms tracks how often the controller overrides a hold, and how many exceptions are closed with no change. Both point to tolerances set too tight or too loose.

Pull a baseline from the last few months before you start.

How do you start automating three-way match?

1. Choose one supplier group with enough volume to measure, such as your suppliers of stocked goods that invoice against POs.
2. Agree the hard stops and the tolerances with AP, purchasing and receiving, using your recent approved variances as the starting point.
3. Collect 50 to 100 real invoices with their POs and receipts, including the messy ones, and test reading and matching accuracy before connecting anything live.
4. Run the workflow beside the manual process for a defined period and compare what each catches.
5. Add routing, owners and deadlines once the findings are trustworthy, and name who handles each exception type.
6. Extend to the next supplier group or to services only when the first is stable. How to rank candidates is covered in Which business processes to automate first.

How Kastling approaches three-way match automation

Kastling treats invoice matching as a workflow to understand before anything is built, as part of the AI Integration & Automation service. It starts with a free discovery call. A separately scoped paid audit is common next, reviewing how invoices, POs and receipts reach your team, where your ERP holds each one, and where exceptions cost money or discounts today.

The workflow connects to the ERP, receiving and invoice sources you already use. Tolerances are agreed with the people who handle exceptions, each exception goes to a named owner, and payment approval, price variances and bank detail changes stay with your team. We agree up front how success will be measured and test the workflow on your real invoices before it runs live.