Three-Way Matching Explained (With the Exceptions That Cause Most Delays)

Three-way matching is the least glamorous control in finance and one of the most effective. It answers a simple question before money leaves: did we agree to this, did we receive it, and is this the price we agreed?

The three documents

• The purchase order: what was ordered, at what price, on what terms.
• The goods receipt: what physically arrived, in what quantity, when.
• The supplier invoice: what you are being asked to pay.

If quantities and prices reconcile across all three, the invoice is cleared for payment. If they do not, it becomes an exception and a human looks at it.

Two-way matching and when it is enough

Two-way matching compares the PO and the invoice only, skipping the receipt. It is appropriate for services and subscriptions where there is nothing to receive. Applying three-way matching to a monthly software invoice creates work without adding control.

Where matching actually breaks

In practice the exception queue is dominated by five situations, and only one of them is a real problem.

Why the last exception is the real one

An invoice with no purchase order behind it cannot be matched at all. Accounts payable is then asked to validate a purchase they had no visibility into, usually after the goods are consumed and the supplier is chasing payment. That is not an AP problem. It is a requisition problem, and it gets solved upstream.

That pattern has a name and a measurable rate: see maverick spend for how to quantify it by department, and purchase requisition vs purchase order for why the requisition step is the only place it can be stopped cheaply.

Making matching fast

1. 1Generate POs from approved requisitions so the PO data is already clean.
2. 2Make receiving a one-tap action for the person who requested the item.
3. 3Set tolerances by category rather than one global rule.
4. 4Route exceptions to the budget owner, not to a shared AP inbox.
5. 5Review the exception reasons monthly and fix the top cause.

Done well, the majority of invoices should clear without a human touching them, and the exceptions that remain should each be worth the minute it takes to resolve.

Start with the operating case, not the feature list

Context matters in invoice matching because the visible transaction is only the final record of several earlier decisions. Consider this operating case: A supplier invoices 100 units, the PO says 100, and the warehouse records 92 because eight remain on a later truck. A zero-tolerance rule blocks the whole invoice even though the commercial position is understood. The useful question is not whether a form was completed. It is whether the evidence available at that moment was sufficient for a named owner to make a reversible, explainable decision. That distinction keeps the process practical: control is attached to consequence, not paperwork.

Trace one ordinary case and one awkward case from the first request to the final accounting entry. Record who knew what, which system held it, and what happened when the expected path failed. This exposes handoffs that a workshop diagram misses: the spreadsheet used to repair supplier names, the inbox where an approver asks for context, or the monthly reconciliation that makes reports believable after the fact.

Evidence to assemble before changing the process

Do not begin configuration with a blank workflow canvas. Build a small evidence pack first. It should be compact enough for the working team to challenge line by line, and representative enough that a successful pilot means something. The minimum useful pack contains the following inputs.

• PO lines with quantity, unit price, tax, freight, and delivery terms
• Receipts recorded against the correct line and delivery
• Invoice lines captured without collapsing detail into a total
• Tolerance rules that distinguish price, quantity, tax, and freight variance

The decisions the workflow must make explicit

A dependable invoice matching process does not ask everyone to approve everything. It identifies a small set of decisions, assigns each to the person with the authority and information to make it, and records enough context to explain the result later. If two reviewers are checking the same fact, remove one. If nobody can state what would cause rejection, the step is probably ceremonial.

• Whether two-way or three-way matching fits the category
• Which variances can clear automatically and which need an owner
• Whether partial deliveries can be paid proportionately
• Who resolves each exception without routing everything to accounts payable

Write these decisions as testable statements. For example: approve when the budget is available and the need is valid; route to security only when company data enters the service; reject when the supplier identity cannot be verified. Testable rules make demos, implementation workshops, and post-launch audits materially more useful than labels such as finance review or procurement check.

A practical implementation sequence

Sequence matters because teams otherwise automate the cleanest diagram and discover the real exceptions after launch. Keep the first release narrow, but do not make it artificially easy. Include enough volume to observe behaviour and at least one category with meaningful exceptions. A sensible sequence is:

1. 1Start with clean PO and receipt identifiers
2. 2Match at line level where quantities matter
3. 3Route only the failed dimension to the accountable person
4. 4Review exception codes monthly and remove the upstream cause

At each step, preserve a manual recovery path and name the person allowed to use it. Recovery is not failure; invisible recovery is. An exception handled in a private message teaches the system nothing. An exception recorded with a reason can inform the next policy or configuration change.

Failure modes worth testing before launch

Happy-path acceptance testing proves very little. Build tests from the cases that cause delay, uncontrolled commitment, duplicate work, or misleading reporting. The following failures are common enough to deserve an explicit owner and expected response before rollout.

• Applying zero tolerance to freight and rounding
• Requiring receipts for subscriptions that have no physical delivery
• Sending all exceptions to a shared finance queue
• Hiding no-PO invoices inside a generic price-variance code

Run these as tabletop exercises with the requester, approver, finance operator, and system administrator in the same room. If the answer depends on somebody remembering an unwritten convention, document it or redesign the path. If the answer requires administrator intervention for an ordinary exception, calculate that support load before declaring the workflow scalable.

Measure the control without gaming it

A metric needs a stable denominator, a reproducible source, and an owner who can change the result. Publish the definition beside the number. Show medians with a tail percentile where time is involved, and split rates by material populations rather than averaging unlike work together.

• First-pass match rate
• Touchless invoice rate
• Median age by exception reason
• Share of exceptions caused by missing receipts or missing POs

Review the underlying records monthly during rollout, then quarterly once behaviour stabilises. A rising exception rate can mean the process is deteriorating, but it can also mean the system has started recording exceptions that were previously invisible. Interpret the movement before rewarding or correcting anyone.

Limits and cases that need a different tool

No invoice matching design is universal. State exclusions before estimating benefits. That protects the business case from inflated addressable volume and tells operators where a different control, specialist system, or human judgement remains necessary.

• Matching proves agreement between records, not that the purchase was wise
• Fraud using collusive records can still pass
• Poor invoice line extraction creates false exceptions
• Service acceptance often requires judgement rather than a delivery count

Keep a decision record that survives the project

For each material choice, record the date, owner, evidence considered, option selected, rejected alternatives, and the condition that would trigger review. This is not meeting minutes. It is a compact explanation of why the company accepted a particular cost or risk. Six months later, a new operator should be able to distinguish an intentional compromise from an accidental omission without locating the original project team.

Use the record during monthly operations reviews. Compare the assumptions made at approval with actual volume, cycle time, exceptions, and supplier behaviour. When an assumption fails, change the rule or reopen the decision; do not quietly build manual work around it. That feedback loop is what turns a configured workflow into an operating system rather than a frozen implementation project.

The final design should be easier to explain than the process it replaces. If a requester cannot predict what information will be required and who will decide, complexity has merely moved behind the screen. Keep the common path short, make consequential exceptions visible, and revisit the rules when transaction patterns or organisational ownership change.