In Cameroon, Mobile Money now weighs heavily in an SME’s cash flow. Many businesses receive and disburse daily via MTN MoMo or Orange Money — yet the booking remains artisanal: flows often land in bulk in account 512 (bank) or worse, are recorded as cash 53.

Here is how to properly structure your MoMo accounts in a SYSCOHADA chart.

Why it is NOT a bank account

Natural temptation: create a 512### sub-account “Mobile Money MTN” and dump movements into it. Wrong.

The 512 account designates a bank current account in the strict sense: account holder = the company, opened at a regulated banking institution, monthly statement, IBAN. Your MoMo wallet is none of that.

The MoMo wallet is an electronic money deposit held by a payment institution (MTN MFS Africa, Orange Money), not a bank. From an accounting standpoint, it is an internal transfer pending or liquidity transit account, closer to 581 or 580.

The proposed pattern

Here is the structure we apply in the SMEs we support:

581001 — Internal transfers — MTN MoMo CM (XAF)
581002 — Internal transfers — Orange Money CM (XAF)

For each operator, as a sub-account:
58100110 — MoMo MTN — Main merchant wallet (number 67xxxxxxx)
58100120 — MoMo MTN — Secondary merchant wallet if needed

Account 581 is a transit account on the liability side of the SYSCOHADA chart. It records flows awaiting reclassification.

The typical accounting flow

Customer payment via MoMo

  1. Customer pays 50,000 XAF via MTN MoMo to the merchant wallet.
  2. Webhook notification received (cf. apps/api/src/modules/mobile-money/).
  3. Automatic entry:
    • Debit 581001 (MoMo wallet) — 50,000
    • Credit 411xxxxxx (Customer) — 50,000
  4. The wallet is not the bank. The balance is latent.

Transfer MoMo → bank

When the SME transfers the wallet balance to its BICEC or Afriland account:

  1. MTN fees applied (typically 1% of transfer).
  2. Entry:
    • Debit 512100 (BICEC) — 49,500
    • Debit 627100 (Banking services) — 500
    • Credit 581001 (MoMo wallet) — 50,000
  3. Account 581001 is now at zero.

Pitfalls to avoid

Pitfall 1 — No automatic reconciliation

If the SME has 80 MoMo receipts per month and no automatic reconciliation, each MoMo→bank transfer becomes a puzzle: which of the 80 transactions corresponds to this 247,500 XAF payment?

Solution: import the MoMo wallet statement (or direct webhook integration)

  • reconcile 581 at the operation level.

Pitfall 2 — Confusing internal transfers with customer flows

If a salesperson receives a personal payment on their Pro MoMo and then transfers it to the company, it is not a direct customer receipt — it is two distinct operations: (a) salesperson advance, (b) company reimbursement. To be booked separately, otherwise the real customer’s 411 ledger is wrong.

Pitfall 3 — MoMo fees booked under 512

Mobile Money operator fees are not bank fees in the classical sense. Account 6271 (Bank fees) is usable but unclear. Prefer a dedicated analytics tag (“Mobile payment services”) to rationally arbitrate operator vs bank cost.

Webhook and integrity

SynkriaOps receives MoMo notifications via HMAC-SHA256 webhook + AES-256-GCM secret encryption (cf. apps/api/src/modules/mobile-money/services/webhook-signature.service.ts). The sender IP is filtered by CIDR allowlist to prevent external replays.

The automatic 581↔411 reconciliation triggers on receipt of an authenticated notification — the entry is booked without human intervention but traceable (audit log + chained hash).

Updated with the actual SynkriaOps code state as of 2026-05-08. MTN CM coverage is operational; Orange CM is pending CEMAC sandbox credentials from the operator side.