Reconciliation is the discipline that proves a mobile money service is telling the truth: that every shilling in customers' wallets is backed by money in the bank, that every partner has been paid exactly what they are owed, and that nothing has leaked in between. It is invisible to customers when it works and catastrophic when it does not. This guide explains what needs to be reconciled in a wallet business, why a double-entry ledger makes most of it mechanical, how to handle the exceptions that always remain, and what a healthy daily close looks like.
What "reconciled" means for a wallet
A mobile money service holds money in several places at once and owes it to many parties. Reconciliation means demonstrating, regularly and with evidence, that the internal record (the ledger) agrees with every external record (bank statements, partner reports, switch settlements) and that the internal record is consistent with itself.
There are four big reconciliations every operator must run:
- Safeguarding: total e-money in all wallets equals the balance in the trust accounts.
- Bank accounts: every movement on each bank statement matches a ledger entry, and vice versa.
- Partners and rails: what the ledger says was sent to or received from each biller, airtime provider, switch, bank or remittance partner matches their reports.
- Agents and merchants: float, commissions, sales and settlements match what agents and merchants see and what they were paid.
Start with the ledger: why double-entry changes everything
In a system where balances are stored as numbers and updated by code, reconciliation is detective work: find which update went wrong, when, and why. In a double-entry ledger, every movement is recorded as balanced debits and credits, and every balance is calculated from those entries. Two powerful properties follow:
- The ledger can always prove itself. The sum of all debits equals the sum of all credits, always. If it does not, something is fundamentally wrong, and you know immediately.
- Every balance has a history. Any wallet, agent float or partner position can be rebuilt from its entries, so a disputed balance is explained line by line.
With that foundation, most reconciliation stops being investigation and becomes matching.
Designing the chart of accounts for reconciliation
How you structure accounts on the ledger decides how easy reconciliation will be. A reconciliation-friendly design includes:
- Customer, agent and merchant wallets as individual accounts.
- A trust asset account per safeguarding bank account, mirroring each real account.
- Clearing (suspense) accounts per external rail: one for each biller aggregator, bank connection, switch and partner, holding amounts that are in flight.
- Fee income and commission expense accounts, separated by product.
- Settlement accounts per merchant and partner, holding what is owed until paid out.
- Loan and float credit accounts, if you lend.
With per-rail clearing accounts, "how much do we owe the airtime provider right now?" is a single balance, not a report.
The safeguarding reconciliation
This is the reconciliation regulators care about most. Each day:
- Import the closing balance and transactions of every trust account from the bank.
- Calculate total e-money liabilities from the ledger: all customer, agent and merchant wallet balances, plus any other e-money obligations.
- Compare. Explain every difference with items in transit, such as deposits the bank has not yet posted, or payouts not yet cleared.
- Escalate any unexplained difference immediately, and top up the trust account if it is short.
A good platform produces this report automatically every morning, with the explained differences itemised.
Bank statement matching
Every bank account connected to the service, whether trust, settlement or operating, should be matched line by line:
- Import statements automatically, through bank APIs or file exchange, rather than by download and copy-paste.
- Match on reference first, then on amount and date within a tolerance.
- Auto-post known items, such as bank fees or interest, with rules.
- Queue exceptions for a person to resolve, with the evidence attached.
Consistent references are the secret. When every payout, float purchase and settlement carries a unique reference that appears on the bank statement, most lines match themselves.
Partner and rail reconciliation
External rails are where most differences arise, because each partner has its own view of what happened:
| Situation | Ledger shows | Partner shows | Resolution |
|---|---|---|---|
| Timeout, partner completed | Pending | Success | Complete the transaction; confirm to customer |
| Timeout, partner failed | Pending | Failed | Reverse the customer's debit |
| Duplicate callback | One success | One success | Ignore the duplicate (idempotency) |
| Partner-side reversal later | Success | Reversed | Post a reversal with the partner's reference |
| Amount mismatch | X | Y | Investigate; adjust with approval and trail |
Two design choices keep this manageable. First, explicit pending states: a transaction whose outcome is unknown is never shown as failed or succeeded until confirmed. Second, idempotency keys on every external request and callback, so retries never create duplicates. Both are covered in interoperability and prompt-to-pay.
Agent and merchant reconciliation
Agents and merchants reconcile their own businesses against the platform, and their trust depends on it:
- Agents need a daily view of opening float, every transaction, commission earned and closing float, which should match their own count.
- Merchants need a daily Z-report of sales by payment method, refunds, fees and settlement, which should match their till and stock records.
- Super-agents need a view of float distributed to and returned from each outlet.
Commission and settlement payouts should post as ledger entries with references, so any question can be answered from the statement.
Reversals: correcting without erasing
Mistakes happen: a transfer to the wrong number, a duplicate payment, a biller that rejected a payment after accepting it. The golden rule of reconciliation is that nothing is ever deleted or edited. A correction is a new transaction that mirrors the original, linked to it by reference, with a reason and an approver. That way, the history always explains the current balance, and auditors can see both the mistake and its correction.
A single reversal engine for every transaction type, whether transfers, bill payments, merchant payments, agent cash, bulk payouts, float or savings, keeps corrections consistent and auditable.
The daily close
A healthy wallet operation closes each day with a routine:
- Ledger integrity check: debits equal credits; no orphan entries.
- Pending review: resolve transactions still pending from external rails, querying partners for status.
- Bank matching for all accounts; exceptions assigned.
- Safeguarding reconciliation and top-up if needed.
- Partner settlement: calculate what is owed to or by each partner; initiate settlements.
- Merchant and agent settlement and commission payouts.
- Exception report to finance leadership, with ageing of unresolved items.
The goal is to shrink manual work to genuine exceptions, and to shrink the exceptions over time by fixing their root causes.
A worked example: one morning's safeguarding reconciliation
The figures below are illustrative, but the structure is exactly what a finance team reviews each morning:
| Item | Amount |
|---|---|
| Total customer wallet balances (ledger) | 412,580,000 |
| Total agent float balances (ledger) | 63,240,000 |
| Total merchant wallet balances (ledger) | 28,910,000 |
| Total e-money liabilities | 504,730,000 |
| Trust account A closing balance (bank) | 301,000,000 |
| Trust account B closing balance (bank) | 199,580,000 |
| Total trust balances | 500,580,000 |
| Difference | 4,150,000 |
| Explained: agent float purchases deposited late yesterday, posted by bank this morning | 3,900,000 |
| Explained: interest credited by bank, not yet posted to ledger | −120,000 |
| Explained: bank charges debited, not yet posted | 370,000 |
| Unexplained difference | 0 |
Every explained item should link to its evidence: a bank line, a ledger entry, or both. If the unexplained line is not zero, the day does not close until it is resolved or escalated, and if trust funds are short, they are topped up first and investigated second.
The usual root causes of breaks, and how to remove them
After a few months, most reconciliation exceptions turn out to come from a handful of causes. Fixing each at the source is worth far more than resolving them one by one:
| Root cause | Symptom | Permanent fix |
|---|---|---|
| Missing or free-text references | Bank lines that match nothing | Generate unique references for every outbound payment; require them on inbound instructions |
| Manual journal entries | Differences no one can explain | Replace with rule-based postings; require approval and reason for any manual entry |
| Timeouts treated as failures | Customer refunded, partner also paid | Explicit pending states; status query before any reversal |
| Duplicate callbacks | Double credits | Idempotency keys on every callback |
| Partner reports in different time zones or cut-offs | Items appearing a day apart | Align cut-off times; match with a date tolerance |
| Fees netted by partners | Amount mismatches | Post expected fees as separate entries; agree gross settlement where possible |
Month-end, audit and the regulator
Daily reconciliation makes month-end simple: the month is just the sum of reconciled days. What month-end adds:
- Trial balance from the ledger, feeding the general ledger of the company's accounting system.
- Fee and commission summaries by product for revenue recognition.
- Partner statements agreed with each partner.
- Regulatory returns on e-money outstanding, trust balances, volumes and values.
- Evidence packs for auditors: daily reconciliation reports, exception logs with resolutions, and approvals for every manual adjustment.
External auditors and central bank inspectors increasingly ask for the full daily history, not just the month-end snapshot. A platform that stores every daily reconciliation report with its exceptions and resolutions answers those requests in minutes.
Who does what: roles in a reconciliation team
- Reconciliation analysts work the exception queues each morning.
- A finance lead signs off the safeguarding reconciliation daily and approves manual adjustments.
- Operations resolves partner issues and stuck transactions with partner support teams.
- Compliance reviews patterns that might indicate fraud or abuse, such as repeated reversals.
- Technology fixes root causes, such as missing references or new partner report formats.
Segregation matters here too: the person who makes a manual adjustment should not be the person who approves it.
Metrics for reconciliation health
- auto-match rate for each bank account and partner;
- number and value of open exceptions, and their age;
- transactions stuck in pending beyond the partner's timeout;
- unexplained safeguarding differences (target: zero);
- time to complete the daily close.
Designing references that reconcile themselves
Most reconciliation effort is spent matching items whose references were lost somewhere between systems. A few rules prevent that:
- One unique reference per transaction, generated by the platform, never reused.
- Carry the reference everywhere: in the ledger, in the SMS receipt, in the request to the partner, in the bank transfer narrative, and in notifications to merchants.
- Store the partner's reference too, alongside yours, as soon as it is returned.
- Short, typeable formats for references customers and agents may need to quote to support.
- Batch and line references for bulk payments, so both the batch total and each line can be traced.
Commission disputes: settle them from the ledger
Commission is where agents and operators most often disagree, because agents see it as income and operators see it as a cost to control. Three habits keep those disagreements short:
- Post commission with the transaction. Commission earned on a cash-in or cash-out should be a ledger entry linked to that transaction's reference, not a figure calculated later in a spreadsheet.
- Reconcile the expense daily. The total commission expense for the day should equal the sum of commission postings, and the payout run should clear exactly that balance.
- Answer disputes from the agent's own statement. When an agent queries a figure, support should open the same statement the agent sees and walk through the references, instead of producing a separate report that may not match.
When the rules change, for example a new tier or a promotion, date the change in the system so that each transaction is paid under the rule in force at the time. Retroactive recalculations are the most common source of commission disputes.
Common reconciliation mistakes
- Reconciling monthly. Breaks found a month late are much harder to resolve. Reconcile daily.
- Adjusting instead of investigating. A balancing entry that makes numbers agree without explaining the difference hides the problem until it grows.
- Spreadsheets as the system of record. Manual files break, get overwritten and leave no audit trail.
- Ignoring small breaks. Small recurring differences are often the first sign of a systematic bug or fraud.
Key terms in reconciliation
| Term | Meaning |
|---|---|
| Break | Any item that exists on one side of a reconciliation but not the other, or with a different amount. |
| Suspense account | A temporary ledger account holding items that cannot yet be matched or allocated; it should trend to zero. |
| Trust account | The bank account holding funds that back customers' e-money balances. |
| E-money float | The total of all customer, agent and merchant wallet balances, which must be fully backed by trust funds. |
| Three-way match | Agreeing the platform ledger, the partner's records and the bank statement for the same transactions. |
| Settlement file | A report from a partner listing transactions and the net amount to be paid or received. |
| Ageing | How long an unmatched item has been open; older breaks need escalation. |
| Double-entry | Recording every transaction as equal debits and credits, so the ledger always balances. |
| Idempotency | Making sure a repeated request, such as a retry after a timeout, does not create a second transaction. |
| Write-off | Removing an unrecoverable difference from the books after investigation and approval. |
Key takeaways
- Reconciliation proves that every balance is backed by real money and that every partner agrees with you.
- Reconcile daily, at three levels: the platform ledger, each partner's records and the bank statements.
- Carry one unique reference through every system, and store the partner's reference next to yours.
- Treat every break as a question to answer, not a number to adjust; age open items and escalate the old ones.
- Keep the trust account at least equal to total e-money float every day, and report it to the regulator as required.
- Automate matching so people spend their time investigating exceptions, not ticking lines.
Frequently asked questions
What is safeguarding reconciliation?
Proving that the total e-money in customer, agent and merchant wallets equals the money held in trust at banks, usually daily.
Why do mobile money transactions get stuck as pending?
When an external partner does not respond in time, the outcome is unknown. The transaction stays pending until the partner's status is confirmed, then completes or reverses.
How often should a wallet reconcile?
Safeguarding and bank matching daily; partner settlements according to each partner's cycle; ledger integrity continuously.
Can reconciliation be fully automated?
Most of it can, with a double-entry ledger, consistent references and automatic statement imports. A small number of genuine exceptions will always need a person.
PesaBridge starts reconciliation at the ledger: every send, payment, deposit and payout posts a balanced debit and credit, every balance is calculated from those postings, a single reversal engine with maker-checker corrects any department without deleting history, and statements tie out for customers, agents, merchants and corporates. See reconciliation and controls or talk to our team.
