Bank statement matching: why systems do it badly while claiming they do it
Almost every ERP claims automatic statement matching. The difference is what it does with a payment that matches no invoice exactly — and those are the majority.
- Published
- Author
- Konis Software
Automatic bank statement matching is a feature almost every business system now lists. The difference between them is not whether they match, but what they do with a payment that does not correspond exactly to any open item — and in any company dealing with more than a handful of customers, that is most of the interesting cases.
A system that easily matches a payment carrying the correct reference proves nothing: that is the easy part of the job and a spreadsheet can do it. The value begins with the rest.
The cases a system is measured by
| Case | What the system should do |
|---|---|
| Payment without a reference | Propose by amount and partner, flagged as a proposal rather than posted |
| One payment for several invoices | Allocate by age or by choice, with the remainder visible |
| Partial payment | Close part of the item; the remainder stays open with its own due date |
| Payment larger than the debt | An overpayment as a balance, not an error posted to a difference account |
| Wrong reference number | Recognition by amount and partner with a warning, not blind matching |
| Foreign currency inflow | Conversion at the rate on the inflow date, with the exchange difference posted separately |
A reference number is not a guarantee
A checksum-validated payment reference solves the retyping problem, but only when the payer actually uses it. In practice everything else happens: payment carrying the previous invoice's reference, the purchase order number instead of the invoice, or a reference that is valid by the checksum but belongs to another partner.
The correct behaviour is therefore to treat the reference as a strong signal rather than as proof: if amount, partner and reference do not point at the same item, that is a case for a person, not for automation.
The other direction: payment orders
The integration also runs outbound, and the stakes there are higher because money leaves. What is wanted from the system is less automation and more control.
- A proposed payment run from due liabilities, with dates and any early-payment discount.
- Approval by limit — an amount above a threshold requires a second signatory, enforced by the system rather than by agreement.
- Verification of the recipient's account against the partner record, because altering a bank account in an email is the most common payment fraud.
- A record of who created the order, who approved it and when it was sent — kept separate, because the same person must not do both.
Instant payment QR codes and collecting from individuals
For companies collecting from private customers, an instant-payment QR code on the invoice practically eliminates reference errors: the customer scans, and the data arrives correct. It is the cheapest possible intervention in matching — the error is prevented at source instead of corrected in the ledger.
What to ask for in the demo
- Import a real statement, not a prepared one — with all the messy cases your company actually has.
- Ask to see the unmatched items screen and how many steps it takes to resolve one.
- Ask whether a match can be reversed and what remains in the trail once it is.
- Ask how exceptions are learned — whether the system remembers that this customer always pays without a reference.
- Ask to see the exchange difference on a foreign currency inflow posted separately rather than absorbed into the amount.
In NG One matching is a rule over an event stream rather than a hidden procedure: every automatic closure records its provenance — what it matched on and with what confidence — and can be reversed with a trail. Whatever the system is not sure it understands stays open and visible, because that is the only form of automation that can be checked afterwards.