Three-Way Matching
Three-way matching answers one question before money is committed: does what we were invoiced agree with what we ordered and what we received? Drelo.ai automates the comparison of invoice, purchase order and goods receipt data, classifies the differences and routes anything outside your tolerances to the people who can decide.
Matching compares three records that are created at different moments by different parties. Each one states something the others cannot.
What your organisation agreed to buy: items, quantities, agreed prices and terms. Created by you, before delivery, and the reference point for what was expected.
What was actually received, recorded at delivery or on service confirmation. Created by your receiving or requesting side, and the evidence that the obligation exists.
What the supplier is charging: items, quantities, prices and totals. Created by the supplier, and the claim being tested.
Comparing all three catches the cases that any pair alone would miss — invoiced at the wrong price, invoiced for more than was delivered, or invoiced for something never received at all.
Differences inside your tolerances continue through the AP process, with the accepted difference still recorded.
Anything outside tolerance is classified by what differs and routed for review and resolution.
Tolerances are your commercial policy and are set per category, supplier group or entity. No tolerance values are assumed here.
For an accounts-payable team, matching is where most of the manual effort and most of the risk sit. Done by hand it means opening the invoice, finding the order, finding the receipt, comparing lines, and chasing whoever knows why the numbers differ.
Automating the comparison changes what the AP team spends time on. The invoices that agree stop consuming attention; the ones that disagree arrive already explained — which line, which value, how large the difference. AP becomes a decision-making function rather than a lookup function.
Header and line data are extracted and validated.
The purchase order the invoice refers to is identified.
Goods receipt or service confirmation data is retrieved.
Quantities, prices and values are compared line by line.
Differences inside tolerance continue; the rest become exceptions.
The prepared result is handed to the ERP per the agreed process.
Invoiced quantity against the ordered quantity and, where applicable, the quantity receipted.
Invoiced unit price and line value against the agreed purchase-order price.
Whether the invoice resolves to a purchase order and the correct lines on it.
Whether goods or services were confirmed as received before the invoice continues.
The invoice resolves to the right purchase order and receipt, and quantity and price agree within the agreed tolerance.
A document cannot be resolved, or a difference falls outside tolerance, so the invoice is held for a person to decide.
Both outcomes are recorded, so a matched invoice is as traceable as an exception.
Matching happens in layers. The first is finding the right documents: the invoice must be connected to the correct purchase order, and its lines to the correct order lines and receipts. This step is often the harder one, because suppliers reference orders inconsistently and describe items in their own terms.
Perfect agreement is not the everyday case. Rounding, currency conversion, small weight variances on bulk goods and minor freight differences all produce differences that are real but not worth investigating. Tolerances are the policy that says which differences are acceptable.
Two points matter more than the numbers. First, tolerances are your commercial decision, not a software default. Second, a difference accepted within tolerance is still recorded — accepted is not the same as invisible.
Anything outside tolerance becomes an exception, classified by what actually differs so that it reaches the right person rather than a generic queue.
A price variance is a buying conversation; a missing receipt is a receiving conversation; a duplicate is an AP control matter. Classifying the difference is what makes the exception actionable instead of merely visible.
Matching decides whether documents agree. It does not decide whether a disagreement is acceptable — that is a commercial judgement, and it stays with people.
Practically, this means a clean match inside tolerance can follow an automated route, while variances are presented to the person who owns them with the comparison already laid out. We deliberately do not claim that every matched invoice posts itself unattended: how far the automated path extends is configured with your finance team and the owners of the ERP, and organisations set that boundary differently depending on control requirements and approval policy.
Matching is only as good as the data it compares against. Purchase orders, receipts, vendor master data and the financial documents live in your ERP, and matching reads them rather than replacing them.
How that data is read, and how prepared results are handed back, depends on the integration pattern agreed for the landscape — see integrations, and SAP AP automation for SAP environments.
A matching decision has to be reconstructable later. For each invoice, the record should show which documents were compared, what differed, which tolerance applied, whether an exception was raised, who resolved it and on what basis, and what was handed to the ERP.
This is what makes automated matching defensible rather than simply fast: the automated path leaves a more consistent trail than a manual one, because every comparison is recorded the same way.
Two-way matching compares the invoice with the purchase order. Three-way matching adds the goods receipt, so it also confirms that what is being invoiced was actually received. Two-way is often used for services or for spend where no receipt exists; three-way is the norm for physical goods.
We do not claim fully autonomous posting as a given. Drelo.ai prepares and performs the comparison, classifies the result and hands prepared data to the ERP. Whether a clean match proceeds without a human step, and under what limits, is a configuration and governance decision made with your finance team and the owners of the ERP.
You do. Tolerances encode your commercial policy — what size of difference is not worth a person's time — so they belong to finance, not to software. They are usually set per category or supplier group rather than one global number.
Then three-way matching does not apply and the invoice follows a different route, typically coding and approval rather than matching. Non-PO spend is a normal part of the mix and should be handled deliberately rather than forced into a match.
They are common and should not be treated as errors. An invoice for part of an order is matched against what has been received so far, with the remaining quantity still open. The distinction that matters is between an open remainder and an over-delivery.
Yes. Purchase orders, receipts and the financial documents remain in your ERP. Matching reads that data and prepares a result; it does not become a parallel system of record.
Tell us how your orders, receipts and invoices line up today, and which variances consume the most time. We will walk through how the comparison and exception routing would be set up.