Invoice matching software

Invoice matching software compares every line of a supplier invoice against the purchase order line and the goods receipt line, on pre-tax unit prices, and flags only the lines that fall outside tolerance. Everything below is the actual logic — the formulas, the tolerance rules and the exception types — so you can judge a vendor before you talk to one.

---

What invoice matching software actually does

Three documents describe the same purchase, and they are created by different people at different times:

• The purchase order — what you agreed to buy, at what unit price. Created by whoever raised the order.
• The goods receipt — what physically arrived, in what quantity. Created by whoever was on the loading dock.
• The invoice — what the supplier is asking to be paid for. Created by the supplier.

Matching is the act of proving those three agree, line by line, before money moves. When they do not agree, the software has to tell you which line, by how much and in whose favour — not just that "the invoice has an error".

The math, in full

For every invoice line matched to a PO line, two independent variances are computed on pre-tax unit prices:

They are kept separate on purpose. A line can be correctly priced and over-delivered, or correctly delivered and over-priced, and those two problems go to different people to resolve. Collapsing them into a single "difference" figure destroys the information you need to act. The manual version of this triage is covered in our guide to invoice-to-PO reconciliation.

Tolerances

Nobody wants a case opened because a line is off by two cents. A tolerance has two dimensions — an absolute amount and a percentage — and a rule for combining them:

• OR mode (the sane default): the line is an exception if either dimension is exceeded. Catches both small percentages on expensive lines and large percentages on cheap ones.
• AND mode: the line is an exception only if both are exceeded simultaneously. This is a noise floor — quieter, and it will let some real money through.

Comparison is strict: a value exactly equal to the threshold is within tolerance. This matters more than it sounds, because a supplier who knows your tolerance will price precisely at it.

A worked example, with the numbers

A PO for packaging supplies. Tolerance set to $1.50 absolute or 2%, OR mode. This is the case that makes the argument for line-level matching better than any explanation:

The trap: two of those five lines are clean. The other three cost $409. But if your process compares the invoice total against the PO total, the stretch film overcharge is partly masked by the pallets you never received, and the surcharge looks like it might be freight. A header-level check can produce a total that looks close enough to approve while three separate things are wrong.

This is why "the totals matched" is not a control. The full argument, with the arithmetic.

2-way, 3-way and 4-way matching

Most businesses need 3-way. 4-way earns its cost in pharma, chemicals and food, where a batch can be received and then quarantined — the pharma and chemical case. If you are evaluating vendors, the full three-way matching guide covers the process end to end.

The exception types worth naming

"Exception" is not one thing. A system that lumps them together sends every problem to the same person, which is why AP teams drown. These are the distinct states, and they route differently:

Two of these deserve their own attention: GRNI reconciliation for everything received and not invoiced, and duplicate invoice detection, which is the single exception type that costs real cash rather than accuracy — matching an invoice against its own PO cannot catch it, because the duplicate is a second invoice that matches perfectly on its own.

The cases that break naive matching

Any vendor can match a clean one-to-one invoice. These are the situations worth asking about in a demo, because they are where systems quietly fail:

• Partial delivery. The PO is for 100, 60 arrived, the supplier bills 60. Nothing is wrong. A system that compares against the PO quantity flags a false exception and trains your team to ignore alerts.
• Partial invoicing. One delivery, two invoices. Each is valid; only the sum can be checked against the receipt.
• Consolidated invoice. One invoice covering several POs and several deliveries. Matching has to run per line against the right order, not per document.
• Description drift. The PO says "Pallet 48x40 HT", the invoice says "EUR pallet heat treated". Same item, different words. This is the single most common reason matching engines fail in practice.
• Credit notes and rebates. A negative line that must reduce a specific earlier line, not float free — how rebates and credit notes reconcile.
• Freight and surcharges. Legitimate charges that will never have a PO line. The system needs a category for "expected to be unmatched" or it will cry wolf on every shipment.

Why this stops working in Excel

Excel handles matching fine at low volume, and there is no reason to buy software before you need it. It stops working for reasons that are structural rather than about effort:

• A VLOOKUP matches on exact strings. "Acme Ltd" and "ACME LIMITED" are different strings, so the lookup fails and a human reconciles by eye.
• Partial deliveries and partial invoices require state across multiple documents. A spreadsheet has no natural way to hold "40 of these 100 are still outstanding".
• There is no audit trail of who approved a variance and why, which is exactly what an auditor asks for.
• The work scales linearly with invoice count, so the cost of the control grows exactly as fast as the business.

The honest threshold is somewhere around a few hundred invoices a month, or the point where one person's week is consumed by it — where the line actually falls.

Buyer's evaluation checklist

Questions that separate real matching from a PDF reader with a rules engine bolted on. Ask them in the demo, with your own documents:

1. Does it match line by line or compare document totals? Ask to see a partial invoice.
2. Are price variance and quantity variance reported separately?
3. Are unit prices compared pre-tax?
4. Can tolerances be set per supplier or per category, and can you choose OR vs AND?
5. What happens when the invoice description does not textually equal the PO description?
6. Can it handle one invoice spanning several POs?
7. Does it detect duplicates across channels — the same invoice by email and by portal, days apart?
8. What is the exception routing model — does everything land in one queue?
9. Does it export to your accounting system, and is that export a live integration or a file?
10. What does implementation actually require, and what does it cost?

How ininvoice does it

ininvoice is a matching and validation layer that sits in front of your accounting system. It is not a full accounts payable suite and it does not execute payments.

• You connect Gmail. Supplier invoices and delivery notes that already arrive by email are read as they land, without anyone uploading anything.
• Open purchase orders are loaded by CSV or API.
• Every invoice line is matched to its PO line and receipt line, and price and quantity variance are computed on pre-tax unit prices with the tolerance rules above.
• Matched invoices pass through. Only exceptions are surfaced, with the amount and the cause stated in plain English.
• Duplicates are caught by supplier, number, amount and timing pattern, including when the same invoice arrives through two different channels days apart.
• Reconciled data exports in formats compatible with Holded, Sage 50/200 and A3 ERP. Native integrations are in development.

Where ininvoice is not the answer: if you need payment execution, global tax compliance or a full procure-to-pay suite with supplier onboarding, you are looking for a different category of product. If your problem is that nobody checks whether supplier invoices are correct before they get paid, that is exactly what this does.

Who needs this, and who does not

Worth it if: you buy physical goods against purchase orders, you receive a few hundred supplier invoices a month or more, several people touch the approval chain, and your suppliers send price changes you did not explicitly agree to.

Not worth it if: you buy mostly services with no delivery note, your invoice volume is low enough for one person to check properly, or you have no purchase orders at all — matching needs something to match against. If you have no PO discipline, fix that first; software cannot compare an invoice to an order that was never raised.

Frequently asked questions

What does invoice matching software actually do?

It compares each supplier invoice line against the corresponding purchase order line and goods receipt line on pre-tax unit prices, and flags lines where price or quantity fall outside tolerance, plus lines with no PO or no receipt at all. It does not simply compare invoice totals against PO totals.

What is the difference between 2-way and 3-way matching?

2-way compares the invoice against the purchase order only, confirming you were billed what you agreed but not that the goods arrived. 3-way adds the goods receipt, which is the only way to catch being billed in full for a short delivery.

Why is line-level matching necessary instead of comparing totals?

Header totals include tax and cannot represent partial invoicing or partial delivery. Two errors in opposite directions also cancel out: an overcharge on one line masked by an under-delivery on another produces a total that looks correct while both lines are wrong.

Does it replace the ERP?

No. It sits in front of it. Invoices are validated before posting, so only matched documents reach the accounting system and exceptions get resolved with the supplier first.

Is invoice matching the same as PO matching?

In practice they name the same job from different ends. "PO matching" emphasises the purchase order as the reference document; "invoice matching" emphasises the invoice as the thing being checked. Both mean comparing invoice lines against order lines, and in a 3-way process against the goods receipt too.

What tolerance should we set?

There is no universal answer, but a common starting point is a small absolute amount combined with a low percentage in OR mode, then tightening once you see the exception volume. Start loose enough that your team can clear the queue, then narrow it. A tolerance nobody has time to action is the same as no control at all.

How long does setup take?

Connect the inbox and load open POs by CSV or API. There is no implementation project and no setup fee. Historical PO loading does not block processing from starting.