The unallocated list nobody wants to own
Customers top up by bank transfer. Businesses using your product receive payments from their own customers. Borrowers make repayments. Most arrive with the right reference and are credited automatically. Some do not. The reference is missing, mistyped, includes an old invoice number, or the payer pasted the account holder's name instead.
Those payments land in an unallocated account. Someone in ops looks at the list now and then, searches for a customer by name or amount, and credits the ones they are sure about. The rest stay. The list grows, and some items on it are months old. Meanwhile customers write in to say they sent money and it has not appeared.
Why exact matching is not enough
Automatic allocation usually looks for one thing: the reference matching a customer or an expected payment. People do not type references carefully.
| What arrives | Why exact matching fails | What could match it |
|---|---|---|
| Reference with a typo | One character out | Near match on the reference plus the payer name |
| No reference | Nothing to match | Payer name and account against past payments |
| Right person, wrong reference | Reference belongs to a different product | Payer's history and expected amount |
| One payment covering two expected ones | Amount does not match either | Sum of open expected payments for that customer |
| Payment from a third party | Payer is not the customer | Reference or amount only, needs a person |
Each of these can be matched with more effort. That effort is currently a person searching by hand.
Money in limbo
For the customer, their money has disappeared, which is the worst thing a financial product can do to them. For you, unallocated money is a reconciliation item, a support queue and, if it sits long enough, a harder problem about who the money belongs to. How long you hold unallocated funds and what you do with them is for your own policy and advisers; the build makes sure the policy is followed.
Layered matching and a clean queue
What we build tries harder to match automatically, and makes the leftovers quick for a person to resolve.
- Every incoming payment first goes through exact matching on reference, as now.
- Unmatched payments are tried against fuzzy reference matches, payer name and account history, and open expected payments such as repayments due.
- Each potential match gets a confidence level. Only matches meeting the rules you set are credited automatically, and they are logged as such.
- The rest go to a review queue that shows the payment, the best candidates and why each was suggested.
- Resolving an item credits the right customer through your ledger and records who decided and why.
- For payments that cannot be matched, the queue tracks the age against your policy and supports your process for contacting the payer or returning the funds.
- Where a customer writes in about a missing payment, support can search the unallocated list from the helpdesk.
We also look at why references go wrong. Often a clearer reference in the app, a copy button or a shorter format prevents a lot of the problem.
A shorter list, every day
More payments land in the right place without anyone touching them. The review queue has fewer items, each with a suggested match, and ops clear it daily instead of when someone has time. Customers who write in get an answer from support directly.
Old items get the attention your policy says they should, because their age is visible.
Are unallocated payments building up?
- Your unallocated list includes items weeks or months old.
- Ops search for matches by name and amount by hand.
- Customers regularly say they paid and cannot see it.
- Only exact reference matches are credited automatically.
- Nobody owns the list day to day.