How to reconcile mobile money payments
Mobile money is an excellent way to receive money and a difficult one to reconcile. The difficulty is structural rather than a defect: the rail was designed to move value between people, not to carry accounting metadata.
The names differ by market — M-PESA in Kenya and Tanzania, MTN MoMo and Airtel Money across much of Africa, GCash in the Philippines, bKash in Bangladesh, and the wallet layered over UPI or Pix elsewhere — and the reconciliation problem is close to identical in all of them.
This is a practical account of what you get, what goes wrong, and what actually reduces the problem.
What a transaction gives you
Broadly: an amount, a timestamp, a receipt number, the paying phone number or wallet ID, and the name registered to that line. Where a business short code, merchant code or till is used there is usually an account reference field the payer types themselves.
Two things to note. The registered name is the owner of the line, which is not necessarily the person paying. And the reference field is free text filled in by a human on a phone keypad, which is exactly as reliable as that sounds.
The five failure modes
In rough order of frequency.
- No reference at all. The payer skipped the field or the payment came through a channel without one.
- A reference that identifies nothing — a first name, a nickname, a unit number that was renumbered.
- An unregistered paying number. The member paid from a spouse's, a colleague's or a relative's phone.
- A round amount that matches several outstanding obligations equally well.
- A missing or duplicated callback: the payer has a confirmation message your system never received, or the same money appears twice under different receipt numbers.
Matching in layers
Effective matching applies rules in order of certainty and stops as soon as one is decisive. Anything that survives all the layers is a review item, not a guess.
- Exact reference match against your own scheme. Decisive; allocate automatically.
- Registered paying number for a party with an outstanding obligation. Strong, particularly with an amount match.
- Exact amount against a single outstanding obligation for a plausible party. Suggestive, not decisive.
- Payer history: this number has paid for this account before. Often the deciding factor.
- Everything else: propose with evidence and a confidence score, and let a person decide.
Reducing the rate at source
Matching well is the second-best intervention. The first is receiving fewer unmatchable payments, and three things move that number materially.
- A reference scheme people can actually use: short, unambiguous, printed on every statement and message, and ideally not requiring them to remember it.
- Registered paying numbers captured deliberately — including the spouse's, the employer's and the relative's — rather than learned only after a failure.
- Third-party payers modeled as real records, so a company or a parent has an identity the rail can be matched against.
Two things to check independently
First, compare against a second source where you have one. A transaction on a statement with no corresponding callback is a finding worth a value, not a silence.
Second, detect duplicates on the shape of the payment — same payer, same amount, same window — rather than only on the receipt number. The same money genuinely can arrive twice with two identifiers, and receipt-number-only detection will not catch it.