Purchase order matching is the accounts payable control that compares a supplier invoice against the purchasing documents that authorize it before the invoice is approved for payment. Two-way matching compares the invoice to the purchase order. Three-way matching adds the goods receipt, so the invoice is checked against both what was ordered and what actually arrived.
The control exists because an invoice on its own is a claim. The purchase order records what the company agreed to buy and at what price, and the goods receipt records what was delivered. Matching the three confirms that the company is paying the agreed price for goods it actually received, which is the check that catches duplicate invoices, price creep, quantity overbilling, and invoices for deliveries that never arrived.
This article covers what each match type compares, where matching breaks down at the line level, and how to automate it. The final sections describe how Centime matches invoice lines to purchase orders and what to test when evaluating a system.
Both match types work at the line level rather than the invoice total. An invoice can tie out in total while individual lines are wrong, so a header-level comparison passes invoices that a line-level comparison catches.
Two-way matching compares the invoice against the purchase order on two dimensions:
Three-way matching adds the goods receipt and compares:
The difference matters when a supplier ships partially. On a PO for 100 units where 60 arrived and the supplier invoiced for 100, two-way matching passes the invoice because the quantity ties to the order. Three-way matching holds it, because only 60 units were received.
Not every purchase warrants three-way matching. Inventory and other receivable goods are the natural candidates, since a physical delivery is recorded. Services, subscriptions, utilities, and expense-type lines often have no goods receipt to match against, and forcing a three-way rule onto them creates exceptions with no informational value.
The mechanics are simple. The work is in the cases where the documents do not correspond cleanly.
These cases are the reason PO matching stays manual in many AP departments. The straightforward matches are easy to automate, and the exceptions consume the time.
Automating PO matching means linking invoice lines to purchase order lines without a person doing the comparison, then presenting only the lines that need a decision. Five capabilities do that work.
Match at the line level, on the right fields for the line type. Item lines are compared on unit price and quantity, since those are the dimensions that carry the risk. Expense-type lines have no meaningful unit price and are compared on amount instead. A system that applies one rule to both produces exceptions on every expense line.
Link lines automatically, using more than one signal. Exact matches on rate and quantity are the first pass. Beyond that, the system needs to recognize the same item described differently, which requires comparing normalized descriptions and, past that, a similarity model that learns which supplier descriptions correspond to which items and accounts.
Set tolerances, and record a tolerance pass as its own outcome. A variance inside the tolerance a company sets is a different event from a true mismatch, and the two should not be recorded identically. Keeping them separate is what lets a controller see which invoices passed exactly and which passed within tolerance.
Give each dimension its own status and its own resolution. A line can have a correct quantity and a wrong rate. Tracking rate, quantity, and amount separately lets the rate discrepancy be resolved without disturbing the rest of the line.
Handle the not-yet-matchable case explicitly. An invoice waiting on a goods receipt needs a state of its own, so it is neither approved nor treated as an exception requiring investigation.
Centime runs PO matching inside its AP automation application, in the same flow that captures and codes the invoice. The behavior below reflects how the matching engine operates rather than a summary of features.
Match type is set globally and overridden per supplier. A company sets two-way, three-way, or no matching as its default, then overrides that for individual suppliers. Three-way matching is applied where a goods receipt genuinely exists, and expense-only suppliers run two-way, without one policy forcing exceptions on the other.
Three-way eligibility is resolved per item. Rather than applying three-way matching to every line on a supplier's invoice, Centime determines eligibility at the item level, so inventory and receivable items match against receipts while other lines on the same invoice do not.
Lines link through a four-pass sequence. The engine first scores every invoice line against every open PO line and links the exact matches immediately, on rate and quantity for item lines and on amount for expense lines. Lines that remain are matched on exact normalized descriptions. What is still unresolved goes to a similarity model that predicts the item or account a line corresponds to. The remaining candidates are then ranked and the best of them linked. Each pass narrows the set the next pass has to consider.
Received quantity, not ordered quantity, drives three-way matching. Centime reads goods receipt data against the PO line and matches on the unbilled received quantity, so partial deliveries match correctly and a quantity already consumed by an earlier invoice is not billed twice.
Tolerance results are distinguished from mismatches. Rate, quantity, and amount each carry their own status, and a variance that falls inside the configured threshold is recorded as a threshold match rather than a mismatch. A line where every dimension passes within tolerance is recorded as a full threshold match, which is a different outcome from a line that matched exactly.
Each discrepancy is resolved on the line. An AP approver can accept, reject, or dispute a rate or quantity discrepancy independently, mark a line as awaiting receipt when the invoice arrived first, unlink a line that was matched incorrectly, or recall a decision already made. New lines on the invoice that were never on the PO are actioned the same way.
PO revisions are reflected. When a purchase order changes, invoice lines linked to removed PO lines are unlinked rather than left pointing at a document that no longer exists.
Matching runs inside NetSuite, QuickBooks, Sage Intacct, and Microsoft Dynamics. It reads the purchase orders and goods receipts already recorded in the ERP rather than a synchronized copy of them, and the approved bill posts back to the same system.
Evaluations tend to center on whether a system supports three-way matching. Nearly all of them claim to. These criteria separate them.
The gains from PO matching automation appear as AP hours rather than as a line item. The published customer results below cover AP automation broadly, of which matching is one part, so they should be read as the outcome of the whole workflow rather than of matching alone.
Erdman Holdings, a commercial real estate company processing hundreds of invoices a month, recovered more than 20 hours a week on accounts payable compared with its previous manual process. Nickie Hanson, the company's Controller, attributes that to replacing manual handling across the AP workflow. Synergy HomeCare, running more than 100 invoices a month across 400 territories, recovered more than 40 hours a month after automating payables.
The mechanism behind both is the same. When the straightforward matches link automatically and only genuine discrepancies reach a person, the AP team spends its time on the exceptions that carry real financial risk.
Centime matches invoice lines to purchase order lines and goods receipts inside Oracle NetSuite, Intuit QuickBooks, Sage Intacct, and Microsoft Dynamics 365 Business Central, with per-supplier match rules and tolerances your team sets. See PO matching software running in your ERP, or book a 30-minute demo to see it run against your own purchase orders.