Mobile money and ERP: integrating mobile payments into the core business system.

The scenario repeats itself. A distribution company collects a growing share of its sales through mobile payment. Every week, someone in accounting downloads the statements from each wallet, matches them by hand against open invoices, then posts one entry for the total. Discrepancies are put in suspense. The operator’s fees are estimated. The wallet balance appears nowhere in the interim balance sheet. At the close, these suspense accounts become the first topic of discussion with the statutory auditor.

A market reality, not an innovation project

The first thing to change is the way of looking at it. Mobile payment is not an experimental channel to be handled in a separate project. It is a means of payment, on the same footing as bank transfer, cheque or cash, and it must be handled in the core business system with the same rigour: one cash account per wallet, a journal, supporting documents, periodic reconciliation. As long as the ERP cannot see it, the company steers its cash on a partial picture.

The flows to integrate

Customer receipts. The customer pays an invoice, a deposit or a cash purchase from their phone. The ERP must receive the transaction with its reference, associate it with the invoice or the customer, clear the account and record the fees. The tricky point is identification: a mobile payment arrives with a phone number and an amount, rarely with an invoice number. The project must therefore design the payment reference, communicate it to the customer and read it on receipt. Without that, clearing will remain manual.

Supplier and payroll payments. In the other direction, the company pays suppliers, carriers, day labourers or employees by mobile payment, often in bulk. The ERP must generate the payment order from approved invoices or from payroll, transmit it, receive the confirmation or rejection, and post everything line by line. Here the subject is no longer identification but control: who approves the list, who transmits it, and how a rejection is handled.

Reconciliation and SYSCOHADA posting

A mobile payment wallet is a cash account. It is tracked and reconciled like a bank account. Reconciliation compares the operator’s statement with the ERP entries, transaction by transaction, and isolates the discrepancies: payments received but unidentified, payments issued but unconfirmed, fees, cancellations. In the revised SYSCOHADA, these operations find their place in the appropriate cash and expense accounts, with one supporting document per transaction and not one global entry. What changes with real integration: the statement is no longer a downloaded file, it is a feed received by the system, and reconciliation becomes an exception to handle rather than a weekly task.

This discipline has a direct consequence on the close. When every mobile payment is posted at transaction level, cleared and reconciled, the suspense accounts empty out and the cash on the balance sheet reflects the money actually available, wallets included. We discuss this in our viewpoint on the SYSCOHADA close: a suspense account that swells every month is a flow the system does not know how to handle.

A mobile wallet is a cash account. As long as the ERP cannot see it, the company steers its money on a partial picture.

Integrate through APIs, not files

Mobile payment operators expose interfaces that allow you to initiate a payment, receive its notification and query a balance or a history. It is on these interfaces that a durable integration is built, not on downloaded exports. The architecture depends on the core business system. With SAP S/4HANA, integration goes through SAP BTP, which carries the connectors, message transformation and supervision, keeping the core clean of any custom development. When the company also has Salesforce, MuleSoft plays this role of common integration layer between the CRM, the ERP and the operators. With Odoo, connectors exist for the main operators in the sub-region; they must be assessed on their maintenance and coverage before being selected.

Whatever the platform, three rules. An integration layer separate from the core, to absorb operators’ interface changes without touching the ERP. Flow supervision, to see a blocked payment before the customer complains. And error handling designed from the outset: timeouts, rejections, duplicates, refunds.

Internal control and fraud

Mobile payment is fast and irreversible. That is its commercial strength and its control risk. The fraud schemes we see are simple: a beneficiary phone number changed in a supplier record, a salary payment duplicated, a receipt diverted to a personal wallet, a fictitious refund. None requires technical skill. All exploit a lack of segregation of duties or traceability.

Integration into the ERP is precisely what makes it possible to respond. Beneficiary numbers become master data, with four-eyes validation of every change. Bulk payments follow an approval workflow, with limits per person and per day. Every transaction carries its author, its date and its supporting document. Wallets are reconciled by someone who does not handle them. And alerts, an unusual amount, a new beneficiary, a payment outside working hours, come out of the system instead of depending on individual vigilance. Our IT security & risk offering treats these controls as part of the integration project, not as an audit after the fact.

Personal data

A phone number associated with a payment is personal data. Mobile payment flows, incoming and outgoing, constitute a processing operation within the meaning of Law No. 2008-12, to be declared to the CDP according to the applicable formalities, with a purpose, a retention period and access rules. Transaction logs, useful for control, must be protected on the same footing as payroll. We develop this question in our viewpoint on CDP compliance from the scoping phase.

What we recommend

• Treat mobile payment as a means of payment of the core business system, with one cash account per wallet and one supporting document per transaction.
• Design the payment reference before the integration: it is what makes clearing automatic.
• Integrate through APIs, via a dedicated layer: SAP BTP, MuleSoft or Odoo connectors, never through direct development in the core.
• Reconcile daily, by exception, and let no suspense account live beyond the month.
• Put segregation of duties in place on beneficiaries, approvals and reconciliations, with alerts carried by the system.
• Declare the processing and protect payment data as sensitive data.

Mobile payment is already in your revenue. The only question is whether it is also in your system, or whether it lives in a spreadsheet, between actual cash and book cash. It is a short workstream, at the crossroads of our finance expertise and our integration and API work, and one of those whose effect is visible from the very next close.