3 way matching in accounts payable

3 way matching in accounts payable means you only pay an invoice after three documents agree: the purchase order that says what you agreed to buy, the receiving record that says what actually arrived, and the vendor invoice that says what you are being charged. If the item, quantity and price line up within the limits you set, the invoice is approved for payment. If they do not, someone looks before money leaves the account.

The control stops the most expensive payables mistakes: paying for goods that never arrived, paying a price nobody agreed to, and paying the same invoice twice. Done by hand it takes real clerk time, and the checking tends to get thinner exactly when volume rises.

Below: a worked example, the matching types compared, tolerances and partial deliveries, how to automate the match so a person only sees real exceptions, and when the control is overkill.

Where manual matching costs money

Paying for goods that never arrived

When the receiving record is missing or late, AP either holds a valid invoice or pays it on trust. A short shipment paid in full is money lost until someone notices and claims a credit.

Price creep nobody approved

A vendor bills slightly above the PO price. One line at a time it looks like rounding. Across a year it is real margin.

Duplicate invoices

The same invoice arrives by email and by post, or is resent with a new number. Without a check on vendor, amount and PO, both get paid.

Late payments and lost discounts

Invoices wait for someone to match them, vendors chase, and early payment discounts expire.

Exceptions with no owner

A mismatch is flagged, but nobody knows whether purchasing, the warehouse or the budget owner should resolve it, so the close waits.

What 3 way matching means, with a worked example

Each document answers a different question. The purchase order: what did we agree to buy, at what price. The receiving record, or goods receipt: what physically arrived and was accepted. The invoice: what the vendor wants to be paid. Matching compares them line by line, not just on the total.

Take a PO for 100 boxes of shipping cartons at 12.00 per box. The warehouse records 100 received. The invoice bills 100 at 12.00. All three agree, so the invoice is approved for payment on its terms. The table below changes one fact at a time. Each change produces a different outcome and a different person who should deal with it.

The amounts are illustrations in a generic currency, and the tolerance is an example, not a recommendation.

Two way, three way and four way matching compared

Two way matching compares only the PO and the invoice. It confirms the billed price and quantity, not that anything arrived. It fits services and subscriptions.

Three way matching adds the receiving record, so you also confirm delivery. It is the standard for physical goods bought on a PO: inventory, materials, parts and supplies.

Four way matching adds an inspection record, so you pay only for goods that passed inspection. It suits manufacturers and labs. Many businesses run all three by category, which is an accounts payable best practice: strict where it matters, light where it does not.

Tolerances, partial shipments and price variances

A tolerance is the difference you accept without human review. Without one, every rounding cent and freight line becomes an exception, and the team learns to approve exceptions without reading them. That is worse than no control.

Tolerances are usually a percentage, a fixed amount, or whichever is smaller, set by vendor or category: some room on low value supplies, none on contract priced items. Quantity tolerances work the same way.

Partial shipments need matching at the line and receipt level. If 60 of 100 boxes arrive and the vendor invoices 60, the match passes and 40 stay open on the PO. If the vendor invoices 100 against a receipt of 60, policy decides whether to hold it all or approve 60. Write that rule down before you automate it, because software applies whatever you tell it, every time.

• Price variance: invoice price differs from the PO. Route to the buyer.
• Quantity variance: billed more than received. Route to receiving.
• Missing receipt: goods may have arrived unrecorded. Route to receiving with a deadline.
• No PO: the purchase skipped the process. Route to the budget owner and fix at the source.

Why manual matching breaks as volume grows

At a low weekly volume, a careful person with a spreadsheet can match everything. As volume climbs, the same person matches totals instead of lines, skips small invoices and waves through familiar vendors. The control exists on paper. In practice it is a signature.

The data is also scattered: POs in the accounting system, receipts in a warehouse app, invoices as PDFs in a shared inbox. Much of the clerk's time goes to finding and retyping, not judgment. That is the part worth automating.

How an automated 3 way match works step by step

An automated accounts payable workflow does the finding, reading and comparing, then hands a person only the invoices outside your rules. It applies your policy consistently and logs every decision, so a controller can see why an invoice was paid.

Benian builds this as workflow automation inside accounts the client owns, connected to the accounting system, the invoice inbox and wherever receiving is recorded. Invoice reading uses AI document extraction, and every extracted field that drives a decision is checked against the PO and receipt, not trusted alone. Low confidence sends the invoice to a person instead of a guess.

Routing exceptions to the right approver

A large share of the time saved comes from routing, not matching. An exception sent to a general AP inbox waits. One sent to the buyer who placed the PO, with the three documents side by side and the difference highlighted, gets answered.

Good routing names one owner per exception type, sets a deadline, escalates when it passes and records each decision with a reason. A report of exceptions by vendor and type shows patterns, such as one vendor causing most price variances. That reporting is where data intelligence work adds to the match.

Accounts payable procedures that make matching possible

Automation cannot match documents that do not exist. Three accounts payable procedures come first.

Purchase orders with line items and agreed prices, created before the order is placed. A receiving step that records what arrived, against the PO, on the day it arrives. A clean vendor master with one record per vendor and a controlled process for changing bank details, since a changed bank account is a common payment fraud route. If any is missing, the honest first project is the procedure, not the automation.

When 3 way matching is overkill for a small business

If you buy mostly services, two way matching or a simple approval is enough. If the owner approves every bill and knows every vendor, a formal match adds friction without much protection.

It earns its place when you buy physical goods from many vendors, when the person paying is not the person who ordered or received, or when volume has outgrown careful review. If unsure, start smaller: match only your top vendors by spend for a quarter and count the exceptions it finds. Benian's free Opportunity Map can check whether AP is your real bottleneck before you spend on it.

Illustrative match outcomes for one PO line: 100 boxes at 12.00, with an example price tolerance of 1 percent

The automated matching process

1. Capture the invoice. Invoices from email, portals or scans land in one queue and are checked for duplicates on vendor, number, amount and date.
2. Extract the lines. Vendor, PO number, lines, quantities and prices are read. Low confidence fields go to a person.
3. Find the PO and receipts. The workflow pulls the PO and every receipt recorded against it.
4. Compare line by line. Price and quantity are checked against your tolerances, including partial receipts and open lines.
5. Approve or route. Matches are marked ready to pay in the accounting system. Exceptions go to their named owner with the difference shown.
6. Record and report. Every decision is logged with its reason, and exceptions are counted by vendor and type.