Running two wallets should not mean maintaining two definitions of revenue.
Finance needs one commercial ledger and separate provider evidence for each payment route.
Pull four sets of records
- The billing ledger: invoices or obligations that became due in the period.
- The M-PESA provider statement or transaction export.
- The Airtel Money provider or PSP statement/export available under the merchant setup.
- Settlement or bank evidence used by finance to confirm downstream movement of funds.
Do not use the settlement report as a substitute for the invoice ledger. They answer different questions.
Match at the transaction level first
For every successful payment, connect the provider transaction to the customer account and invoice using the strongest evidence available: invoice/reference, provider transaction ID, amount, time and merchant account.
The result should be one normalized row per payment, regardless of wallet.
A useful month-end report layout
Invoice ID | Customer | Amount due | Wallet | Provider reference | Paid amount | Payment date | Match status | Reconciliation status | Settlement status
The wallet column lets finance analyze method mix without splitting the commercial ledger.
Separate match exceptions from settlement exceptions
Payment-to-invoice exceptions
- Unknown account/reference.
- Amount mismatch.
- Two successful payments against one invoice.
- Invoice marked paid with no provider evidence.
Settlement exceptions
- Paid transaction not yet present in the expected settlement batch.
- Fee or net-amount difference that needs explanation.
- Settlement reference missing from the finance record.
Keep those queues separate. A customer can be fully paid while finance is still resolving settlement evidence.
Reconcile totals only after row-level exceptions are visible
Aggregate totals can balance while individual customer records are wrong. Close the period only after unmatched and duplicate items have owners and next actions.
Month-end close checklist
- Every successful provider transaction is matched or explicitly in an exception queue.
- Every paid invoice has supporting payment evidence.
- Duplicate successes are investigated.
- Externally satisfied invoices have documented evidence.
- M-PESA and Airtel Money totals are summarized from the same invoice ledger.
- Settlement exceptions are tracked separately from customer payment status.
For the deeper reconciliation model, use the M-PESA reconciliation guide and the reconciliation architecture guide.
Close the period in a repeatable order
Start with unmatched provider transactions, then duplicate successes, then paid invoices without evidence, and only after those are resolved compare provider and settlement totals. That order matters because a total can look correct while individual customer allocations are still wrong.
Assign every remaining exception an owner and a review date. A month-end report is not complete simply because the spreadsheet balances; finance should also know which unresolved items could still affect a customer account.
