If you run a multi-branch retail business in Kenya, M-Pesa is already your busiest till. Customers pay into a shared Paybill, the money lands in your bank account within seconds, and — on paper — that should be the easy part. In practice, it's where a surprising amount of revenue quietly goes missing.
The anonymous Paybill problem
A Paybill number doesn't know which branch took the payment, which sale it belongs to, or whether it's even a legitimate transaction versus a duplicate tap on a customer's phone. Safaricom's C2B callback gives you an amount, a phone number and a reference — not a sales order. When one Paybill serves ten branches, that stream of anonymous payments becomes a daily reconciliation problem for whoever is closing the books.
The usual response is a spreadsheet: someone downloads the M-Pesa statement, cross-references it against till receipts branch by branch, and manually matches what they can. It's slow, it's error-prone, and — critically — it's after the fact. By the time a mismatch surfaces, the shift has ended, the cash drawer has been counted, and nobody remembers which of three near-identical payments belonged to which sale.
From unallocated to allocated
The fix isn't a better spreadsheet — it's treating every M-Pesa payment as a record that has to be allocated before it's considered reconciled, the same way you wouldn't consider an invoice paid until it's matched to a receipt.
Every payment enters the system as unallocated: captured automatically the moment Safaricom's callback fires, with the amount, phone number, and timestamp intact, but no link yet to a sale. From there, allocation happens in one of two ways:
- Manual allocation at the till or back office — a cashier or branch admin matches the payment to the specific sales order, full or partial, at the point of sale or shortly after.
- Bulk allocation — where payments arrive faster than they can be matched one at a time (end-of-day catch-up, or an ERP export), a spreadsheet or ERP feed can allocate many payments against many orders in one pass.
Only once a payment is linked to a sale and a branch does it stop being a loose end. That distinction — unallocated versus allocated — is the single most useful thing a reconciliation system can surface, because it turns "did we get paid for this?" from a forensic exercise into a filter you can check in seconds.
Branch reconciliation, not head-office guesswork
With allocation in place, a branch reconciliation report becomes possible: for any branch, over any period, how much came in via M-Pesa, how much of it is allocated to a sale, and how much is still sitting unallocated. That last number is the one that matters. Unallocated balances are where leakage hides — payments that were received but never matched to a sale, sales that were recorded but never matched to a payment, or worse, cash sales rung up against a customer who actually paid by M-Pesa.
Making that number visible per branch, not just at group level, is what lets a finance team ask the right question of the right branch manager instead of auditing every branch equally.
Catching duplicates and suspicious payments before they cost you
Multi-branch cash handling has its own failure modes beyond simple mismatches. Two of the most common:
- Duplicate payments — a customer's transaction goes through twice (network retry, confusion at the till), and without automatic detection, someone downstream either double-allocates it or refunds it manually and hopes they got it right.
- Flagged payments — amounts that don't match any open sale, payments against unusually large sums, or patterns that look like they need a second look before they're allocated at all.
Surfacing these automatically, at the point they occur, is what turns reconciliation from a monthly forensic project into a daily five-minute check.
Four-eyes control on reversals
Reconciliation systems that let one person allocate and reverse a payment unilaterally create exactly the control gap you're trying to close. A four-eyes approval on reversals — one person requests it, a second person with the right role approves it — means a mis-allocated payment can be corrected without opening the door to someone quietly reversing a legitimate one.
When the system and the statement disagree
Callbacks occasionally fail to arrive — a stuck webhook, a network blip — and a payment that Safaricom processed never shows up in the system on its own. Recovery tooling that lets you import an M-Pesa statement directly and reconcile it against what the system already has closes that gap, so "the callback didn't fire" doesn't become "the payment is unaccounted for."
The result
None of this is about a single dramatic fix — it's about closing the small gaps where cash leakage actually happens: the unallocated payment nobody chased, the duplicate nobody caught, the reversal nobody double-checked. Put together, allocation, branch-level visibility, duplicate detection, four-eyes control and statement recovery turn a Paybill from a black box into an audit trail.
If cash reconciliation across your branches is still a spreadsheet exercise, it's worth seeing what it looks like when every M-Pesa payment is matched to a sale and a branch automatically. Request a demo and we'll walk through it against your own branch structure.
