Reconciliation is the unglamorous work of proving that what your books say happened is what the bank says happened. Done by hand it is slow and quietly error-prone, because the failure mode is not a crash — it is a number that is wrong for a month before anyone notices.
Most matching problems are reference problems
Teams reach for smarter matching logic when the real issue is that incoming payments carry nothing useful to match on. A credit labelled with a payer's name and nothing else can correspond to any of their open invoices, or to a part payment of several.
No amount of fuzzy matching fixes missing information. The fix is upstream: make the payment carry an identifier before it ever reaches your bank statement.
Why narration matching fails
The narration field is the obvious place to look and the worst place to rely on. It is free text, it is truncated differently by different banks, and it is filled in by someone who does not care about your reconciliation.
- Customers type the invoice number inconsistently, or not at all.
- Banks truncate the field at different lengths, so the reference you need is often the part that was cut.
- Intermediary systems rewrite it, prefixing their own codes.
- The payer's name in the narration is the account holder, who may not be the entity you invoiced.
- Group companies pay for each other, so the name you see belongs to a customer you do not have.
How a virtual account solves it
A virtual account number maps to your real account but is unique per customer. When money arrives, the account it arrived into identifies who sent it — with no dependence on what they typed in the narration.
- Identity comes from the destination, not from free text the payer controls.
- It survives partial payments: three transfers into the same virtual account are unambiguously from the same customer.
- It works for customers who pay by bank transfer, where you have the least control over the reference.
- It identifies the payer even when a group company pays on their behalf, because the destination is what you assigned.
- Funds still settle into your real account, so nothing changes downstream in treasury.
Choosing the granularity
Virtual accounts can be issued per customer, per invoice, or somewhere in between. The choice decides how much ambiguity is left after the credit arrives.
| Granularity | Identifies | Best when |
|---|---|---|
| Per customer | Who paid | Customers pay regularly against a running account |
| Per invoice | Who paid and for what | Invoices are discrete and part payment is rare |
| Per customer per project | Who paid and against which engagement | Long-running work billed in stages |
| Per collection channel | Which route the money came by | Several sales channels settling into one account |
Per customer is the usual starting point: it removes the hard problem (identity) and leaves the easy one (allocation), which your ledger can often resolve by age or by the amount matching an open invoice exactly.
The cost of going too granular
Per-invoice accounts look like the complete answer and bring their own problems. Every invoice now needs an account provisioned, communicated and eventually retired, and customers with saved payees find the number changing every month.
- Customers save payees. A number that changes per invoice defeats that, and they will pay the old one.
- Provisioning volume rises with invoice volume, which may hit limits you did not know existed.
- Retiring accounts becomes a housekeeping task nobody owns.
- A payment to a retired account still has to go somewhere sensible.
Per customer avoids all four, and the allocation it leaves behind is usually solvable from the amount and the open invoice list.
Automate the match, keep a human for exceptions
An exact match on amount and reference should post without review. Everything else belongs in a queue for a person.
- Auto-post the unambiguousRight payer, right amount, one open invoice. This should be the large majority and should need no attention at all.
- Queue the ambiguousPart payments, overpayments and credits that could settle more than one invoice. Show the candidates and let a person choose in one click.
- Escalate the unidentifiableA credit into no known virtual account is genuinely unknown. Keep these visible rather than letting them sit in a suspense account unexamined.
- Let the resolution teach the matcherWhen a reviewer allocates an ambiguous credit, record the pattern. The same customer short-paying by the same rounding every month is a rule waiting to be written.
- Run it dailyA short exception list gets cleared. A monthly one becomes a project, by which point the context has gone.
The exceptions you will actually see
| Exception | Usual cause | Reasonable default |
|---|---|---|
| Short payment | Deduction, dispute, or bank charges | Part-settle and flag the balance |
| Overpayment | Duplicate transfer or advance | Post and hold as credit on account |
| Round-sum payment | Customer paying several invoices at once | Offer the open set and let a human allocate |
| Credit to a closed account | Saved payee not updated | Route to the customer's current account and notify |
| No known account | A payer you have not onboarded | Hold visibly and investigate; never auto-write-off |
Rolling it out without disrupting collections
The risk in a migration is that customers keep paying the old details while your team assumes everything has moved. Treat the old route as a supported path for longer than feels necessary.
- Issue virtual accounts to new customers first, where there is no saved payee to displace.
- Migrate the highest-volume existing customers next, individually, with a conversation rather than a bulk email.
- Keep the main account's existing matching path running throughout — credits there are expected, not errors.
- Put the virtual account number on every invoice, so the correct details travel with the request to pay.
- Track the share of receipts arriving via virtual accounts, and stop treating the old path as temporary until that number plateaus.
What this changes for the customer
Virtual accounts are usually sold as a finance-team benefit, and most of the value is there. They also change the customer's experience, mostly for the better and in one respect for the worse, which is worth handling deliberately.
- Better: the customer stops being chased about unidentified payments, because their payments identify themselves.
- Better: part payments and advances stop producing confused statements, because everything lands in one identifiable place.
- Better: a saved payee works indefinitely, since a per-customer account does not change between invoices.
- Worse: the first communication asks them to change bank details, which is exactly what a payment-redirection fraud also asks.
Communicating a change of details without looking like fraud
- Tell them through a channel you already useAn invoice they expect, or a conversation with the person they deal with. Not a one-off email from an address they have never seen.
- Keep the old account liveIf the previous details still work, a cautious customer who ignores the change still pays you. Removing the old route is what forces the issue.
- Put it on the invoice, not only in a noticeThe details that get used are the ones on the document being paid.
- Expect verification calls and make them easyBrief whoever answers the phone, so a customer ringing to confirm reaches someone who knows about the change immediately.
- Never ask for urgencyUrgency is the fraud tell. A migration with no deadline is both less alarming and, since the old route still works, true.
Frequently asked questions
Is a virtual account a real bank account?
It is a number that routes into your real account. Funds settle into the underlying account as normal; the virtual number exists so that the destination identifies the payer.
Should I issue one per customer or one per invoice?
Per customer is the usual starting point — it solves identity, which is the hard part, and leaves allocation to your ledger. Per invoice adds provisioning overhead and breaks saved payees, which is how customers end up paying a retired number.
Why is matching on the narration field unreliable?
It is free text supplied by the least-motivated participant, truncated differently by different banks and sometimes rewritten by intermediaries. Anything built on it degrades as volume rises.
Does this replace matching on amount and reference?
No, it strengthens it. The virtual account establishes who paid; amount and any reference still determine which invoice it settles. Together they take most credits to an unambiguous match.
What about customers who keep paying into the main account?
Expect some to, especially long-standing ones with the old details saved. Keep the existing matching path for those credits and migrate customers gradually rather than treating the old route as an error.
What should happen to a credit that matches no known account?
Hold it visibly and investigate. The failure mode to avoid is letting unidentified credits accumulate in a suspense account where nobody looks at them.
