Encaisser par portefeuille mobile : ce que ça change dans votre caisse
Accepter le paiement par portefeuille mobile est une décision commerciale simple : vos clients l'ont déjà, et ils préfèrent. C'est dans le logiciel que cela se complique, et jamais là où on l'attend.
L'argent n'arrive pas là où vous l'attendez
Un règlement par portefeuille n'entre pas sur votre compte bancaire. Il entre sur un compte chez l'opérateur, d'où vous le transférez ensuite — dans un délai qui n'est pas le vôtre.
Ce sont donc deux comptes de trésorerie, pas un. Un logiciel qui n'en connaît qu'un affiche une trésorerie fausse dans les deux sens : trop basse tant que l'argent est chez l'opérateur, puis comptée deux fois le jour du transfert si le virement est saisi comme une recette au lieu d'un mouvement interne.
Le montant reçu n'est pas le montant dû
Il y a une commission, et selon l'opérateur et le type de compte, elle est prélevée à l'envoi ou à la réception. Dans le second cas, un client qui vous doit 50 000 F vous en fait parvenir un peu moins.
Un logiciel qui ne solde une facture que si « montant reçu = montant dû » ne soldera donc jamais rien, et votre équipe prendra l'habitude de forcer les règlements à la main — ce qui vaut mieux que rien, jusqu'au jour où quelqu'un force le mauvais. Il faut deux choses : une tolérance déclarée, et un compte de charge où la commission se pose. Sinon elle disparaît dans un écart que personne ne sait expliquer en fin d'exercice.
Le SMS n'est pas une preuve
Il arrive en retard, il arrive deux fois, il n'arrive pas. Il peut aussi arriver alors que la transaction a échoué côté opérateur.
Le SMS est une notification, pas un enregistrement. Il sert à déclencher une vérification ; ce qui fait foi est le relevé de l'opérateur. Un logiciel qui enregistre un encaissement à partir d'un SMS recopié à la main enregistre en réalité la bonne foi de la personne qui l'a recopié.
L'identifiant de transaction est la seule clé
C'est le point qui coûte le moins cher et qui rapporte le plus : une contrainte d'unicité sur l'identifiant fourni par l'opérateur.
Sans elle, la même transaction s'enregistre deux fois — une notification renvoyée, une page rechargée, deux personnes qui saisissent le même relevé — et le client se retrouve crédité du double. Vous ne le découvrez pas le jour même : vous le découvrez dans un solde client négatif, six semaines plus tard, sans savoir lequel des deux encaissements est le bon.
Une ligne dans le schéma de la base. Elle vaut tous les contrôles de saisie qu'on pourrait écrire à sa place.
Le client ne paie pas depuis le numéro que vous connaissez
Il paie depuis le téléphone de son épouse, depuis un kiosque, depuis le numéro d'un cousin. Rapprocher automatiquement sur le seul numéro d'expéditeur produit donc des affectations fausses, qui sont pires que des affectations manquantes : elles ont l'air justes.
La référence saisie par le payeur est le seul lien fiable. Encore faut-il qu'elle soit conçue pour être tapée sur un clavier de téléphone : courte, sans caractères qu'on confond — le zéro et le O, le 1 et le I — et, si elle dépasse cinq ou six signes, avec une clé de contrôle qui rejette une faute de frappe au lieu de l'affecter au mauvais client.
L'écran qui manque toujours
« Règlements reçus, non affectés. » Une liste, avec le montant, la date, l'identifiant, et un bouton pour rattacher à une facture.
S'il n'existe pas, le rapprochement se fait quand même : dans un cahier, sur un téléphone, dans la tête de la personne qui tient la caisse. Et ce cahier devient la vérité, pendant que le logiciel devient une formalité.
La question à poser
À qui vous vend un logiciel, ou à qui l'a écrit :
Combien avons-nous encaissé hier par portefeuille mobile, et à quelles factures cela correspond-il ?
Si la réponse demande d'ouvrir l'application de l'opérateur à côté, le rapprochement n'est pas dans le logiciel — il est dans quelqu'un.