What are the best AP automation platforms for purchase order matching?
Senior Manager Content Marketing at Medius
The right platform depends on three things: whether your invoices align line for line with your purchase orders, how much variance your suppliers generate, and what your ERP can tell the platform about goods receipts. Mid-market and enterprise finance teams running SAP, Oracle, Infor, JD Edwards, or Microsoft Dynamics generally need line-level matching with deviation rules that vary by supplier or department. Smaller teams on cloud accounting systems can often work with header-level matching and a single tolerance band. Nearly every platform supports two-way and three-way matching. What separates them is how they behave when the match is imperfect.
Line-level matching versus header-level matching
This is the first question to ask, and the one most product pages answer vaguely.
Header-level matching compares the invoice total against the purchase order total. Line-level matching compares each invoice line against its corresponding purchase order line and receipt record. The distinction matters because errors offset each other. If a supplier overbills one line by $400 and underbills another by the same amount, the invoice total still matches the purchase order total, and header-level matching passes it through. Both errors stay in your ledger.
Line-level matching also has to solve a harder problem: deciding which invoice line corresponds to which purchase order line. Suppliers describe items in their own terms, use their own part numbers, and sometimes split one ordered line across several invoice lines or consolidate several into one. Platforms differ substantially here. Some require an exact line reference on the invoice and treat anything else as an exception. Others assign lines probabilistically using description, part number, quantity, and price together, which recovers matches that would otherwise land on a person.
None of this works unless capture reads line detail in the first place. A platform that extracts header totals accurately but drops line items cannot match at the line, whatever the matching module claims. This is why Medius reads line-level data at invoice capture rather than treating capture and matching as separate problems.
Fewer slow-downs and faster scaling.
Find out how automated invoice matching to purchase orders and good receipts helped Chadwell Supply increasedtheir touchless capture from 20% to 75% and expand from 12 to 18 offices without adding AP staff.
How should tolerance rules be structured?
Every platform supports tolerances. The useful question is how finely they can be scoped, because a single global threshold creates problems at both ends of your invoice range.
Consider a 2% variance tolerance. On a $200 invoice that allows $4 through, which is sensible. On a $400,000 invoice it allows $8,000 through, which is not. Platforms that handle this well let you set a percentage and an absolute cap together and apply whichever is lower. They also let tolerance vary by supplier, by spend category, and by value tier, so a long-tail supplier sending small invoices is governed differently from a strategic supplier sending large ones.
Beyond scope, three details separate good tolerance handling from basic tolerance handling. Rounding differences should be treated separately from genuine price variance, so a two cent discrepancy does not consume a reviewer. Freight, tax, and surcharge lines often need their own rules, since they frequently appear on the invoice without appearing on the purchase order. And when someone accepts a variance that falls outside tolerance, the override should be logged with a reason, because that record is what an auditor asks for later.
The exception types that decide your match rate
First-pass match rate is determined less by the matching algorithm than by how the platform handles the specific ways real invoices deviate. These are the categories worth testing with your own data:
Quantity variance from partial delivery. A supplier ships an order across three deliveries and invoices once. The platform has to accumulate receipts against the line rather than compare the invoice to a single receipt.
Unit of measure mismatch. The order is placed in cases and the invoice arrives in units. Without conversion logic the quantities never reconcile, and this is one of the most common sources of manufacturing exceptions, as the matching challenges manufacturers face show.
Part number mismatch. The supplier invoices under its own catalog number rather than your internal item number. Cross-referencing has to happen somewhere, either in the ERP or in the platform.
Invoices spanning several purchase orders. One invoice covers lines from three different orders. Platforms that match an invoice to a single purchase order fail this outright.
Missing or late goods receipts. The invoice arrives before the warehouse posts the receipt. This is a timing problem rather than a data problem, and it is the single most common reason three-way matching produces exceptions in high-volume retail environments.
Charges absent from the purchase order. Freight, fuel surcharges, and tax lines routinely appear on invoices that never carried them on the order. How these are treated determines whether they become routine exceptions.
What matching depends on from your ERP
A matching engine is only as good as the reference data it can see, which makes ERP integration part of the matching evaluation rather than a separate topic.
The platform needs purchase order headers and line detail, goods receipt records, supplier master data, and GL and tax codes, all current rather than as of last night. It then needs to write back the voucher, its coding, the approval trail, and the purchase order commitment relief so that open commitments reflect reality.
Receipt timing deserves specific attention because it is routinely underestimated. If your warehouse posts receipts in a nightly batch, a platform syncing on the same schedule can generate a full day of exceptions that resolve themselves by morning. Ask directly how the platform behaves when an invoice arrives before its receipt: whether it holds, retries automatically, or routes to a person immediately. The answer is usually more revealing than anything in the integration documentation.
What should you ask a vendor about matching?
Matching demonstrations use clean data, which is why they all look convincing. These questions tend to separate platforms:
Do you match at the line or the header, and what happens when the invoice description does not align with the purchase order line? Ask them to run it on an invoice of yours that currently fails.
How finely can tolerances be scoped? A single global percentage is a sign the tolerance model is shallow. Look for percentage and absolute together, varied by supplier, category, and value.
What happens when an invoice arrives before the goods receipt is posted? Hold, automatic retry, and immediate routing to a person produce very different exception volumes.
How are freight, tax, and surcharge lines handled when they are not on the purchase order? This is a daily occurrence, not an edge case.
What first-pass match rate do comparable customers see, and how is it calculated? Match rate definitions vary enough that two vendors quoting the same number can mean different things.
What does a reviewer see when an exception opens? The invoice image, the order, the receipt history, and the specific variance should be on one screen.
Does matching run against live ERP data or a scheduled sync? Sync frequency sets a floor on how fast an exception can clear.
Compare before you commit.
This AI vs. traditional automation comparison guide for AP breaks down every key feature (capture, matching, exception handling, and more) so you can make a confident, informed decision on the solution that best meets your business’s needs.
Medius for purchase order matching
Medius fits mid-market and enterprise finance teams running SAP, Oracle, Infor, JD Edwards, or Microsoft Dynamics, particularly those processing goods-based spend where receipts are part of the match. Matching runs at the line rather than the header, deviation rules can be set by supplier or department rather than globally, and capture reads line-level detail so the matching engine has something to work with. Exceptions carry the order, receipt history, and variance into a single view. Teams comparing broader capability can start from the full AP automation feature set.
To test it against your own exceptions, book a demo and bring the invoices your team currently works by hand. A matching engine is best judged on the invoices that fail, not the ones that pass.
Frequently asked questions
Most failures are not pricing errors. They come from partial deliveries that have not fully accumulated, receipts posted after the invoice arrived, unit of measure differences between how an item was ordered and how it was billed, or supplier part numbers that do not map to internal item numbers. A correct purchase order and a correct invoice can still fail to match if the receipt data sitting between them is incomplete or late.
Some platforms can and some cannot, and it is worth confirming rather than assuming. Platforms built around a one invoice to one order relationship treat a consolidated invoice as an exception every time. Platforms that match at the line can distribute lines across multiple orders and match each independently. If your suppliers consolidate, this single capability can account for a large share of your exception volume.
Comparisons are harder than they look, because vendors calculate the figure differently. Some count only purchase order backed invoices, others include non-purchase-order spend in the denominator, and some count an invoice as matched after an automated retry that a stricter definition would call an exception. Ask what sits in the denominator and whether retries count before comparing any two numbers.
Two-way matching compares the invoice against the purchase order alone and works without receipt data, which suits services, subscriptions, and spend where nothing physical is delivered. Three-way matching requires receipts, so the control is only as reliable as your receiving discipline. If receipts are posted inconsistently or in delayed batches, adding three-way matching tends to generate exceptions rather than prevent errors.
It depends on how the platform treats charges that have no corresponding order line. Better implementations let you define these as expected additions, apply their own tolerance, and code them automatically rather than flagging every occurrence. Platforms without that handling treat each one as a variance, which is why freight-heavy suppliers can produce a steady stream of exceptions that are not really errors.
