Total matching is a trap: how overpayments slip through

Constructed example (synthetic data) that shows the trap

Distribution SME. Order to a chemical products supplier:

• Purchase order (PO): 100 units of product A at EUR 50.00/unit.
• Agreed total: EUR 5,000.00 + VAT.

Delivery note arrives:

• Received: 98 units. 2 came broken and were returned.

Invoice arrives:

• Invoice: 100 units at EUR 51.00/unit.
• Invoice total: EUR 5,100.00 + VAT.

If you match totals: approved

Agreed total EUR 5,000 vs invoiced total EUR 5,100. Difference: EUR 100 (2%). If your global tolerance is 2% or 3%, the invoice passes the check. Your system says: it matches. Your team approves and pays.

If you match line by line: two errors

Here the hidden reality appears:

Concept	Agreed (PO)	Received (DN)	Invoiced	Variance
Quantity	100 u	98 u	100 u	+2 u not received
Unit price	EUR 50.00	—	EUR 51.00	+EUR 1.00/u

The two variances calculated pre-tax:

• Price variance: (51 − 50) × 100 = EUR 100 in favour of the supplier.
• Quantity variance: (100 − 98) × 50 = EUR 100 you should not pay (those 2 units were not received).

What you should actually pay

98 units actually received, at the agreed price of EUR 50.00/unit:

98 × 50 = EUR 4,900.00 + VAT.

You are paying EUR 5,100, you should be paying EUR 4,900. Overpayment: EUR 200. And total matching approves it without blinking because “the difference is within tolerance”.

Why this happens in practice

Three real reasons why total matching survives at SMEs:

1. ERPs ship it that way by default

Most accounting systems compare totals as a quick check. It comes out of the box. Line-level granularity is usually an extra module, a custom integration, or done by hand in Excel.

2. The two discrepancies cancel each other out

If there was only a price error (EUR 1/unit more), the invoice would be 100 × 51 = EUR 5,100 vs EUR 5,000 ordered = EUR 100 variance. Detectable.

If there was only a quantity error (2 units short), the invoice would be 100 × 50 = EUR 5,000 equal to the PO. Matches to the cent.

The problem is when both errors happen at the same time on the same invoice: they cancel each other out numerically when you sum the total. The trap.

3. VAT mixes the bases

If you compare VAT-inclusive, line-level rounding (some lines at 21%, others at 10%, some exempt) creates enough noise that small real variances go unnoticed. That is why the matching always has to be pre-tax, on each line’s taxable base.

How much this costs you per year

Realistic estimate for a distribution SME with 600 invoices/month and an average ticket of EUR 1,500:

• Invoices with line-level variance not detected by totals: 5-9% of the total. Let’s estimate 7%.
• Average overpayment when it occurs: order of EUR 100-300/invoice. Let’s estimate EUR 150.
• Monthly calculation: 600 × 7% × 150 = ~EUR 6,300/month of invisible overpayment.
• Annual calculation: ~EUR 75,000/year.

Estimates based on an average distribution SME profile. Your real figure depends on volume, sector, supplier quality and the rigour of your current matching process.

The rule that avoids the trap

Line-by-line, pre-tax matching. Three operating rules:

1. Compare pre-VAT unit prices, invoice vs PO.
2. Compare quantities, invoice vs delivery note (not invoice vs PO directly).
3. Per-line tolerance, not global. A EUR 50 variance on a EUR 50 line is 100%. A EUR 50 variance on a EUR 5,000 line is 1%. Same absolute number, different pain.

Recommended tolerance: 2% or EUR 1.50 per line (OR mode): the variance exceeds the threshold if it exceeds EITHER of the two.

Why accounting ERPs don’t do this on their own

These systems are ERPs / accounting. Their job is to record the invoice, not to control it. When an invoice arrives, they assume someone has already validated it. They trust whoever passes it along. That is why line-by-line matching usually falls on the person who receives the email, opens the PDF, looks up the PO in Excel and compares by eye.

That works with 30 invoices a month. With 300 it collapses. With 600 it lets 7% slip through by pure statistics: nobody has time to review every document line by line.

How ininvoice automates this

ininvoice sits between your supplier’s email and your ERP:

1. Captures the invoice from the email (Gmail).
2. Extracts data line by line from PDF, image or scanned invoices (XML e-invoice reading is in development).
3. Looks up the PO via fuzzy matching, even if the invoice does not carry the exact number.
4. Cross-checks every line: pre-VAT unit price, quantity, discounts.
5. Applies a 2% or EUR 1.50 per-line tolerance (OR mode), set by your organisation: a line is flagged if it exceeds either limit.
6. If a line exceeds tolerance, it raises an exception and holds the invoice with the line flagged.
7. If every line matches, it is ready for a person to approve; once approved, it is exported as a CSV or Excel file ready to import into your ERP.

The total is still calculated, but as a coherence check, not as the matching criterion. The match is judged per line, and a person approves the invoice.