Rembourser un client : les trois pièges qui coûtent de l'argent

C'est le plus banal et le plus cher. Le commerçant clique sur « Rembourser », rien ne semble se passer — la requête part chez le prestataire de paiement et met deux ou trois secondes —, alors il reclique. Deux appels partent, le prestataire les honore tous les deux, et le client reçoit le double. On ne s'en aperçoit pas le jour même : on le découvre au rapprochement bancaire, parfois des semaines plus tard.

La parade n'est pas de désactiver le bouton après le clic : un rechargement de page le réactive, et deux onglets ouverts contournent la protection. Le verrou doit être posé DANS LA BASE, avant l'appel au prestataire : la commande passe en « remboursement en cours », et cet état est vérifié au moment de l'écriture, pas au moment de l'affichage.

La bonne formulation est celle de l'idempotence : appeler dix fois le remboursement doit produire exactement le même résultat qu'un seul appel. C'est cette propriété qu'il faut exiger d'un logiciel, pas « un bouton qui se grise ».

Une facture émise ne se supprime pas et ne se modifie pas : c'est une pièce comptable. Quand une vente est remboursée, la pièce qui l'annule s'appelle un avoir, et elle porte son propre numéro, dans une série continue et sans trou.

Rembourser sans avoir laisse une facture encaissée d'un côté et un mouvement bancaire inverse de l'autre, sans rien qui les relie. Le commerçant s'en sort à la main tant qu'il y a trois cas par an ; à trente, il ne s'en sort plus, et son comptable non plus.

Un logiciel correct crée l'avoir AU MOMENT du remboursement, avec le même détail de lignes et les mêmes taux que la facture d'origine. S'il vous demande de créer l'avoir vous-même, dans un second écran, il vous prépare un oubli.

Rembourser une commande entière est simple : tout repart, taxes comprises. Rembourser une partie ne l'est pas. « Je rembourse 30 € » ne veut rien dire pour la TVA tant qu'on ne sait pas si ces 30 € sont un article à 5,5 %, un article à 20 %, ou des frais de port.

Le cas se produit tout le temps : un client garde deux articles sur trois, ou signale un article abîmé. Si le logiciel demande un MONTANT, il vous fait fabriquer une erreur ; s'il demande QUELLES LIGNES sont remboursées, il calcule la TVA tout seul et l'avoir est juste.

Le second cas des frais de port mérite une décision écrite avant qu'il n'arrive : en cas de rétractation, le vendeur rembourse les frais d'envoi initiaux au tarif standard, mais pas les frais de retour ni le surcoût d'une livraison express choisie par l'acheteur. Un logiciel qui rembourse le port par défaut vous fait perdre de l'argent silencieusement ; un logiciel qui ne le rembourse jamais vous met en faute.

Trois remboursements partiels de 40 € sur une commande de 100 € font 120 €. Chacun paraît légitime pris isolément, et aucun écran ne les additionne. C'est un défaut de conception, pas une erreur humaine.

Le contrôle est simple à énoncer et rarement présent : le total remboursé ne peut jamais dépasser le total réellement encaissé. Il doit être vérifié par le logiciel au moment de l'écriture — refuser vaut mieux que rattraper, et un comptable ne devrait jamais être la dernière ligne de défense d'un logiciel.

Toutes ces règles ont un point commun : elles sont impossibles à tenir de mémoire un vendredi soir de forte activité. Elles appartiennent au logiciel qui tient la commande — celui qui connaît les lignes, les taux, ce qui a déjà été remboursé et ce qui a été encaissé.

Le prestataire de paiement, lui, ne connaît qu'un montant. Rembourser depuis son tableau de bord fonctionne, et laisse le logiciel de gestion ignorant : pas d'avoir, pas de TVA recalculée, pas de plafond vérifié. C'est la manœuvre qui semble la plus rapide et qui coûte le plus cher au moment du bilan.

C'est précisément ce que fait Structure Hub : le remboursement s'y décide, l'avoir s'y crée, la TVA s'y recalcule par ligne, le plafond s'y vérifie, et l'appel au prestataire n'est que la dernière étape — verrouillée avant d'être envoyée.