M-Pesa Daraja API Reconciliation: Automating Statement Matching in 2026

The verdict in three sentences

Bank reconciliation of mobile money flows crosses three references: the operator wallet, the bank statement and the accounting ERP. The main trap: a grouped settlement where a single bank credit bundles 300 sales, impossible to reconcile without the detail file. The 2026 method: map keys between the three systems, replay doubtful lines via the status API, and hold a 0.5% gap tolerance beyond which you investigate.

The three references and why they diverge

Each reference tells part of the story. The operator wallet knows every unit transaction at the moment it happens. The bank only sees the grouped payout (settlement) that arrives T+1, often net of fees. The ERP carries orders and invoices on the business side. Reconciliation means making these three views coincide.

The most common divergence comes from the grouped settlement. In Nairobi, a merchant who sells 300 times in a day does not see 300 credits on their bank account the next day: they see one credit for the total, minus fees. Without the detail file provided by the operator, it is impossible to know which sales make up that credit.

The detail file is the bridge: it links the bank's grouped credit to the wallet's unit transactions and the ERP's orders.

Key mapping and control queries

Automating reconciliation assumes each system shares a common key. In practice, you chain several keys: the operator reference links the wallet to the detail file, and the order reference links the detail file to the ERP. When a line does not match, you replay it via the status API (for example the Transaction Status Query of the Daraja API for M-Pesa) to decide.

Recommended frequency: a daily reconciliation on the previous day's settlement. At T+1, the detail file is available, and processing each day prevents a gap from drowning in the next. The 0.5% tolerance generally covers fees and rounding; beyond that, you investigate line by line.

Mini case study

Ibrahim runs a restaurant chain in Nairobi with online ordering. On 12 April 2026, his ERP shows 300 orders for 4,500,000 FCFA (equivalent). The next day, his bank credits a single payout of 4,470,000 FCFA. Apparent gap: 30,000.

With the detail file, he breaks it down: the grouped credit matches the 300 lines, and the 30,000 FCFA are operator fees (about 0.67%), to be booked as a charge. One line resists: an order of 15,000 FCFA absent from the detail. He runs a Transaction Status Query: the payment timed out, never debited; he cancels the order. Result: reconciliation closed in 30 min instead of 3h, residual gap back to 0%.

FAQ

Why a single bank credit for hundreds of sales? Because the operator uses grouped settlement: it adds up a period's transactions and pays the net in one go, usually at T+1. The detail file is essential to split that credit.

What gap tolerance should you accept? A 0.5% tolerance absorbs normal fees and rounding. Beyond that, every unmatched line must be investigated: often a timeout, a refund or a mis-provisioned fee.

How often should you reconcile? Daily on the previous day's settlement (T+1). Daily reconciliation prevents buildup and keeps each grouped credit traceable while the detail file is fresh.

How do you settle a doubtful line? Via the operator's status API (for example Daraja's Transaction Status Query). It re-checks a transaction's real state and lets you decide: collect, cancel or refund.

Should you integrate reconciliation into the ERP? Ideally yes: above 300 transactions a day, automated reconciliation that pushes status into the ERP saves hours of data entry and makes the balance sheet reliable.

Let's talk about your project. We automate your wallet-bank-ERP reconciliation with detail files and status queries. WhatsApp +221 77 596 93 33.