Matching an invoice to its purchase order and goods receipt is the control that stops your business paying for things it never ordered or never received. This page explains how automated invoice matching works, what tolerances real AP teams set, and why most match failures are a data problem rather than a matching problem. Upload an invoice to see the line-item data a match actually needs.
Upload your invoices
Drop files here or click to upload
Up to 50 files
Uploading...
On paper, invoice matching is arithmetic. The invoice says 500 units at $12.40, the purchase order says 500 units at $12.40, the receipt says 500 units arrived, so the bill gets paid. In practice the three documents never line up that neatly, and an AP clerk spends the afternoon working out whether a $63 difference is a freight charge, a partial delivery, or a supplier who quietly raised prices.
A matching engine compares line to line. If the invoice arrives as a PDF and only the header total gets keyed into the ERP, there is nothing to match against the purchase order lines, so the match either fails or gets waved through on the total alone.
The PO is written in cases, the supplier bills in each, and the receipt is booked in pallets. The numbers are all correct and the match still fails, because nobody stored the conversion factor anywhere the system can read it.
Purchase orders rarely carry a line for freight or fuel surcharge. The invoice does. Every one of those invoices becomes an exception unless the matching rules allow charges that have no PO line.
A PO for 1,000 units delivered in three shipments produces three receipts and, often, three invoices that each cover a different subset. Cumulative matching handles this. Document-to-document matching does not.
A zero-tolerance rule sends every rounding difference to a human. A generous one lets a supplier drift 5% above the agreed price for a year before anyone notices. Neither setting is a control.
Three-way matching assumes a goods receipt exists. On consulting, maintenance, and subscription spend there is nothing to receive, so the third document never appears and the invoice sits waiting for a match that cannot happen.
Automated invoice matching reads the invoice, finds the purchase order it belongs to, compares the lines, applies your tolerance rules, and either releases the invoice for payment or routes a specific exception to a named person. The matching itself runs inside your ERP or AP platform. What most teams are missing is the step before it: structured, line-level invoice data. That is the part the extractor at the top of this page handles.
The engine pulls the purchase order reference off the invoice, including the variants suppliers print (PO#, Order No, Customer Ref) and the ones they hide in the line-item description.
Quantity, unit price, extended amount, and part number are compared line by line rather than on the invoice total, which is the only way a price increase on one item ever gets caught.
Absolute dollar, percentage, and quantity tolerances at both line and header level, usually with a lower tolerance on high-value categories and a wider one on freight.
Quantities are matched against everything received against the PO to date, not against a single receipt, so partial deliveries and consolidated invoices stop generating false exceptions.
A failed match becomes a task with a reason attached (price variance, quantity variance, no receipt, no PO) and goes to the buyer or the receiving supervisor rather than back into the AP inbox.
Every rule above depends on clean fields. Upload the PDF, scan, or emailed invoice and get vendor, invoice number, PO number, dates, totals, taxes, and every line item as Excel, CSV, or JSON.
The sequence is the same whether the match happens in NetSuite, Sage Intacct, a mid-market AP platform, or a spreadsheet a controller built.
Extract the header fields and every line item from the document. Without the PO number and the individual lines, there is nothing for the engine to compare and the match degrades into a total-only check.
Tip: Capture the supplier part number as well as the description. Descriptions never match; part numbers do.
Look up the PO by reference, then pull every receipt booked against it. Cumulative quantities matter more than any single receipt document.
Check quantity billed against quantity received, unit price against PO price, and the extended total. Anything inside tolerance passes silently. Anything outside it becomes a coded exception.
A price variance belongs to procurement, a quantity variance to receiving, and a missing PO to the requester. Sending all three to AP is why matching feels like it creates work.
Matching sits between procurement, the warehouse, and finance, which is exactly why it is nobody's favorite process.
The match is what lets AP pay confidently. It is also where AP inherits every mistake made upstream in purchasing and receiving.
High volumes of physical goods, real price and quantity variances, and inventory valuation that depends on the match being right.
Deliveries land on job sites, receipts are signed on paper, and the invoice references a PO the site never saw. Matching here is mostly a document problem.
Three-way matching is one of the few AP controls an auditor can test directly, so the exception log matters as much as the pass rate.
Invoice matching is the accounts payable control that compares a supplier invoice against the internal documents that authorized and confirmed the purchase, normally the purchase order and the goods receipt, before the invoice is approved for payment. If the quantities, prices, and totals agree within an accepted tolerance, the invoice is released. If they do not, it becomes an exception that a person investigates. Last updated July 2026.
Invoice matching software automates that comparison. It reads the invoice, locates the purchase order, applies the tolerance rules the business has set, and releases or blocks the invoice without a clerk opening three documents side by side. The engine is only as good as the data it is given, which is why line-item extraction sits directly upstream of every matching workflow.
The number counts the documents being compared. Two-way matching checks the invoice against the purchase order. Three-way matching adds the goods received note, so the business confirms the items physically arrived before paying. Four-way matching adds an inspection or quality record, used where goods can be delivered and still be unusable.
| Match type | Documents compared | What it catches | Typical use |
|---|---|---|---|
| 2-way match | Invoice + purchase order | Billed price or quantity differs from what was ordered | Services, software, subscriptions, low-risk spend with no receipt |
| 3-way match | Invoice + PO + goods receipt | Paying for goods that were ordered but never delivered | Inventory, raw materials, distribution, manufacturing, construction |
| 4-way match | Invoice + PO + receipt + inspection record | Paying for goods that arrived but failed quality control | Regulated manufacturing, pharmaceuticals, aerospace, food |
Most US finance teams run a blended policy: three-way matching on anything with a receipt, two-way on services, and a straight approval workflow on non-PO spend. Our guide to three-way matching walks through a worked example, and the 2-way vs 3-way vs 4-way matching comparison covers when each is worth the friction.
Three-way matching in accounts payable compares the supplier invoice, the purchase order, and the goods received note before payment is approved. The PO proves the purchase was authorized at an agreed price. The receipt proves the goods arrived. The invoice is the request for money. When all three agree on quantity and price, the invoice is paid. It is the strongest routine control most AP departments have against overbilling and against paying for undelivered goods.
Header agreement is not a match. A real engine works at line level, and the fields below are the ones that decide whether an invoice passes.
| Field | Compared against | Common tolerance in US mid-market AP |
|---|---|---|
| Vendor and remit-to | PO vendor record | Exact match required |
| PO number | Open purchase orders | Exact match required |
| Unit price | PO line price | Small percentage band, tighter on high-value lines |
| Quantity billed | Cumulative quantity received | Never above received quantity |
| Extended line amount | Price times quantity | Rounding only |
| Invoice total | Sum of lines plus tax and freight | A few dollars absolute |
| Freight and surcharges | Often no PO line exists | Absolute dollar cap, routed to the buyer above it |
| Sales and use tax | Tax rules, not the PO | Excluded from the match, validated separately |
Note that tolerances are a policy choice, not a standard. Publish yours, review them against the actual variance you see, and treat any tolerance that never produces an exception as a tolerance set too wide.
A matching tolerance is the amount by which an invoice may differ from the purchase order or receipt and still pass automatically. It exists because insisting on the cent means a human reviews rounding differences all day. Tolerances are usually expressed two ways at once, as a percentage and as an absolute dollar cap, with the tighter of the two governing. A 2% or $25 tolerance passes a $10 variance on a $1,000 line and stops a $200 variance on a $2,000 line.
In most AP departments the top causes are the same, and only one of them is a genuine billing error.
Working the queue that results is its own discipline, covered in our guide to invoice exception handling.
The comparison can. The judgment cannot. Software can match, apply tolerances, and release clean invoices with no human involvement, and a well-run PO process pushes a large share of invoices straight through. What software cannot do is decide whether a price increase was agreed on a call, or whether the missing receipt means the goods never came or that receiving is behind. Every touchless invoice programme still needs a person for the exceptions, which is the point made in our article on touchless invoice processing.
Not natively. QuickBooks Online lets you copy a purchase order onto a bill and mark a PO as closed, but it does not run an automated two-way or three-way match against tolerances, and it has no goods receipt document separate from the bill. Teams that need a real match on QuickBooks add a third-party AP or procurement app, or move the receipt step into an inventory system. QuickBooks Desktop Enterprise does support item receipts, which gives you the third document. If you are only trying to get the invoice data into QuickBooks cleanly, our convert invoices to QuickBooks page covers that path.
| Where the match runs | What you get | What it still needs from you |
|---|---|---|
| ERP native (NetSuite, Sage Intacct, Dynamics, SAP) | Matching against the PO and receipt records that already live there | Invoice data keyed or imported as structured lines |
| AP automation platform | Capture, matching, approval routing, and payment in one workflow | Clean PO and receipt data synced from the ERP |
| Procurement platform | Matching tied to the requisition and approval chain | Suppliers who actually transact through it |
| Spreadsheet | Workable under a few hundred invoices a month | Invoice, PO, and receipt exports that share a key |
We are the layer in front of all four. InvoiceExtractor turns the invoice document into structured line-item data, including the PO reference, so the matching engine you already own has something to compare. We do not route approvals, hold your PO records, or move money, and any page that tells you a data extraction tool is a full AP platform is selling you something. If you want the platforms compared honestly, including where each of them beats us, read best AP automation software.
You cannot, and roughly a third of invoices in a typical mid-market company have no PO behind them. Non-PO spend is controlled differently: the invoice is coded to a general ledger account and cost center, then routed to the budget owner who confirms the expense was authorized. That is approval, not matching. The practical fix is to move recurring non-PO categories onto blanket purchase orders so they can be matched, and to tighten GL coding on the rest.
At minimum: the vendor identity, the invoice number and date, the PO reference, the currency, every line with its part number, description, quantity, unit of measure, unit price and extended amount, plus tax and freight as separate values. Header totals alone will only ever support a total-level check. Getting those fields off a PDF without retyping them is what invoice line item extraction does, and it is the step that makes automated matching possible at all.
Invoice matching is the accounts payable control that compares a supplier invoice against the purchase order and, usually, the goods receipt before the invoice is paid. If quantities, prices, and totals agree within tolerance, the invoice is released for payment. If they do not, the invoice becomes an exception for a person to investigate.
Two-way matching compares the invoice to the purchase order only, checking that the price and quantity billed match what was ordered. Three-way matching adds the goods received note, confirming the items physically arrived. Two-way suits services and subscriptions where nothing is delivered; three-way suits physical goods, where paying for an undelivered shipment is a real risk.
A tolerance is how far an invoice may differ from the purchase order or receipt and still pass automatically. It is normally set as a percentage and an absolute dollar cap together, with the tighter one governing. Tolerances stop rounding differences from creating exceptions. Set them too wide and a supplier can overbill for months without triggering a review.
The most common reasons are a missing or unreadable PO number, goods that arrived but were never receipted, partial deliveries billed against a full PO, unit of measure mismatches, and freight or surcharges that have no PO line. Genuine supplier price errors are a minority of exceptions, which is why fixing upstream data beats hiring more people to clear the queue.
The comparison can be fully automated, and clean PO invoices can be released without anyone looking at them. The judgment calls cannot. Someone still has to decide whether a price variance was agreed, or whether a missing receipt means the delivery never happened. Automation should shrink the exception queue, not pretend it is empty.
No. QuickBooks Online lets you copy a purchase order onto a bill, but it does not perform an automated tolerance-based match and it has no goods receipt document separate from the bill. A real three-way match on QuickBooks Online requires a third-party AP or procurement app. QuickBooks Desktop Enterprise supports item receipts, which provides the third document.
You do not match it, you approve it. Non-PO invoices are coded to a GL account and cost center, then routed to the budget owner who confirms the spend was authorized. To bring recurring non-PO categories under a match, put them on a blanket purchase order and release against it.
No. We extract the invoice header fields and every line item, including the PO reference, and hand that data to whatever runs your match: your ERP, your AP automation platform, or a spreadsheet. Matching needs your purchase order and receipt records, which live in those systems. We remove the retyping that makes line-level matching impractical.
Four-way matching adds an inspection or quality record to the invoice, purchase order, and goods receipt. It is used where goods can arrive on time, in the right quantity, and still be unusable, such as in regulated manufacturing, pharmaceuticals, aerospace, and food production. Outside those settings the extra step rarely pays for itself.
The vendor, invoice number and date, PO reference, currency, and every line item with part number, quantity, unit of measure, unit price, and extended amount, plus tax and freight separately. Header totals alone only support a total-level check, which misses the single overpriced line inside an otherwise correct invoice.
Get the rows a match needs, not just the total.
Pull PO lines into structured data too.
Where matching sits in the automated AP cycle.
Platforms that run the match, compared honestly.
