Why Mobile Money reconciliation eats your week
Most Cameroonian businesses accept MTN MoMo and Orange Money but reconcile both by hand. Here is what that costs, and what fixing it actually involves.
Ask a retailer in Douala how they take payment and the answer is usually the same. MTN Mobile Money, Orange Money, cash, and a bank transfer for the bigger accounts. Four rails. Four different records of the same day of trading.
Then ask how they know what came in. That is where it gets quiet.
The manual loop
The typical process looks like this. Someone opens the MTN statement. Someone opens the Orange statement. Someone opens the till book or the spreadsheet. Then they go line by line, matching a payment to an order.
It works. It also takes hours, and it scales badly. A shop doing 40 transactions a day can hold this together. At 300 a day it breaks, and it breaks in a specific way: you stop reconciling daily and start reconciling weekly. Once you are a week behind, a missing payment is no longer something you can chase. The customer has moved on and so has the evidence.
Three costs follow from this.
Money you never collect. A failed transfer that nobody noticed is revenue you earned and did not receive. In a business with thin margins, a handful of these a month is the margin.
Decisions made on stale numbers. If today's real position is only known next Friday, then every stock and staffing decision this week is a guess.
A person doing machine work. Reconciliation is pattern matching. It is the exact shape of task software is good at and people are expensive at.
Why it stays broken
The honest answer is that the fix is not obvious from the inside.
MTN and Orange both have APIs. They do not have the same API, the same identifiers, or the same idea of what a transaction record looks like. One returns a reference the customer sees, the other returns one they do not. Timestamps differ in timezone handling. Fees are deducted at different points in the flow.
So the work is not "connect the payment API". The work is building one internal record of a payment that both providers can map onto, and being strict about it. That is a day of thinking and a week of plumbing, and it is nobody's job when everyone is busy running the business.
What fixing it looks like
The approach we recommend is boring, which is the point.
- One transaction table, provider agnostic. Every payment becomes a row with your reference, the provider reference, the amount in XAF, the fee, the status, and the timestamp normalised to one timezone. Providers change. The table does not.
- Pull on a schedule, not on demand. A job fetches both providers every few minutes and writes to that table. If a provider is down, the job retries. Nobody clicks anything.
- Match automatically, escalate the rest. Most payments match on reference and amount. The ones that do not go to a short exceptions list. A person looks at the exceptions, not at everything.
- Alert on the gap, not the volume. Nobody reads a dashboard daily. A message when unmatched payments cross a threshold gets read.
The aim is not magic. It is to turn reconciliation from a line by line pass over everything into a short review of only what did not match.
The part worth saying plainly
You do not need a full platform rebuild to get this. Most of the businesses we talk to assume the fix is a new system that replaces everything they run. It usually is not. It is a payments layer that sits underneath what you already use, and a discipline about how a payment gets recorded.
If reconciliation is currently a person and a spreadsheet in your business, that is the cheapest thing on your roadmap to fix, and the one that pays for itself fastest.
This is the layer we build for retailers, startups, and growing enterprises across Cameroon. If you want to talk through what it would take in your setup, get in touch.