Mobile Money Reconciliation Across Africa (M-Pesa, MTN, Airtel)
Mobile money is the dominant payment rail across much of Africa and the worst-reconciled item on most balance sheets. The five reasons a mobile money statement never matches your invoices, the pattern that fixes it without an integration, and a blunt statement of which single provider we actually connect to.
Mobile money solved payments across this continent faster than almost anyone expected and it has never been reconciled properly. Businesses that would never accept an unreconciled bank account will happily run a till number for years, matching against it monthly, by eye, from a phone.
The reason is not laziness. It is that mobile money breaks the assumption every accounting process rests on — that a payment identifies who paid and what for.
Start with the honest part
One provider, one country
Our only mobile money integration anywhere is M-Pesa in Kenya, through Safaricom's Daraja interface, using your own credentials so funds land in your own till. There is no MTN MoMo, no Airtel Money, no Orange Money, no Wave, no EcoCash, no Telebirr and no aggregator connection in any market. Everywhere else, mobile money is a reconciliation discipline rather than an integration. The rest of this post is mostly about that discipline, because it is what most readers will actually be doing — and because it works.
Why the statement never matches
Five structural reasons, and they compound. Recognising which ones apply to you determines how much of the problem is fixable by process alone.
- The payer is a phone number, not a customer. A wholesale customer pays from whichever handset is nearby — a driver's, a spouse's, an agent's. Your records know a customer; the statement knows an MSISDN. Matching them is a human act unless a reference is enforced.
- The reference is optional, and optional means absent. Where a reference field exists, a meaningful proportion of payments will carry a blank, a name, or "payment". Every one of those becomes an unallocated receipt somebody has to chase.
- Fees are deducted at different points by different providers. The customer paid one amount and you received another. If the invoice is settled at the gross figure, you carry a permanent small residue on the account; if at the net, the customer's balance is wrong.
- Timing differs from settlement. The transaction happened on Friday evening. The settlement into your account appears on Monday, possibly aggregated. Two different dates, one event, and month-end sits between them roughly once a year.
- Personal numbers are used for business. Extremely common in smaller businesses, and it makes reconciliation structurally impossible — business receipts are interleaved with school fees and airtime in a record nobody can share with a bookkeeper.
A bank payment tells you who paid. A mobile money payment tells you which handset was nearby.
The pattern that works without an integration
This is not a workaround waiting for a feature. A large number of well-run businesses across the continent reconcile mobile money reliably with no integration at all, and they all do roughly this.
-
Use a business number, always, and only
A till, paybill or merchant account separate from any personal number. Nothing else on this list works without it, and no amount of software fixes a business run through a personal wallet.
-
Enforce the reference at the point of asking
Put the invoice number on the invoice, in the SMS, in the WhatsApp message and on the delivery note — everywhere the customer is told what to pay. Reference discipline is won before the payment, never after.
-
Record the receipt against the invoice at the time
When the payment lands, allocate it. Not at month end. The allocation is trivial on the day and archaeological in three weeks, because the person who knew which customer that number belongs to has forgotten.
-
Import the provider statement on a fixed rhythm
Weekly, not monthly. A week of unmatched items is a task; a month of them is a project everybody postpones.
-
Book fees as fees, explicitly
Decide once whether the customer settles gross or net, write it down, and post the difference to a charges account rather than leaving it as a residue on the customer balance. The residues are what eventually make a receivables ledger untrustworthy.
-
Let someone other than the receiver reconcile
Segregation matters more here than almost anywhere, precisely because the transaction generates no paper of its own and the phone that received it is in someone's pocket.
What an integration actually adds
Worth being precise, because it is less than people assume and more than nothing. Using our Kenyan M-Pesa integration as the concrete example, since it is the only one we can describe from experience.
Integrated versus reconciled
| Capability | Integrated (M-Pesa, Kenya) | Reconciled (everywhere else) |
|---|---|---|
| Payment request pushed to the customer's phone | Yes | No |
| Payment lands in your own till, on your own credentials | Yes | Yes |
| Confirmation returned to the system automatically | Yes | No |
| Receipt matched to the invoice without a human | Yes | No |
| Paying a vendor from the system | Yes | No |
| Receipt recorded against the invoice | Yes | Yes |
| Provider statement imported and matched | Yes | Yes |
| Fees separated from the settled amount | Yes | Yes |
| Reference discipline still required | Partly — configurable by you | Yes |
Built and maintained Configurable by you, not maintained by us Not built
The honest reading of that table: an integration removes the manual matching step and the request-for-payment friction. It does not remove the need for a business number, for reference discipline, for a fee policy or for someone independent reconciling. Businesses that expect an integration to fix an undisciplined process are disappointed in every market, including the one where we have the integration.
The straight answer
What AWRA OpsHub does today
- M-Pesa in Kenya via Safaricom's Daraja interface, using your own credentials so funds land in your own till rather than passing through us.
- Payment requests pushed to a customer's phone for a specific amount against a specific sale, with the confirmation returned to the system.
- A dynamic M-Pesa QR for your till or paybill, which the customer scans and authorises — with confirmation out of band, so the receipt is recorded when the funds are seen.
- Outgoing payments to a vendor's phone, and to a vendor's paybill or till, matched back to the transaction when the provider confirms.
- Recording any mobile money receipt against an invoice in any country, whether or not there is an integration behind it.
- A payments register that holds money in and money out across modules, which is where the reconciliation actually happens.
What it does not do
- No MTN MoMo, Airtel Money, Orange Money, Wave, EcoCash, Telebirr or any other provider, in any country.
- No payment aggregator integration that would cover several providers at once.
- No automatic import of provider statements anywhere. Statements are imported by you and matched.
- No automatic bank feeds in any market.
- No float or agent management, and nothing that supports operating as a mobile money agent.
- No mobile money in any country other than Kenya, including for Safaricom operations elsewhere.
The obvious question is why. The answer is that eTIMS and this integration both exist because Kenyan clients commissioned them, and neither appeared from a roadmap. If a specific provider in your market is what stands between you and a decision, tell us — it is a build with a written spec, timeline and price, not a checkbox we are withholding.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a revenue authority pipeline, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax and e-invoicing pipelines
Electronic invoicing against your revenue authority's published interface, with the parts vendors gloss over — retries, a failure queue and a daily report of sales carrying no fiscal reference.
Banks, payments and mobile money
Statement feeds, payment gateways, bulk-payment files and collection accounts wired into the Payments Register so money in and out reconciles without re-keying.
Payroll and statutory returns
Payroll and social security schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedWhat to ask a vendor claiming continental coverage
Three questions, all checkable
Which providers, in which countries, live in production today?
What you will hear
A list of logos, or "we integrate with mobile money across Africa".
How to read it
Logos are not integrations. Ask for a named provider, a named country, and a customer using it last month whom you can telephone. This question resolves the conversation faster than any other.
Does the money touch your account at any point?
What you will hear
Usually not addressed unless asked.
How to read it
There is a real difference between an integration using your own merchant credentials, where funds land directly in your till, and an aggregator model where they pass through someone else first. Both exist and both are legitimate — but the second has settlement timing and counterparty implications you should understand before signing.
What happens to an unreferenced payment?
What you will hear
A description of automatic matching.
How to read it
Ask specifically about the payment with no reference, or the wrong one. Every provider has them. The useful answer describes a suspense treatment and a queue somebody works — not a claim that matching is automatic, which is true only for the payments that were already easy.
Where to go next
The continental framework is in the best ERP software for African businesses. For the field-team version of the same problem — advances issued and retired over mobile money — see field advances and mobile money.
By market: retail and POS in Abidjan and Dakar works through the two-custody pattern where no integration exists, digitizing operations in Uganda covers the MTN and Airtel context, and donor-funded operations in Southern Africa covers the EcoCash and MoMo reconciliation discipline for grant portfolios.
Our take
Get a business number, enforce the reference where you ask for the money rather than after it arrives, allocate receipts on the day, import the statement weekly, and let someone other than the receiver reconcile. That pattern works in every market on this continent with no integration at all, and businesses running it are better reconciled than businesses with an integration and no discipline. Then treat every vendor claim about continental mobile money coverage as a factual assertion with a phone number attached — ours is one provider in one country, and we would rather say so.
See mobile money reconciled properly
Receipts recorded against invoices, fees separated, statements matched on a rhythm, and a payments register that holds money in and out across every module — with M-Pesa integrated directly in Kenya.
Talk to us about your payment railsFrequently asked questions
Which mobile money providers do you integrate with?
One: M-Pesa in Kenya, through Safaricom's Daraja interface. There is no MTN MoMo, Airtel Money, Orange Money, Wave, EcoCash, Telebirr or aggregator connection in any country, including for the same operators' services in other markets. Everywhere else, mobile money receipts and payments are recorded and reconciled against imported provider statements. We state this plainly because it is exactly the claim that gets inflated in regional marketing, and because the reconciliation pattern works well enough that overstating it would be unnecessary as well as dishonest.
Does our money pass through you?
No. The Kenyan M-Pesa integration uses your own merchant credentials, so a customer payment lands directly in your own till or paybill and an outgoing vendor payment leaves from your own shortcode. We are not in the settlement path and we do not hold your funds at any point. This is worth checking with every vendor who offers payment features: an aggregator model where funds pass through a third party before reaching you is legitimate and common, but it has settlement timing and counterparty implications you should understand before signing.
Can we reconcile MTN MoMo or Airtel Money without an integration?
Yes, and a great many well-run businesses do exactly that. Record the receipt against the invoice at the time it is received, import the provider statement on a weekly rhythm, book fees explicitly to a charges account rather than leaving residues on customer balances, and have someone other than the person holding the phone perform the reconciliation. The discipline that makes it work is upstream: a business number rather than a personal one, and the invoice reference placed everywhere the customer is asked to pay.
What do we do with payments that have no reference?
Treat them as a queue rather than a mystery. Record the receipt as unallocated against a suspense treatment, and work the queue on a fixed rhythm while the information is still recoverable — someone in the business usually knows which customer a number belongs to for about a fortnight, and then nobody does. The permanent fix is upstream: reference discipline is won at the moment you ask for payment, by putting the invoice number in the invoice, the message and the delivery note.
How should we handle transaction fees?
Decide once, write it down, and apply it consistently. Either the customer settles the gross amount and the fee is your cost, or they settle net and the difference is theirs — both are workable, and mixing them is what creates untrustworthy receivables. Post the fee to a charges account explicitly rather than leaving small residues sitting on customer balances, because those residues accumulate silently and eventually make the whole ledger something people work around rather than rely on.
Is using a personal number really that bad?
Yes, and it is the one item on this list with no software remedy. Business receipts interleaved with personal transactions cannot be shared with a bookkeeper, cannot be reconciled independently, cannot be audited, and put the business's cash inside an individual's account. Every other habit here depends on separating the two first. It is also, for most businesses, a same-day fix — which makes it the highest-return change available in this whole area.
Will you build an integration for our provider?
Potentially, as a scoped build rather than a promise. Kenya's M-Pesa integration and its eTIMS connection both exist because clients needed them enough to commission them, and the same route is open elsewhere. If a specific provider in your market is what stands between you and a decision, describe the requirement and we will come back with a written scope, timeline and price before you commit to anything. What we will not do is put a logo on a slide and let you assume it is live.
