Reconciliation is the moment when you stop trusting the story and start comparing two records: what the mobile money operator says about your number, and what your own books say about the same money. It matters because a transfer that was initiated is not a transfer that landed.

The good news is that most of the work is already done for you. When a payer confirms on their phone, the platform receives the operator’s answer and settles the payment by itself — no one has to click anything for a mobile money sale to reach your books. Your job is the exception queue: the rows where the operator has not answered, answered late, or answered with a number that does not match what you expected.

Two screens hold everything you need. Finance > Payments is your fee ledger and the place to check what you wrote down at the counter. Finance > Orders is where the operator’s answers are recorded, with the message and references that come with them.

Confirmations arrive on their own

When a payer approves the request on their phone, the operator’s answer is delivered to the platform and the payment settles without anyone touching Ekati. This is why a busy Saturday morning does not generate a backlog of work for your team: the ordinary case is already handled.

Pending is a normal state, not an error

A row that has been pending for a few minutes is a payer who has not finished on their handset. A row pending for a full day is a different matter: the request was probably abandoned, the phone number was mistyped, or the customer’s balance was insufficient. That is the moment to phone.

The provider reference is the operator’s word. Every transaction carries the operator’s own reference alongside the platform’s. When a parent disputes a payment, the pair of references is what settles the conversation: one identifies the transaction to the operator, the other identifies it in your books.

The history is the audit trail. Every status change on an order is dated and kept, with a note when one was written. If a customer asks why their course has not appeared, that history answers the question in order, without anyone having to remember what happened last week.

The operator has not answered

Do not record anything on a promise. Leave the row pending, note the reference and the time you tried, and ask the payer to retry from their own account. Once the answer arrives, the payment settles by itself.

The transfer arrived but nobody recorded it

This is the most common real case, and the fix is straightforward: once the money is in your hands, record the payment at the counter on the learner’s file, with the operator reference and a note. The learner gets a receipt, the fee is cleared, and your books match the bank.

The same money was sent twice. Two transactions on one order mean the payer pressed the button twice. Read both provider references before acting: if only one payment reached you, record the one that did and keep the other reference in your notes for the refund conversation. Never record the same amount twice just because two requests exist.

Somebody says they paid and you cannot find it. Search the Payments list and the Orders list by that reference before concluding anything. It is usually one of three things: a payment recorded against another learner in the same family, a transfer that is still in flight, or a different mobile money number than the one on file. The first is fixed with a correcting entry, the second resolves itself, and the third is a conversation with the family.