Mobile money has changed the distance between a customer and a business account. A customer can pay from a phone, a field officer can receive a disbursement, and a branch can operate without waiting for a bank transfer to clear. The operating challenge is what comes after the notification: identifying the customer, posting the right amount, separating fees and taxes, and proving that the money was reconciled.

The GSMA’s 2025 industry report records the continued scale of mobile money across registered accounts, active accounts, transaction value, and merchant payments. Its regional analysis also notes the importance of East Africa within mobile-money activity. The exact product, settlement, and regulatory conditions still vary by country and provider, so integration decisions must be tested against the provider’s current documentation.

Treat the payment as an event with evidence

A useful ERP integration does more than display a successful callback. It should preserve a chain of evidence:

  1. the original customer reference or invoice;
  2. the provider transaction identifier;
  3. the amount, currency, fees, and settlement account;
  4. the time received and the integration status;
  5. the ERP posting or allocation result; and
  6. the reconciliation and exception decision.

MTN’s public MoMo documentation describes collections, disbursements, request-to-pay, payment status, and transfer capabilities. Safaricom’s developer portal provides the entry point for M-Pesa APIs. These are integration surfaces, not a guarantee that every endpoint or product is enabled in every market. Confirm the commercial account, country, credentials, limits, and support route before committing the workflow.

Four workflows worth connecting first

Customer collections

Create a payment request or receive a payment notification linked to a customer, invoice, order, or account number. Put unmatched payments into a review queue instead of forcing an operator to guess. A suspense or unapplied account can make the exception visible while the team obtains the missing reference.

Supplier and field disbursements

Disbursements should begin with an approved batch, not an operator copying phone numbers into a portal. The ERP should show who prepared the batch, who approved it, what was sent, what failed, and what was returned. A failed transaction must not look like a completed payment merely because the request was accepted.

Branch and agent reconciliation

Compare the provider statement, the ERP control account, the branch record, and the bank settlement. Differences should be classified: timing, provider fee, duplicate, reversal, wrong account, missing reference, or suspected fraud. Classification turns a vague mismatch into work that can be assigned and closed.

Tax and invoice evidence

In Uganda, the Uganda Revenue Authority describes EFRIS as the electronic fiscal-receipting and invoicing system for the relevant taxpayers and provides integration information. A mobile-money payment does not, by itself, prove that the required invoice or fiscal document was issued. The transaction flow must define when the invoice is created, when it is sent, and how the payment is matched.

Design for the messy cases

The best test cases are ordinary problems:

  • the same customer pays twice;
  • a payment arrives without an invoice reference;
  • a callback is repeated;
  • the provider confirms the request but settlement is delayed;
  • a customer receives a reversal;
  • the amount is in the wrong currency; or
  • the service is unavailable while a cashier is serving customers.

The integration should be idempotent: a repeated provider message must not create a second posting. It should also retain raw provider evidence and a human-readable status. If the connection fails, the fallback must be explicit: queue for retry, record a controlled offline receipt, or route to a supervisor. Do not silently mark the transaction as paid.

Keep the ledger honest

Payment value, provider fees, tax, and settlement differences should be represented separately where the accounting policy requires it. Reconciliation should be a process with an owner and review date, not a green icon on a dashboard. Posted corrections should be traceable reversals or adjustment entries, not edited history.

The Bank of Uganda’s December 2025 financial stability review illustrates why transaction volume and value deserve operational attention: mobile-money activity is large enough that small control weaknesses can create a material workload. The specific thresholds and account treatments depend on the entity’s policy and jurisdiction; the practical lesson is to make exceptions visible early.

What an ERP buyer should ask

  • Which providers and countries are supported today?
  • Are collections, disbursements, status queries, reversals, and statements all covered?
  • How are duplicate callbacks rejected?
  • Can a finance reviewer trace a ledger entry back to the provider transaction?
  • How are fees, taxes, timing differences, and settlement accounts handled?
  • What is the offline or degraded-mode procedure?
  • Who owns credentials, API certificates, rotation, and incident response?

Kraal Code’s product direction includes mobile-money and tax-system integration for African organisations. Treat the exact provider and country matrix as a deployment decision: verify the supported endpoint, test the reconciliation path, and obtain finance-owner sign-off before switching on live payments.

Procurement, sales, and payroll examples

In procurement, a field team may request a payment to a supplier or agent after an approved purchase. The ERP should carry the purchase reference, beneficiary details, amount, approval, provider response, and settlement evidence. If the supplier changes a phone number, the change should require the same review as a bank-account change; a payment API should not make a weak master-data process faster.

In sales, a customer may pay before the invoice reference is available. The business can record the receipt in an unapplied queue, request the missing information, and allocate it after review. This keeps the customer relationship moving without pretending that the receivable is already settled.

In payroll or field allowances, the batch should be approved against a worker or project list, with duplicate beneficiaries and unusual amounts flagged for review. Personal-data handling, consent, access, and retention are separate responsibilities. A mobile-money connector does not remove them.

Reconciliation as a daily operating view

The reconciliation screen should answer five questions without opening several unrelated files:

  1. Which provider items arrived since the last review?
  2. Which items were matched automatically, and by what reference?
  3. Which items need a person to decide?
  4. Which ERP postings are waiting for settlement?
  5. Which differences are older than the agreed review window?

Link the provider statement, ERP transaction, source document, reviewer, and resolution note. Keep raw callbacks for technical investigation, but give finance a clear explanation in business terms. A reliable integration is one in which the operator can prove both the successful payment and the rejected or reversed payment.

Kraal Code’s sales capability, accounting capability, and security guidance are relevant starting points for reviewing the wider workflow around a mobile-money connection.

A safe integration checklist

Before enabling production credentials, document the provider account, countries, supported products, callback authentication, retry policy, duplicate key, settlement account, exception owner, statement format, and incident contact. Test a success, timeout, duplicate, reversal, wrong reference, wrong currency, partial batch, and provider outage. Have finance sign off the posting and reconciliation results; have the system owner sign off the operational alerts and credential rotation.

The outcome should be a controlled cash process with a provider connection, not a payment button that creates an unexplained balance. That distinction matters most when the transaction count grows beyond what a person can review from a portal history.

Review the integration after the first reporting period. Compare provider totals with ERP totals, inspect unresolved items by age, confirm that reversals were handled correctly, and record any manual workarounds. The review should produce a small change list with an owner and a date rather than an assumption that the first successful payment proves the process is finished.