Your bank transaction matches an invoice for a different amount, with no warning

Short answer. Bank transactions match automatically to purchase invoices based on amount, invoice number and counterparty. The moment the amount diverges, through a partial payment, a discount or PSP fees, the automatic match falls away and you have to sort it out by hand. 3-way matching (order, delivery, invoice) and tolerance settings help, but with many suppliers and channels you need your own validation that flags the difference instead of letting it through.

It goes fine as long as the amounts match exactly. A transaction with the right invoice number and amount is reconciled automatically in Exact or another package, and the invoice is marked as paid.

It goes wrong on the difference. And in a wholesale business, the difference is everywhere.

Why the automatic match falls away

An accounting package matches a bank transaction to an open item when the amount, the counterparty and the invoice number all line up. If the amount diverges, the automation stops.

That happens more often than you think. A partial payment. A deducted discount. A credit note that has been settled. Or a PSP payout that comes in as a single amount for dozens of orders, net of transaction fees. Reconciling that by hand costs hours (see praatmetjeboekhouding on reconciling PSP payments in Exact Online).

Tolerance and 3-way matching

Packages offer help. You can set a tolerance so a small difference is written off automatically to a general ledger account. And with 3-way matching you link the purchase invoice to the purchase order and the delivery, so that only what was ordered and received also gets paid.

That covers the ordinary case. But a tolerance does not solve a structural difference, and 3-way matching only works if your orders and deliveries sit neatly in one system. With purchasing spread across many supplier accounts and portals, that is exactly what they do not do.

The difference that slips through without a warning

This is where the real risk sits. A transaction matches an invoice for a different amount, and nobody is warned. The difference is written off or left standing, and your margin leaks in a place where nobody is looking.

What you want is not a tighter tolerance, but a signal. Does this difference line up with an agreed discount or volume tier for this supplier, or is it an error? That is a decision, and it ties back to your purchasing agreements per supplier, not to a matching rule in your accounting.

When your own validation pays off

The goal is a grip on your purchasing and your margin, with less manual work. So I review your reconciliation process first, because a part of the differences disappears once your purchasing agreements and your order flow are in order. The rest, the validation that links every difference to the right supplier and purchasing agreement and flags what does not add up, I build. That has to happen one way or another. The only question is whether it can be done smarter today than by hand.