The three-way match, and the invoices that fail it

A purchase order, a goods receipt and an invoice, compared. Automating that does not remove the judgment: it moves it into a tolerance table and into whoever may release a held item.

By the Foxnut team · Updated 12 August 2026

What the three-way match actually compares

A three-way match is a check that three separately produced documents agree before a supplier’s claim is accepted: the purchase order, which records what the buyer authorised and on what terms; the goods receipt, which records what physically arrived and when; and the invoice, which records what is being charged. The three are written by different parties at different moments, which is the whole point of the control and also the source of nearly all its trouble. The buyer writes the order, the buyer’s own people write the receipt, the supplier writes the invoice, and none of the three can be reconciled against the others by looking at any one of them. A federal checklist for core financial systems puts the requirement in the plainest available form: the system should be able to automatically match invoices to obligations and receiving reports by document and line item, and should support both two-way matching, of the obligation and the invoice, and three-way matching, of the obligation, the receiving report and the invoice. Getting that check right before anyone builds anything on top of it is most of what a matching control needs before anyone hands it over.

What makes this different from the other things a studio is asked to automate in a supply chain is that nothing here has to be computed or observed. There is no forecast, no image, no sensor and no third-party feed. All three documents already exist, in systems the business already runs, and a machine can compare them faster and more consistently than a person. So the interesting question is never whether the comparison can be automated. It is what counts as agreement, who decides that, and what happens to the items where the answer is no. Those are parameters and policies rather than measurements, which is why an automated match can be fully working and still be a bad control.

This page rules on the control and stops at its edge. How an invoice reaches the business and becomes data, who signs it off once it has cleared, and when money actually leaves the account are separate decisions with separate owners and separate failure modes. Nothing below describes any of them.

	Purchase order	Goods receipt	Invoice
Who writes it	The buyer, before anything happens	The buyer’s receiving or operations staff, at delivery	The supplier, afterwards
What it is evidence of	Authorisation: this was agreed, at this price, in this quantity	Fact: this much of it arrived, on this date, and was accepted on this one	Claim: this is what is owed for it
How it usually goes wrong	It does not exist, because somebody ordered by email or phone	It is posted late, in bulk, or by somebody guessing at quantities	It is correct and still fails, because it arrived before the receipt was posted
What its absence permits	Spending nobody authorised, at prices nobody agreed	Payment for goods that never arrived, which is the classic case	A supplier who has delivered and cannot get an answer

The third column of the last row is worth pausing on, because it is the failure everybody underestimates. A control that holds correct invoices for timing reasons is not a neutral inconvenience. It generates a queue of exceptions that are not errors, it trains the people clearing that queue to treat holds as noise, and it is the most common route by which a working match quietly stops being a control.

Goods receipt matching, and why the middle document is the weak one

The goods receipt is the only one of the three documents the buyer produces about a physical event, and it is the one most often missing, late, incomplete or written by somebody with no reason to care about it. Everything the match can do rests on it. The US federal prompt-payment rules give an unusually concrete specification of what that document has to carry: the name of the vendor, the contract or other authorisation number, a description of the goods or services, the quantities received where applicable, the dates the goods were delivered or the services provided, the dates they were accepted, and the signature or an electronic alternative supported by appropriate internal controls, together with the printed name, telephone number and mailing address of the receiving official.

Two things in that list do real work and are usually collapsed in practice. Delivery and acceptance are separate dates, and the same rules separate the receiving office, which physically receives the goods, from the accepting entity, which may be a different office altogether. A receipt that records only that a pallet appeared conflates a fact somebody can observe with a judgment somebody has to make. And quantities are required only where applicable, which is the regulation admitting the obvious limit: a service has no quantity received and no pallet, so the middle document either becomes a separate acknowledgement that work was performed or it disappears and the match degrades to two documents.

There is a formal version of that degradation and it is worth knowing before designing anything. The same rules define evaluated receipts as the contractually designated use of the acceptance document and the contract as the basis for payment without requiring a separate invoice. In other words, if the receipt is trustworthy enough and the price is already fixed by the contract, the supplier’s invoice becomes redundant and the third document is deleted rather than matched. That is the most under-considered option in this whole subject. A business struggling with invoice exceptions is often really telling you that its receipts are good and its invoices are noise, and the answer to that is fewer documents, not a better comparison of three.

The published invoice formats show the same weakness from the other side. The pan-European invoice specification carries all three of the match’s keys as named fields, and their status is not equal. An invoice must carry either a buyer reference or a purchase order reference, and the purchase order reference is mandatory in the underlying syntax to the point that the specification instructs senders with no purchase order to put the literal value “NA” in the field. The despatch advice reference and the receiving advice reference, which are the fields that would tie an invoice to the goods receipt, are both optional. So is the line-level referenced purchase order line reference, which is the field that makes a line-by-line match possible at all rather than a comparison of totals. The format supports the match. It does not oblige a supplier to supply the parts of it that the third leg needs.

This is also where the four-way variant belongs, since it is the same question asked once more. A four-way match adds an inspection or quality-acceptance document to the three, so that arrival and conformance are separate facts rather than one. It is not a different control; it is the same control with the acceptance judgment split out and given its own evidence, and it is worth the extra document only where a thing can arrive in full and still be unusable. That an incumbent system records “Quality” as a distinct blocking reason, separate from “Quantity” and from “Price”, is the practical trace of that split.

What the decision turns on

Six structural dimensions decide whether a process is worth automating. Three-way matching reads unusually on three of them: its exception rate is set by a parameter rather than observed, its error cost is defined in statute rather than estimated, and the automation changes how the control is audited rather than what it does.

Three-way matching: process profile
Dimension	What it reads on three-way matching	Source
Exception variance	The exception is a variance between documents, and its rate is chosen rather than discovered, because a variance only becomes an exception once it breaches a tolerance somebody set. The federal system checklist treats those tolerances as a first-class configuration item: user-defined variance tolerances by document type, by percentage and by a not-to-exceed dollar threshold, applied when an expenditure exceeds the obligation because of quantity or price variances or additional shipping charges. The kinds of exception are equally well documented rather than emergent: one incumbent system records blocked invoice items against eight named reasons - 'Quality', 'PO price quantity', 'Quantity', 'Price', 'Manual', 'Amount', 'Date/time' and 'Project budget' - plus manual and statistical blocks at header level. Note what 'Date/time' and 'Manual' are doing in that list: some of what a match rejects is a sequencing artefact and some is a human decision, and neither is an error in the document. No verified public measure of exception rates in purchase-order matching was retrieved, so none is quoted here.	GAO-04-763G, questions 126 and 144; SAP invoice verification blocking reasons
Volume	Not invoices, and not suppliers. A machine compares three documents at no marginal cost, so the count that scales is the number of held items a person has to look at and rule on, and that count is a function of the tolerance settings at least as much as of trading volume. It also multiplies with the level the match runs at: the checklist asks for matching by document and line item, and a purchase order with forty lines offers forty chances to disagree where a header-total comparison offers one. The payback condition follows as a condition rather than a figure. The automation pays when the exceptions it raises, at the tolerances the business is actually willing to live with, take less time to clear than the manual comparison it removes - and almost nobody has both of those numbers, because the second one has never been separated from the general run of invoice handling.	GAO-04-763G, questions 204 and 205
Cost of an error	Asymmetric, and the expensive direction is defined by statute rather than estimated. A false hold costs clerical time and supplier goodwill and is absorbed inside the month. A missed mismatch is the failure the control exists for: US federal law counts as improper any payment for a good or service not received and any duplicate payment, and separately requires a payment to be counted as improper when a review cannot discern whether it was proper because of insufficient or lack of documentation - so under that regime the absence of the evidence is itself the defect, not merely a reason to suspect one. The scale of the deliberate version is measurable. In a study of 2,402 occupational fraud cases from 143 countries and territories, billing schemes - causing an employer to issue payment against invoices for fictitious goods or services, inflated invoices, or personal purchases - were 508 cases, 21% of the total, with a median loss of USD 90,000, a median 14 months before detection and a median velocity of USD 6,400 of loss for every month the scheme ran undetected.	31 U.S.C. 3351(4) and 3352(c)(2), quoted in GAO-26-108694; ACFE Report to the Nations 2026
Reversibility	Completely reversible, and that is the risk rather than the comfort. Nothing the control does is hard to undo: a held item can be released, a tolerance can be widened, a block can be removed, and the goods are already in the building either way. The reversal is therefore not an escape hatch from the control - it IS the control, and the only thing standing behind it is who is allowed to perform it. The internal-control standards say so directly: management separates authorisation, processing and recording, review, and custody so that no one individual controls all key aspects of a transaction, and segregation of duties addresses the risk of management override but cannot absolutely prevent it because of the risk of collusion. The fraud population says the same thing from the outside. Across all cases, a third arose from a lack of internal controls, 19% from an override of existing internal controls and 18% from a lack of management review: together 70%. The irreversible artefact, and the only one, is the record of who released what and why.	GAO-14-704G, Principle 10 attributes and paragraphs 10.12 to 10.14; ACFE Report to the Nations 2026, figure 37
Regulatory exposure	The control is named and tested, and automating it changes the examination rather than ending it. For an audited company the match is a transaction-level control activity, and the auditing standard treats an automated one differently on purpose: entirely automated application controls are generally not subject to breakdowns due to human failure, which permits a benchmarking strategy in which the auditor need not repeat the prior year's specific tests provided general controls over program changes, access to programs and computer operations are effective and the control is verified not to have changed since the baseline was established. The condition attached to that concession is the whole story for anyone building one, and the standard states it plainly: the consistent and effective functioning of an automated application control may depend upon the related files, tables, data and parameters. The tolerance table is exactly such a parameter. Automating the match moves the audit off the clerk and onto change control, access rights and the tolerance settings, and the internal-control standards make the same trade in the other direction, noting that automated control activities tend to be more reliable because they are less susceptible to human error.	PCAOB AS 2201, paragraphs .B28 to .B33; GAO-14-704G, paragraphs 10.04 and 10.06
Vendor market maturity	Settled as a capability and unsettled in the data it depends on. No verified public measure of concentration in matching software was retrieved, so none is quoted here. What is documented is that the capability has a fixed published target rather than a moving one: a federal checklist has for two decades asked whether a core financial system can automatically match invoices to obligations and receiving reports by document and line item, and can perform both two-way and three-way matching, which is about as stable a specification as a software market ever gets, and it is why every mid-market finance system already ships the feature. The unsettled half is the input. In the pan-European invoice specification the purchase order reference is effectively compulsory - so compulsory that senders without one are told to transmit the literal 'NA' - while the despatch advice reference, the receiving advice reference and the line-level purchase order line reference are all optional. The market has standardised the comparison and has not standardised the arrival of the data the third leg of the comparison needs.	GAO-04-763G, questions 204 and 205; Peppol BIS Billing 3.0, November 2025 Release

Two of those rows carry the argument. The exception row says the exception rate is a setting, so a business comparing two products on their match rates is comparing two configurations rather than two systems, and any demonstration can be made to look excellent by widening a tolerance nobody was shown. The reversibility row says the control’s entire strength lives in the release path, because everything the machine does can be undone by one person in one click. Those two together explain why an automated match so often produces confident reporting and no improvement in control: the numbers moved because the parameters moved, and the release stayed where it always was.

The regulatory row is the quiet one and it sets the design. Once the comparison is automated, what an examiner looks at is no longer whether a clerk did the check but whether the parameters and the access rights around it held steady. That is a genuine improvement in evidence, and it comes with an obligation nobody prices at the start: the tolerance table needs a change history, changes to it need to be attributable, and the people who can widen a tolerance should not be the people whose items are being held. A system that cannot show what its tolerances were on a given day has automated the work without automating the control.

What happens to the ones that fail

Very little happens, and that is the correct behaviour. The item does not go anywhere; it is held, it is given a reason, and somebody is told. The incumbent taxonomy is a reasonable map of what those reasons look like in practice - “Quality”, “PO price quantity”, “Quantity”, “Price”, “Manual”, “Amount”, “Date/time” and “Project budget” at item level, with manual and statistical blocks available at header level - and a design that cannot express which of those applies has thrown away the only information the exception carries.

Three things have to be decided before the first item is held, and they are the design rather than the configuration.

The first is the tolerance, which decides how many items are held at all. It is not one number: the checklist’s own shape is a percentage and a not-to-exceed absolute value, applied by document type, which is what stops a 3% tolerance being generous on a rail wagon and meaningless on a box of screws. A tolerance is a written statement of how much money the business is prepared to not argue about, and it should be signed off as one.

The second is the route. A held item needs a named owner, a time within which somebody has to look at it, and a way of separating the three categories that arrive mixed together: items where the supplier is wrong, items where the buyer’s own record is wrong, and items where nothing is wrong and the documents simply arrived in the wrong order. Only the first is a dispute with a supplier. The second is an internal correction. The third should not have been raised at all, and its share is the single most useful measure of whether the tolerances and the receipting are set up sensibly.

The third is the release, which is the control. Whoever can release a held item can defeat the match, so the separation the internal-control standards ask for applies here more than anywhere: authorising, recording, reviewing and custody in different hands, and where that is not practical because the team is four people, an explicit alternative control designed on purpose rather than the absence of one by default. The commonest workable alternative is not a person; it is a rule that no release may be silent, so that every override leaves a record with a name, a reason and an amount, and somebody reads the list.

That is where this control ends. An item that matches is cleared for whatever the business does next with it, and an item that does not is held with a reason attached and a person responsible for it. What happens after either of those points is a different decision, with a different owner, and it is not part of the match.

What this usually gets wrong

The first error is treating the match rate as the deliverable. A first-pass match rate is easy to quote, easy to improve by loosening a setting, and says nothing about whether the control works. The number that describes the control is what happened to the items that failed: how many, how they broke down between supplier error, internal error and pure sequencing, how long they sat, and how many were released without anyone recording why. A project that reports the first number and cannot produce the second has automated a comparison and not built a control.

The second error is setting the tolerances to make the pilot look good. It is the most tempting move available, because widening a tolerance instantly removes exceptions and looks like the system working. The auditing standard is explicit that an automated control’s continued effectiveness may depend on the related files, tables, data and parameters it uses, which means the tolerance table is part of the control and not a preference. Widening it to clear a backlog is a change to the control, and it deserves the same treatment as a change to the code.

The third error is automating the comparison and leaving the release wherever it happened to sit. This is the failure the fraud evidence points at most directly: overrides of existing internal controls account for nearly a fifth of all cases in the population, and a match with an unrestricted release path is an existing internal control with a documented override route. A business that previously needed a signature to release an unmatched item can, after a badly scoped build, do it with one click and no note.

The fourth error is matching at the wrong level. Comparing header totals is much easier and it is not the same control: two lines wrong in opposite directions cancel out and pass, an over-delivery on one item hides a short delivery on another, and a price error is invisible unless the quantities happen to be right. The federal specification asks for the match to run by document and line item for exactly this reason, and the invoice standards’ optional line-level order reference is the reason it so often cannot.

There is one prior question this page does not answer and it belongs before all of the above. Whether the purchase orders exist at all for the spend in question, whether receipts are posted at the time of delivery rather than in a weekly catch-up, and whether units of measure, part numbers and currencies are consistent across the three documents are readiness questions with their own answer. A match built over a purchase-order file that covers half the spend will report a high match rate on the half it can see and will be silent about the half that has no order at all, which is the half where the money goes missing.

The verdict

The evidence supports automating the comparison and deliberately designing the exception path, in that order and with most of the effort on the second. The comparison itself is a solved capability that finance systems have shipped for two decades against a published specification, and it is not where a project succeeds or fails. What decides the outcome is the three things around it: the tolerances, which choose how many exceptions exist; the route, which decides whether a held item reaches somebody who can resolve it; and the release, which is the only place the control can be defeated.

The reason is structural rather than a comment on how good the available products are. Three of the six dimensions point the same way. The exception row says the exception rate is a parameter, so it is chosen rather than measured and can be tuned until the reporting looks good. The reversibility row says everything the control does can be undone by one person, so the separation around the release is the control rather than a governance nicety. And the regulatory row says the automated version shifts the evidence onto change control, access and the parameter table, which is a better place for it to sit and a place nobody staffs by accident.

For a team weighing this, the useful first move is a month of counting rather than a demonstration. Take every invoice that did not go straight through in the last month and sort it into three piles: the supplier was wrong, the buyer’s own record was wrong, and nothing was wrong but the documents arrived out of order. Then count how many of those items were resolved by correcting something and how many by somebody deciding to let it go, and whether anyone wrote down which. Those numbers say more about whether an automated match will help than any pilot will, because they measure the part of the process the automation does not touch - which is also why a vendor selling this on its match-rate percentage is selling you the one number that was never the hard part. Foxnut Studios builds systems of this kind and hands them over, which is the reason to be blunt about the trade: automating this control makes it faster and more consistent, and it also makes it easier to switch off, so the handover has to include the tolerance table, its change history and the list of everyone who can release a hold.

If you have run the counting exercise above and want a second opinion on what it means, walk us through it.

Sources

Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is how an AI engagement is scoped and priced.