3-way PO matching automation compares the invoice, the purchase order, and the goods receipt without a person reading them. It resolves invoice lines to PO lines, tests quantity billed against quantity received, and validates price. Nobody creates a goods receipt for services, so those invoices need a different independent record of delivery.
Key takeaways
- A goods receipt is worth something because of two properties. Somebody other than the requester creates it, and they create it before or alongside the invoice.
- For services, replace the receipt with one of four artifacts, namely a service entry sheet, a completed statement-of-work milestone, an approved timesheet, or a contracted rate card.
- Match against the open PO balance rather than the original quantity. Suppliers usually send many invoices against one PO, and one invoice sometimes spans several POs.
- Two thresholds in series is the quiet leak. Receiving accepts an over-billed quantity inside one tolerance, and the invoice then matches cleanly inside the other.
Three-way matching is the control every accounts payable (AP) guide recommends, and a large share of your invoice volume cannot use it. The goods receipt is the reason. Nothing arrives on a loading dock when you buy legal advice.
The receipt-shaped hole in your control design
Three-way matching compares the invoice, the purchase order (PO), and the goods receipt. Remove any one of those and the model stops working. Nobody creates a receipt for services, subscriptions, professional fees, or milestone work, because nothing was received in the sense a warehouse means.
Non-PO-backed invoices make up a large share of enterprise volume, and in many finance functions they are close to half of it. That spend covers legal, consulting, agencies, software, and facilities. It has the weakest controls in the function, and the reason is structural. The heavy control does not fit, so nothing is designed to take its place.
Ardent Partners put the average invoice exception rate at 18.4 percent and average cycle time at 8.2 days, in its State of ePayables 2025 benchmarks published in January 2026. Non-PO-backed invoices make up much of that exception population. There is no order to match against, so somebody finds the approver by hand.
Finance teams then aim their automation programs at the easy half of the ledger. Gartner reported in November 2025 that accounts payable process automation was the second most common finance AI use case among adopters, at 37 percent. Most teams apply that effort to PO-backed goods, which is the spend that already had a working control behind it.
How to think about matching evidence
A goods receipt is not sacred. It is an independent record that delivery happened. Somebody other than the requester creates it, and they create it before or alongside the invoice rather than after.
Independence and timing are the two properties that make it worth anything. A receipt entered by the same person who raised the requisition, on the day the invoice arrived, provides nothing. It looks like a control and behaves like a rubber stamp.
That reframes the services question. You are not looking for a receipt. You are looking for an artifact with those two properties, for spend that a receiving team never sees. Once you ask it that way, several answers exist, and each has a real cost.
The second design question is what you compare. For goods it is quantity and price. For services it is a milestone, a rate, an hour count, or a period of coverage. The comparison logic differs for each, and so does the system that holds the evidence you need.
Tolerances then govern how close the two records must be. Our companion guide covers invoice matching and tolerances in depth, so this page stays on the automation mechanics.
What the 3-way PO matching engine compares
Automated matching runs at two levels, and the difference between them determines what you catch. A header match compares invoice total against PO total. A line match compares each invoice line against the PO line it belongs to, which requires the engine to work out which line that is.
Line identity is the first real problem in automation. Suppliers rarely echo your line numbers. They send their own part number, their own description, and lines in their own order. An engine resolves those against your item master using cross-references, description similarity, and unit price.
Multi-line PO matching adds the second problem. Suppliers usually send many invoices against one PO over months, and one invoice sometimes spans several POs. Matching against the original PO quantity is wrong in both cases. The engine matches the open balance instead.
Where 3-way PO matching automation breaks
Partial receipts and partial invoices generate most exceptions. Receiving posts 300 units against a PO for 500, then 150, then 50, while invoices arrive on a different schedule. Cumulative matching compares invoiced-to-date against received-to-date rather than pairing documents one to one. Systems that pair documents raise a false exception on every partial.
Unit-of-measure mismatch produces the most confusing exceptions. Your PO is in cases of 12 and the supplier invoices in individual units. Without a conversion factor on the item master, the engine reports an eleven-hundred percent quantity variance. AP investigates a pricing scandal that turns out to be packaging.
Over-receipt is the one that quietly costs money. Receiving accepts 105 units against a PO for 100 under a 5 percent over-receipt tolerance, and the invoice for 105 then matches the receipt cleanly. Two thresholds apply in series, and each was configured by a different team for a different purpose.
Matching without a goods receipt
Four models cover most services spend. Each replaces the receipt with a different artifact.
Service entry sheet. The requester records that the work was performed, and the entry is approved before the invoice can match against it. This is the closest equivalent to a receipt and the strongest of the four. The cost is behavioral, because requesters will not record acceptance on time without escalation reporting. It suits ongoing managed services.
Milestone or statement-of-work matching. The invoice matches a named deliverable in a statement of work (SOW) marked complete. It suits fixed-fee project work and capital projects, where the project owner creates the evidence. The cost is holding milestones in a system rather than a contract PDF, and updating them at every change order.
Contract and rate-card matching. The invoice line rate is compared against the contracted rate for that role, region, or period. It catches the most common services overcharge, a consultant billed at a rate nobody agreed to. Procurement creates the evidence at signing, and the cost is versioned rate cards. It suits agency and legal retainers.
Timesheet matching. Hours billed are compared against hours approved in a vendor management system. It suits contingent labor and time-and-materials work, where a manager approves through the labor system. The cost is integration, plus approving timesheets before invoices arrive.
Two spend types need no new artifact. Inventory and direct materials already have a goods receipt created by receiving. Subscriptions and utilities can match against the contract period and the prior invoice, which the contract owner already holds.
Non-PO-backed invoices also need a general ledger (GL) code before anything else happens. Our guide to GL coding for non-PO invoices covers that step.
What 3-way matching does not catch
A perfect match is a statement about paperwork consistency. It is not a statement about whether the purchase should have happened.
It cannot catch goods that were never needed. A valid PO, a real delivery, and an accurate invoice for equipment nobody had a use for produce a flawless three-way match.
It cannot catch collusion. A requisitioner who raises the PO, confirms the receipt, and approves the invoice makes every document agree. One person authored all three.
It cannot catch quality. Received is not the same as usable, which is the argument for an inspection step on regulated material.
Where current approaches fall short
Most matching automation was built for the goods flow and then pointed at everything else. Non-PO-backed invoices route to a person who guesses the approver from the vendor name and the amount. That is the lightest control on the largest share of discretionary spend.
Services spend also lacks a quantity, which breaks the mental model. A consulting invoice for $84,000 against a $500,000 SOW is not right or wrong on its face. Judging it requires the deliverable status and the rate card, and neither lives in the enterprise resource planning (ERP) system by default.
The second gap is where the evidence is stored. Milestone status lives in a project tool, timesheets live in a labor system, and rate cards live in a contract repository or somebody's drive. Automation that only reads the ERP cannot see any of it, so services matching stays manual and stays optional.
How we approach PO and non-PO invoices
We treat the non-PO half as a first-class problem rather than an exception. Our AI reads the invoice at line level and performs multi-line PO matching and routing. The engine treats partial receipts and cumulative balances as normal cases, not as failures.
For invoices with no PO behind them, our platform assigns GL codes, applies contract and policy context, and routes to the right approver. That volume is governed the same way as everything else. Agents can also run the checks your team performs by hand, including the acceptance chase that determines whether a milestone match is possible.
Qualcomm moved from 14 percent to 61 percent autonomous invoice processing with us on SAP S/4HANA. That kind of shift comes from automating the awkward population rather than the easy one. The platform stores the evidence behind every decision, so a services invoice matched against a milestone leaves the same audit record as a goods invoice matched against a receipt.
The bottom line
Split last quarter's invoices into PO-backed and non-PO-backed, then check which control applied to each. If the second pile is a large share of volume and has no matching model behind it, pick one evidence artifact per spend category and start there. Our team can map that against how your ERP already holds the data.
Frequently asked questions
What is three-way matching in AP automation?
Automated three-way matching compares the invoice, the purchase order, and the goods receipt without a person reading them. It resolves invoice lines to PO lines, checks quantity billed against quantity received, and validates price. Exceptions route to a human with the variance identified.
How do you match invoices for services with no goods receipt?
Replace the receipt with an independent record that the work happened. A service entry sheet, a completed SOW milestone, an approved timesheet, or a contracted rate card each serve as that record. The right choice follows the spend category.
Why do non-PO-backed invoices have weaker controls?
There is no order to match against, so the standard three-way model does not apply and nothing is usually designed to replace it. A person then identifies the approver by hand, which is the lightest control on a large share of discretionary spend.
What does three-way matching miss?
It misses whether the purchase was needed, whether the requisitioner and the supplier are working together, and whether delivered goods were usable. It also misses anything priced inside your variance thresholds. It says nothing about who was entitled to approve the spend, which is the job of your invoice approval workflow design.