Invoice Matching Software: Two-Way, Three-Way, and Where the Match Fails

Invoice matching software compares an incoming invoice against the purchase order and, in a three-way match, the receiving record, then either clears the invoice for payment or routes the difference to a person. It's a comparison engine, not a reading engine, which is a distinction worth getting right before you evaluate anything.

Capture and matching are different problems that fail differently. Capture reads a document and fails on bad scans, unusual layouts, and handwriting. Matching compares structured records and fails on line-level differences, tolerance design, and purchase orders that changed after the invoice was cut. Vendors present them as one capability; your exception queue will present them as two.

Key Takeaways

• Matching compares records. Capture reads documents. Conflating them is the most common evaluation error in this category.

• A two-way match compares invoice to purchase order. A three-way match adds the receiving record, which is the control that catches paying for things that never arrived.

• Tolerance design decides your exception volume more than product choice does, and most teams set tolerances too tight.

• Freight, tax, and unit-of-measure differences break more matches than fraud or error ever will.

• Some exceptions should never be automated away, because the review is the control.

What does invoice matching software compare?

Three records, or two, depending on the match type. The purchase order says what was ordered and at what price, the receiving record says what arrived and in what quantity, and the invoice says what the supplier is charging. Matching compares those statements and flags disagreement.

The comparison happens at two levels, and the level is where products differ most.

• Header-level matching compares totals, which is fast and catches gross errors

• Line-level matching compares each item, quantity, and unit price, which catches the errors that actually cost money

A product that matches only at header level will pass an invoice whose lines are wrong and whose total happens to agree, and that case is more common than it sounds.

Which records are in a two-way match?

The invoice and the purchase order. The system checks that the supplier, the item, the quantity, and the price on the invoice agree with what was ordered, within whatever tolerance you configured.

Two-way matching suits purchases where receipt isn't a meaningful event. Services, subscriptions, utilities, and professional fees all have no receiving record to compare against, and forcing a three-way match onto them creates an exception on every single invoice. Deciding which spend categories are two-way and which are three-way is a policy decision that belongs to finance rather than to the software, and the definitional walkthrough of three-way matching covers the mechanics the software implements.

What does the receipt add in a three-way match?

Evidence that the goods arrived. That's the control that separates "we agreed to buy this" from "this showed up," and it's the only mechanism that catches an invoice for a delivery that never happened.

The control matters because billing schemes are a real and expensive fraud category. Billing schemes accounted for 22% of occupational fraud cases with a $100,000 median loss, according to the Association of Certified Fraud Examiners's 2024 Occupational Fraud: A Report to the Nations, which also found that lack of internal controls contributed to 32% of cases and override of existing controls to a further 19%, together more than half. A three-way match is precisely the internal control those two findings describe the absence of.

Scale matters too. Fifteen federal agencies reported about $186 billion in improper payments across 64 programs in fiscal 2025, a $24 billion rise year over year. Roughly 82% of that total, or $153 billion, was overpayment, according to the U.S. Government Accountability Office's 2026 report Payment Integrity. Overpayment rather than fraud is the dominant failure mode in payment integrity generally, and overpayment is exactly what matching is built to prevent.

How do tolerances work, and who should set them?

A tolerance is the amount of disagreement you'll accept without human review, expressed as a percentage, an absolute amount, or both. Set at zero, every rounding difference becomes an exception. Set too wide, the match stops being a control.

Finance should own the numbers and AP should own the operational feedback, which is a split most companies get backward. AP feels the exception volume and tends to want wider bands; finance carries the control risk and tends to want narrower ones. The right answer is a tolerance that generates an exception volume your team can genuinely review, because an exception queue nobody works is worse than a wider tolerance honestly set.

Pair a percentage with an absolute cap in most environments. A percentage tolerance applied to a very large line permits an absolute variance nobody intended to approve, and that gap only becomes visible when someone audits it.

What does a tolerance band cost you?

Two things, in opposite directions. A tight band costs review time on differences that don't matter. A wide band costs unreviewed variance, which shows up as margin leakage rather than as an incident.

Model both before you configure. Take last quarter's invoice population, apply two or three candidate tolerance settings, and count the exceptions each would have produced and the total unreviewed variance each would have allowed. That's a half-day analysis that people usually skip in favor of copying whatever the previous system had, which is how a tolerance designed for a different supplier mix persists for a decade.

When is a tight tolerance the wrong control?

When the variance is structural rather than erroneous. Freight charged at actual rather than quoted, tax calculated by the supplier's jurisdiction rules rather than yours, and unit-of-measure conversions between how you order and how they ship all produce differences that are correct and will never stop.

Handle those with rules rather than with tolerance. Exclude freight and tax lines from the match and reconcile them separately, or match them against a different expectation. Teams that push structural variance through a tight tolerance generate an exception queue made almost entirely of items that are fine, and the real exceptions get lost in it.

Why do matches fail in practice?

Six causes dominate, and only one of them is what people expect.

• Freight and tax lines that the purchase order never contained

• Unit-of-measure differences between ordering and shipping units

• Partial receipts matched against a full invoice

• Purchase order amendments made after the invoice was issued

• Supplier item codes that don't map to yours

• Genuine price or quantity error, which is the smallest category

Notice where the fraud case sits in that list, which is nowhere. Matching catches fraud as a byproduct of catching discrepancy, and the day-to-day work is mostly data reconciliation.

Protect cash flow with modern AP

Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.

Download the whitepaper

Which line-level differences break it?

Unit of measure and item code mapping, more than anything else. You order by the case and they ship and invoice by the each, or their part number differs from yours by a supplier-specific prefix, and every line looks like a mismatch to a system comparing strings.

Both are fixable in the supplier master rather than in the matching engine, and that's the point worth making. A matching product with sophisticated exception routing and no item-mapping capability will route the same mapping failures to a human forever. When you evaluate, ask specifically how supplier item codes and units of measure are mapped and maintained, because that answer predicts your steady-state exception volume better than any accuracy claim.

What happens when the PO changes after the fact?

The match fails against a purchase order that no longer describes the agreement, and somebody has to decide which version is authoritative. This is the failure mode AP teams describe most bitterly, because the change was usually legitimate and nobody told them.

Two controls address it. Version the purchase order so the match knows which revision was current when the goods shipped, and route amendments through the same approval path as the original so the change is visible before the invoice arrives. The design principles behind approval workflows that don't strand items apply to amendments exactly as they do to originals, and the requisition process is where the discipline has to start.

What still needs a human, and how should exceptions route?

Anything involving a commercial judgment, which is a smaller set than most teams' exception queues suggest. Data reconciliation should not reach a person. Decisions about whether to accept a price change, absorb a shortage, or dispute a charge should always reach one.

Route by exception type, not by dollar value, and assign an owner per type before go-live. Dollar-value routing sends a small price dispute to the same person as an identically sized data mismatch, which trains that person to approve everything.

Who owns a quantity exception?

Receiving or operations, because they're the only people who know what physically arrived. AP can see that the numbers disagree and can't resolve which one is right.

Give the owner a deadline and an escalation path. A quantity exception sitting unresolved past terms turns into either a late payment or an approved payment for goods nobody confirmed, and both outcomes are bad in different ways. Whatever the resolution, the reasoning belongs in the record, since the AP audit trail is what an auditor will read when they ask why this invoice was paid at a different amount than it was ordered.

Who owns a price exception?

Procurement or whoever owns the contract, because resolving it means knowing what price was agreed and whether the supplier had a right to change it. AP routing price exceptions to itself is how unapproved price increases become permanent.

There's a fraud dimension to price and bank-detail exceptions specifically that's worth keeping in view. According to the Association for Financial Professionals's 2026 Payments Fraud and Control Survey Report, 76% of US organizations experienced attempted or actual payments fraud in 2025 with just 17% using AI to fight it, and 74% of organizations were affected by business email compromise while 58% reported checks subject to fraud. In the same period the FBI Internet Crime Complaint Center's 2025 Internet Crime Report recorded 24,768 business email compromise complaints against 21,442 in 2024, alongside $3.05 billion in reported losses. An invoice arriving with a changed price and changed remittance details is the classic pattern, and matching catches the first half of it. The wider picture of how AI is changing payments fraud covers the other half, and duplicate payment detection covers the adjacent case where the same legitimate invoice gets paid twice.

How do you evaluate matching inside a wider AP platform?

On the ERP integration and on the exception experience, roughly equally. Matching accuracy claims are hard to falsify in a demo and easy to test with your own data, so spend the evaluation time on the two things that don't show up in a feature grid.

Integration weight is not a preference; it's where the market has landed. Integration difficulty is cited by 49% of organizations as a top concern, effectively tied with cost at 50%, according to PYMNTS Intelligence and WEX's July 2026 Business Payments Tracker edition "Who Decides Now," which also found 89% of organizations using at least some AP automation while half still push more than 5,000 invoices a month through workflows that aren't fully automated.

Which ERP questions decide it?

Four, and each needs a demonstration rather than a yes.

• Does the system read your open purchase orders and receipts directly, or from a periodic export?

• Does a cleared match post to the ERP automatically, with your coding and dimensions?

• Are purchase order amendments picked up, and how quickly?

• Where does the exception live, in the AP tool or in the ERP, and can both sides see the status?

That last question determines whether your controller can answer "why hasn't this been paid" without opening two systems. The broader boundary between invoice automation and full AP automation is worth settling at the same time, since matching sits right on it.

What should a pilot actually measure?

Touchless rate on your own invoice mix, exception volume by cause, and average time to resolve by exception type. Those three numbers tell you whether the product works for your data, which accuracy percentages do not.

Benchmark the first against published figures rather than vendor claims. The average touchless invoice processing rate is 60%, organizations above 30% touchless adoption show 3.5 times higher AP productivity, and AP cycle times improved by 59% after implementation, according to The Hackett Group's 2025 Accounts Payable Digital World Class Matrix. If a pilot on your real invoices lands well below that average, the gap is usually your master data rather than the product, and buying a different product won't close it.

Run the pilot on a full month including the ugly end. A pilot that processes two weeks of clean invoices proves the case nobody was worried about, and the honest version of this test uses the same period's worst suppliers deliberately. Our overview of invoice processing automation covers what the rest of the workflow around matching looks like.

Where Corpay fits when the match clears

The match clearing is a milestone, not an outcome. An approved invoice still has to be paid on a rail somebody chose, to a supplier whose banking details somebody validated, with the settlement reconciled back into the ledger. When the match and the payment live in different systems, that handoff is where the time goes.

Corpay AP automation puts them in one place. Payment executes across virtual card, ACH, or check once the invoice clears, and settlement returns as a reconcilable transaction. Checks are still in the mix and still falling, down to 9.2 billion payments and $24.45 trillion by value in 2024, a drop of 1.8 billion payments from 2021, according to the Federal Reserve's 2025 Federal Reserve Payments Study, and moving the residue onto electronic rails is part of what the platform does rather than a project you run separately.

What does fully managed AP change about this?

It changes who works the queue. Corpay's AP service is fully managed, so our team enrolls suppliers with validated banking details, delivers payments, and handles the exception follow-up and supplier chasing that would otherwise land on the AP manager who is already reviewing matches. Customers report about 40% less time spent on AP after the move, single-use virtual cards close the reuse exposure on one-off payments, and Corpay returns more than $800 million in rebates to customers each year on card-eligible spend. Most programs are live in weeks.

Which ERPs does it connect to?

Corpay maintains 100+ ERP integrations, including NetSuite, Sage Intacct, Microsoft Dynamics 365 Business Central, and Acumatica, which is the connection that decides whether a cleared match posts itself or waits for an analyst. For a view of how matching sits inside the rest of the workflow, the accounts payable process walkthrough is the place to start, and if you're comparing platforms generally, the Tipalti alternatives breakdown covers the vendor field.

Frequently Asked Questions

What is invoice matching software?

Invoice matching software compares an incoming invoice against the purchase order and, in a three-way match, the receiving record, then clears the invoice for payment or routes the difference to a person. It compares structured records rather than reading documents, which is a separate capability called capture.

What is the difference between two-way and three-way matching?

A two-way match compares the invoice to the purchase order, checking supplier, item, quantity, and price. A three-way match adds the receiving record, confirming that goods actually arrived. Two-way suits services and subscriptions with no receipt event; three-way suits goods.

What is a tolerance in invoice matching?

A tolerance is the amount of disagreement accepted without human review, expressed as a percentage, an absolute amount, or both. Set at zero, every rounding difference becomes an exception. Set too wide, the match stops functioning as a control.

Why do invoice matches fail?

Six causes dominate. Freight and tax lines absent from the purchase order, unit-of-measure differences, partial receipts against a full invoice, purchase order amendments made after invoicing, supplier item codes that don't map to yours, and genuine price or quantity errors, which are the smallest category.

Can invoice matching be fully automated?

The reconciliation can be. The judgment can't, and shouldn't be. Deciding whether to accept a price change, absorb a shortage, or dispute a charge is a commercial decision where the human review is the control, not an inefficiency to remove.

Is invoice matching the same as OCR or invoice capture?

No. Capture reads the document and extracts data, failing on poor scans and unusual layouts. Matching compares the extracted data against your records, failing on line-level differences and stale purchase orders. A product can be excellent at one and weak at the other.

Who should set invoice matching tolerances?

Finance should own the numbers, with AP providing operational feedback on exception volume. Model candidate settings against a real quarter of invoices before configuring, counting both the exceptions each would generate and the unreviewed variance each would allow.

David Luther

Product Marketing Program Manager

David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.

AP Automation

Procure-to-Pay