Automating the Three-Way Match

The Three-PDF Problem

A typical three-way match involves cross-referencing data from three separate documents. A purchase order in one window. A goods receipt confirmation in another. A supplier invoice in a third. The AP clerk checks whether quantities match, whether prices match, whether terms match. For straightforward invoices, this takes two to three minutes each. For exceptions -- partial deliveries, price variances, substitute materials -- it can take twenty minutes or more per document.

Multiply that across hundreds or thousands of invoices per week, and you start to see why accounts payable departments are either heavily staffed or heavily automated. APQC benchmarking data shows a roughly 4x difference in invoices processed per FTE between top- and bottom-quartile AP organizations. The gap is almost entirely explained by how much of the three-way match is automated versus manual.

Every major ERP has some level of automation for this. It works well for straightforward cases, but the interesting problems start where the automation stops.

What the Match Actually Is

For the uninitiated: before paying a supplier invoice, your AP team verifies agreement across three documents.

• The Purchase Order (PO): what you ordered. Item, quantity, agreed price, delivery date, payment terms.
• The Goods Receipt (GR): what you actually received. Item, quantity, condition, date received, storage location.
• The Invoice: what the supplier is charging you. Item, quantity, unit price, tax, total amount, payment due date.

If all three agree -- quantities match, prices match within tolerance, terms are correct -- the invoice is cleared for payment. If they disagree, someone investigates. Simple in theory. Nightmarish in practice.

Because in the real world, the PO says 1,000 units at $12.50 each. The GR says 980 units received (20 damaged in transit). The invoice says 1,000 units at $12.75 each, referencing a price adjustment clause in Appendix C of the supply agreement that was amended six months ago. Is this a valid invoice? It depends on context that none of these three documents individually contain.

Why ERP Matching Fails (It Is Not a Bug)

SAP's MIRO transaction, Oracle's Payables Matching, Dynamics 365's invoice matching policies -- they all do the same thing. They compare numbers in fields. Quantity on PO line vs. quantity on GR line vs. quantity on invoice line. Price on PO line vs. price on invoice line. They apply tolerance rules: if the variance is within X% or Y dollars, auto-approve. If not, create an exception.

This is syntactic matching. It compares values without understanding what those values mean in context. And context is everything.

A 2% price variance on hot-rolled steel coil, which trades on a volatile commodity index, is completely normal. The same 2% variance on an office supplies contract with fixed pricing and no escalation clause is a red flag. SAP treats both identically. It applies the same tolerance threshold because it has no mechanism to distinguish between commodity-indexed pricing and fixed-price agreements at the matching level. The information exists in the system -- in different tables, in different modules, connected by document flows that span procurement, contracting, and vendor management. But the matching engine does not traverse those connections.

The False-Positive Flood

The result is predictable: a flood of false positives. Exceptions that are not really exceptions. Your AP team spends more time clearing false alarms than investigating genuine discrepancies. The truly anomalous invoices -- the ones that represent pricing errors, duplicate charges, or outright fraud -- get buried in the noise.

Organizations respond by widening tolerance thresholds -- "just auto-approve anything within 5%." But on a million-dollar PO, 5% means $50,000 in variance that nobody reviews. The false-positive problem gets solved, but at the cost of weakened controls.

Ontology-Driven Matching

One approach -- the one we are building into P3 -- is to match entities in context rather than comparing fields in isolation.

In an ontology-driven system, the purchase order, goods receipt, and invoice are not flat records. They are typed instances connected to suppliers, contracts, materials, pricing agreements, delivery terms, historical patterns, and business rules. Instead of asking "do these numbers match?", the system can ask a richer set of questions:

• Is this material subject to a blanket purchase agreement with fixed pricing? If so, any price variance is anomalous regardless of amount.
• Is this a commodity with index-linked pricing? If so, validate the invoice price against the current index value, not the PO price.
• Does this supplier have a history of over-invoicing? If their historical discrepancy rate is above 3%, apply tighter scrutiny.
• Was the PO amended after the goods receipt? If the amendment post-dates delivery, flag it -- someone may be retroactively adjusting the PO to match an incorrect invoice.
• Are there other open invoices from this supplier for similar amounts? Possible duplicate submission.

Each of these checks requires traversing relationships in the ontology. A rule engine operating on flat tables cannot perform them because the relevant information spans multiple entity types and multiple system boundaries. An ontology-grounded matching engine can, because it understands the relationships between entities, not just the values in their fields.

Catching What Rules Miss

The real power of ontology-driven matching is not faster processing of straightforward invoices. Any decent ERP handles those fine. The power is in the edge cases -- the scenarios that rule-based systems miss entirely because they were never anticipated when the rules were written.

Partial deliveries with multiple goods receipts against a single PO line. Consignment transfers where ownership changes but physical location does not. Service POs where there is no goods receipt because the "delivery" is hours worked. Credit memos that net against future invoices. Retroactive price adjustments triggered by volume rebate thresholds.

Each of these is a legitimate business scenario that the ontology can model with formal relationships and constraints. And each one breaks traditional field-level matching in ways that generate either false positives (blocking valid payments) or false negatives (approving invalid ones).

Split Invoices and Phantom Vendors

Then there is fraud. The classic AP fraud schemes are well-documented, and they all exploit the same gap: ERP matching engines process each invoice independently without cross-referencing patterns.

Invoice splitting: A fraudulent actor submits multiple invoices just below the approval threshold. Each individual invoice passes the three-way match. The aggregate pattern is anomalous, but the ERP never aggregates because it evaluates documents one at a time. An ontology-based system connects invoices to suppliers, to approval hierarchies, to temporal patterns. A cluster of just-below-threshold invoices from the same vendor in the same week surfaces as an anomaly.

Phantom vendors: Fictitious supplier master records created to siphon payments. The ERP validates that the vendor master exists -- check, it does, someone created it. An ontology-driven system can cross-reference vendor attributes: Does this vendor share a bank account with another vendor? Does their registered address match an employee's home address? Do they have zero purchase history prior to this invoice? These are graph-traversal queries that require entity relationships, not field comparisons.

Duplicate submissions: The same invoice submitted with slightly different formatting -- different invoice number, same amount, same date, same line items. ERPs match on invoice number. If the numbers differ, they see two distinct invoices. Semantic matching looks at similarity across the entity graph: same supplier, same materials, same quantities, same amounts, submitted within days of each other. That is not a coincidence. That is a duplicate.

The Result: Better Controls, Not Just Faster Processing

The most direct benefit is reducing false positives, which is where AP teams spend most of their exception-handling time. Fewer false alarms means more attention available for the genuinely anomalous invoices.

But the deeper value is in controls quality. Traditional matching is a compliance exercise: did the numbers match? Ontology-driven matching is closer to an intelligence exercise: does this invoice make sense given everything we know about this supplier, this contract, this material, and this transaction history? The first catches arithmetic errors. The second can catch fraud, contract violations, and process failures that tolerance thresholds were never designed to detect.

None of this replaces auditors. It gives them better starting points -- surfacing connections across the procure-to-pay landscape that no single transaction table or human reviewer could hold in their head at once. Whether that surfaces a $200 pricing error or a systematic fraud scheme depends on the data. The ontology just makes the connections queryable.