Mobile money et ERP : intégrer les paiements mobiles dans le cœur de gestion.

Le scénario se répète. Une entreprise de distribution encaisse une part croissante de ses ventes par paiement mobile. Chaque semaine, une personne de la comptabilité télécharge les relevés de chaque portefeuille, les rapproche à la main des factures ouvertes, puis passe une écriture pour le total. Les écarts sont mis en attente. Les frais de l’opérateur sont estimés. Le solde du portefeuille n’apparaît nulle part dans le bilan intermédiaire. À la clôture, ces comptes d’attente deviennent le premier sujet de discussion avec le commissaire aux comptes.

Une réalité du marché, pas un projet innovant

Il faut d’abord changer de regard. Le paiement mobile n’est pas un canal expérimental à traiter dans un projet à part. C’est un moyen de paiement, au même titre que le virement, le chèque ou l’espèce, et il doit être traité dans le cœur de gestion avec la même rigueur : un compte de trésorerie par portefeuille, un journal, des pièces justificatives, un rapprochement périodique. Tant que l’ERP ne le voit pas, l’entreprise pilote sa trésorerie sur une image partielle.

Les flux à intégrer

Encaissements clients. Le client paie une facture, un acompte ou un achat au comptant depuis son téléphone. L’ERP doit recevoir la transaction avec sa référence, l’associer à la facture ou au client, lettrer le compte et enregistrer les frais. Le point délicat est l’identification : un paiement mobile arrive avec un numéro de téléphone et un montant, rarement avec un numéro de facture. Le projet doit donc concevoir la référence de paiement, la communiquer au client et la lire à la réception. Sans cela, le lettrage restera manuel.

Paiements fournisseurs et salariés. Dans l’autre sens, l’entreprise règle des fournisseurs, des transporteurs, des journaliers ou des salariés par paiement mobile, souvent en masse. L’ERP doit générer l’ordre de paiement à partir des factures validées ou de la paie, le transmettre, recevoir la confirmation ou le rejet, et comptabiliser le tout ligne par ligne. Ici, le sujet n’est plus l’identification mais le contrôle : qui valide la liste, qui la transmet, et comment un rejet est traité.

Rapprochement et comptabilisation SYSCOHADA

Un portefeuille de paiement mobile est un compte de trésorerie. Il se suit et se rapproche comme un compte bancaire. Le rapprochement confronte le relevé de l’opérateur aux écritures de l’ERP, transaction par transaction, et isole les écarts : paiements reçus non identifiés, paiements émis non confirmés, frais, annulations. Dans le SYSCOHADA révisé, ces opérations trouvent leur place dans les comptes de trésorerie et de charges appropriés, avec une pièce par transaction et non une écriture globale. Ce qui change avec une intégration réelle : le relevé n’est plus un fichier téléchargé, c’est un flux reçu par le système, et le rapprochement devient une exception à traiter plutôt qu’une tâche hebdomadaire.

Cette discipline a une conséquence directe sur la clôture. Quand chaque paiement mobile est comptabilisé à la transaction, lettré et rapproché, les comptes d’attente se vident et la trésorerie du bilan reflète l’argent réellement disponible, portefeuilles compris. Nous en parlons dans notre point de vue sur la clôture SYSCOHADA : un compte d’attente qui gonfle chaque mois est un flux que le système ne sait pas traiter.

Un portefeuille mobile est un compte de trésorerie. Tant que l’ERP ne le voit pas, l’entreprise pilote son argent sur une image partielle.

Intégrer par API, pas par fichier

Les opérateurs de paiement mobile exposent des interfaces qui permettent d’initier un paiement, d’en recevoir la notification et d’interroger un solde ou un historique. C’est sur ces interfaces qu’une intégration durable se construit, pas sur des exports téléchargés. L’architecture dépend du cœur de gestion. Avec SAP S/4HANA, l’intégration passe par SAP BTP, qui porte les connecteurs, la transformation des messages et la supervision, en gardant le cœur propre de tout développement spécifique. Quand l’entreprise a aussi Salesforce, MuleSoft joue ce rôle de couche d’intégration commune entre le CRM, l’ERP et les opérateurs. Avec Odoo, des connecteurs existent pour les principaux opérateurs de la sous-région ; ils doivent être évalués sur leur maintenance et leur couverture avant d’être retenus.

Quelle que soit la plateforme, trois règles. Une couche d’intégration séparée du cœur, pour absorber les changements d’interface des opérateurs sans toucher à l’ERP. Une supervision des flux, pour voir un paiement bloqué avant que le client ne réclame. Et une gestion des cas d’erreur conçue dès le départ : délai d’attente, rejet, doublon, remboursement.

Contrôle interne et fraude

Le paiement mobile est rapide et irréversible. C’est sa force commerciale et son risque de contrôle. Les schémas de fraude que nous voyons sont simples : un numéro de téléphone bénéficiaire modifié dans une fiche fournisseur, un paiement de salaire dédoublé, un encaissement détourné vers un portefeuille personnel, un remboursement fictif. Aucun ne demande de compétence technique. Tous exploitent une absence de séparation des tâches ou de traçabilité.

L’intégration dans l’ERP est justement ce qui permet d’y répondre. Les numéros bénéficiaires deviennent des données de référentiel, avec une validation à quatre yeux à chaque modification. Les paiements de masse suivent un circuit de validation, avec des plafonds par personne et par jour. Chaque transaction porte son auteur, sa date et sa pièce. Les portefeuilles sont rapprochés par une personne qui ne les manipule pas. Et les alertes, montant inhabituel, bénéficiaire nouveau, paiement hors horaires, sortent du système au lieu de dépendre d’une vigilance individuelle. Notre offre sécurité & risques IT aborde ces contrôles comme une partie du projet d’intégration, pas comme un audit après coup.

Données personnelles

Un numéro de téléphone associé à un paiement est une donnée à caractère personnel. Les flux de paiement mobile, entrants comme sortants, constituent un traitement au sens de la loi n° 2008-12, à déclarer auprès de la CDP selon les formalités applicables, avec une finalité, une durée de conservation et des règles d’accès. Les journaux de transactions, utiles au contrôle, doivent être protégés au même titre que la paie. Nous développons cette question dans notre point de vue sur la conformité CDP dès le cadrage.

Ce que nous recommandons

• Traiter le paiement mobile comme un moyen de paiement du cœur de gestion, avec un compte de trésorerie par portefeuille et une pièce par transaction.
• Concevoir la référence de paiement avant l’intégration : c’est elle qui rend le lettrage automatique.
• Intégrer par API, à travers une couche dédiée : SAP BTP, MuleSoft ou connecteurs Odoo, jamais en développement direct dans le cœur.
• Rapprocher chaque jour, par exception, et ne laisser aucun compte d’attente vivre au-delà du mois.
• Mettre en place la séparation des tâches sur les bénéficiaires, les validations et les rapprochements, avec des alertes portées par le système.
• Déclarer le traitement et protéger les données de paiement comme des données sensibles.

Le paiement mobile est déjà dans votre chiffre d’affaires. La seule question est de savoir s’il est aussi dans votre système, ou s’il vit dans un tableur, entre la trésorerie réelle et la trésorerie comptable. C’est un chantier court, à la croisée de notre expertise finance et de nos travaux d’intégration et d’API, et l’un de ceux dont l’effet se voit dès la clôture suivante.