The verdict in three sentences
Consolidating M-Pesa and Airtel Money starts with normalising references and then handling timing differences (statement pulls vs real-time callbacks) in one EAT timezone. The single ledger must reconcile, per operator, total collected, fees and net paid out. The operational target: keep the discrepancy rate below 0.3% and investigate any line beyond it.
Normalise two formats into one
Each operator exposes transactions with its own fields. The first step is a common schema everything maps into.
| Unified field | M-Pesa (Daraja) | Airtel Money |
|---|---|---|
| Reference | TransID | transaction_id |
| Date/time | TransTime (EAT) | timestamp |
| Gross amount | TransAmount | amount |
| Fee | charge | fees |
| Net | net | net_amount |
| Counterparty | MSISDN | msisdn |
Once columns are aligned, every row is comparable. Matching uses a key of MSISDN + amount + rounded timestamp, which avoids false positives when two customers pay the same amount.
Handle settlement timing
The classic trap: reconciling today's sales against a settlement that, for statement-based pulls, reflects yesterday's activity. Here is the 2026 calendar to model.
| Operator | Data source | Fee (est.) | Target gap |
|---|---|---|---|
| M-Pesa | Daraja statement (batch) | tiered by band | < 0.2% |
| Airtel Money | real-time callbacks | tiered by band | < 0.3% |
| Bank sweep | T+0 to T+1 | small | < 0.3% |
Add an expected settlement date column distinct from the sale date. Bank reconciliation runs on settlement date, revenue accounting on sale date. Conflating the two is the number-one cause of phantom gaps.
Tooling: spreadsheet or SQL?
Under 2,000 rows per month, a structured Google Sheet with one tab per operator and a consolidation tab is enough. Above that, a small SQL base (one transactions table with an operator column) makes discrepancy queries instant and hardens the control. Either way the rule holds: one source of truth, one schema, one automated gap check.
Mini case study
Need a professional website?
Kolonell builds websites that attract clients, optimized for the Sénégalese market. Free quote in 2 minutes.
Wanjiru runs a grocery in Nairobi and in December 2026 collects: KES 90,000 on M-Pesa and KES 40,000 on Airtel Money, a gross of KES 130,000. After fees she expects roughly KES 128,400 in the bank. Her unified ledger flags a missing M-Pesa amount of KES 380, a 0.29% gap. Tracing the reference, she finds a pending transaction not yet settled, cleared the next day. Without a consolidated ledger, that KES 380 would have vanished into the noise.
FAQ
How do I avoid false matches between two identical payments?
Use a composite key of MSISDN + amount + timestamp rounded to the minute. Two KES 500 payments at different instants stay distinct.
What about a pending transaction at month-end?
Book it to a suspense account on the sale date, then match it at actual settlement. It must neither disappear nor inflate the expected net for the month.
Do I need a single timezone?
Yes. Bring every timestamp to EAT before reconciling, otherwise an 11:55pm sale can jump a day.
At what gap should I investigate?
Set the alert threshold at 0.3%. Below it, sample-check; above it, line-by-line investigation before closing is mandatory.
Can consolidation be automated?
Yes, via operator APIs (Daraja, Airtel callbacks) or a scheduled CSV import into one base. Automation removes re-keying and cuts human error at the source.
Let's talk about your project. We build your unified multi-operator ledger with automatic discrepancy control. WhatsApp +221 77 596 93 33.
Mohamed Bah
Fondateur, Kolonell
Passionate about digital and entrepreneurship in Africa, Mohamed has been helping Sénégalese businesses with their digital transformation since 2020. Founder of Kolonell, he believes every SME deserves a professional and accessible online présence.
