Mobile Money Shortage Case Files: What Actually Goes Wrong
These are not generic “tips.” They are anonymized failure patterns encountered during real operating, reconciliation and testing work. New cases are added when field use or technical QA exposes a control lesson worth preserving.
Why these cases matter
Generic mobile-money advice says “track your cash and float.” These case files go deeper: they show how a business can appear balanced while the wrong bucket, timing, direction or evidence trail creates a hidden shortage.
The recurring lesson is that a shortage should be located before it is blamed. Physical cash, provider value, settlement receivables, customer receivables, staff liabilities, fees, reversals and FX movements are different things. When they are mixed, the owner loses the trail.
Cash Went Out, but Provider Settlement Had Not Arrived
Symptom: Physical cash fell, yet the system made provider/platform value look available too early.
Control lesson: Use a provider receivable bridge: cash out now, receivable up now; provider balance rises only when settlement is actually received.
Read case file →The Business Paid LEC, but the Customer Had Not Paid Yet
Symptom: The records showed physical cash received even though the customer still owed the business.
Control lesson: Reduce the actual funding account, increase customer receivable, and record physical cash only when the customer pays.
Read case file →The Fee Was Real, but the Asset Was Counted Twice
Symptom: Profit and closing assets looked higher than the value actually held in cash or platform balances.
Control lesson: Track where the fee physically sits and classify the revenue separately; do not add fee-income accounts into asset reconciliation.
Read case file →A Reversal Fixed the Number but Destroyed the Evidence
Symptom: The final balance changed, but nobody could reconstruct what the original transaction was or why it was corrected.
Control lesson: Never erase the original event; link the reversal, document scope and reason, and require owner review for split reversals.
Read case file →Business Value Left for Staff, but the Ledger Treated It Like Normal Trade
Symptom: Cash or float left the business, but the transaction did not create a clear staff liability or approval trail.
Control lesson: Separate approved staff transfer, staff-owes-business and unauthorized transfer categories; repayment clears the staff receivable.
Read case file →The Owner Added Float and the Shortage Seemed to Disappear
Symptom: End-of-day balances looked acceptable after new owner value was added, but the earlier unexplained gap was never resolved.
Control lesson: Record every float addition/removal with source, destination, amount, time and reference so new money cannot erase the shortage trail.
Read case file →One Currency Looked Over, the Other Looked Short
Symptom: USD and LRD moved in opposite directions from what the transaction description implied.
Control lesson: Define the transaction from the business perspective: buy USD means receive USD/pay LRD; sell USD means give USD/receive LRD.
Read case file →The Money Moved, but the Proof Was Missing
Symptom: A high-risk transaction affected cash or float, but the reference/receipt needed to verify it was absent.
Control lesson: High-risk value movement should remain an open exception until supporting reference/evidence is captured or owner-reviewed.
Read case file →Physical Cash Was Correct, but the Wallet Was Short
Symptom: The cash drawer matched expectation while one provider/platform balance did not.
Control lesson: Never accept an overall cash total as proof that each provider bucket reconciles.
Read case file →The Total Drawer Balanced, but One Service Was Still Wrong
Symptom: Combined cash looked acceptable even though one service/provider position could not be explained.
Control lesson: Use one real cash drawer total, but reconcile each provider/float/receivable/fee bucket separately so one service cannot hide another.
Read case file →One Transaction Hit Both Money In and Money Out
Symptom: A single transaction created movements on both sides when only one cash direction and one corresponding platform direction were valid.
Control lesson: Every transaction type needs an explicit effect map; the register should not guess or duplicate both directions.
Read case file →Credit Hit the Business Platform, but There Was No Correct Transaction Type
Symptom: A real provider/Xpress/Ecobank credit arrived, but the control system rejected the entry unless it was forced into “Other” with a note.
Control lesson: Record platform credit as a one-sided increase to the actual platform account, backed by a statement/reference. Do not turn it into sales, customer debt collection or a fake cash movement.
Read case file →Float Changed During the Day, but the Transaction Type Could Not Explain Why
Symptom: Float was added or removed during operations, but the transaction list no longer had a proper float type, so the movement risked being recorded under “Other.”
Control lesson: Separate external float added/removed from internal transfers. Preserve the pre-injection shortage so new owner money cannot erase an earlier variance.
Read case file →Airtime Was Sold, Cash Increased, but the Vendor Balance Was Invisible
Symptom: Airtime sales could be recorded as generic income, but the prepaid airtime/vendor value being consumed was not reconciled as its own balance.
Control lesson: Record customer cash in and reduce the Airtime Vendor Balance by the principal; keep any fee/commission classification separate.
Read case file →Remittance Payout, Platform Credit and Provider Settlement Were Being Mixed Together
Symptom: A remittance “received/out” entry could move the wrong side because payout, immediate platform credit and later provider settlement were not clearly separated.
Control lesson: Separate customer send, immediate-credit payout, settlement receivable and later settlement receipt. Provider settlement received must never create a second physical-cash movement.
Read case file →Formula Audit Case: The Shortage Flag Was Reducing Expected Cash
Symptom: Recording a cash-shortage flag could reduce expected cash by the same amount as the observed shortage, making the drawer appear closer to balanced.
Control lesson: A shortage flag documents the variance; it must not alter expected cash. Any confirmed write-off, recovery or correction is a separate owner-controlled event.
Read case file →New reconciliation control cases
A POS withdrawal failed, but the debit still needed resolution
Why “failed” is not a final accounting status.
One real transaction was entered twice
How duplicate posting can create a false expected shortage.
Cash moved into platform float but looked like income
Why internal movement needs two matched financial legs.
The cause was known, but the money was still missing
Why explained and resolved must remain separate statuses.