Un vendeur demande pourquoi son reversement est inférieur de 327 euros aux commandes livrées. Le support additionne paiements, commissions et remboursements dans trois exports, puis découvre une retenue créée lors d’un litige. Personne ne sait quel mouvement a consommé la réserve ni si le solde affiché avant versement était juste.
Le problème vient d’une comptabilité implicite : chaque service modifie son montant courant et conserve une explication partielle. Une reprise manuelle corrige l’écran vendeur, mais le PSP, la facture et le prochain payout restent différents. Le même écart revient au cycle suivant avec une charge support accrue.
Le vrai enjeu du ledger d’une marketplace opérateur consiste à enregistrer chaque fait financier avec une contrepartie, sans confondre l’argent reçu, dû, disponible ou déjà versé. Contre-intuitivement, le ledger ne remplace pas la comptabilité générale : il rend le sous-livre transactionnel réconciliable.
Vous allez comprendre comment modéliser comptes, écritures, événements et corrections. Paiement, commission, taxe, remboursement, réserve et reversement produisent des mouvements équilibrés, immuables et corrélés à leur source. Chaque solde devient reconstructible à une date précise.
Donner un rôle au ledger
Séparer fait financier et vue métier
Le ledger conserve les transferts de valeur ; la commande conserve produits et statuts ; le PSP exécute les opérations de paiement ; la comptabilité produit les états légaux. Ces systèmes se référencent sans dupliquer leur responsabilité. Un changement de libellé commande ne réécrit aucune écriture.
Les vues vendeur, opérateur et finance lisent le même sous-livre avec des regroupements différents. Le solde disponible est une requête sur des comptes et états, pas un champ modifié par plusieurs services. La définition reste versionnée et testée.
Définir les invariants avant les écrans
Chaque transaction est équilibrée dans une devise, possède une source unique et ne change plus après validation. Les montants utilisent l’unité monétaire mineure ; aucun flottant n’entre dans le calcul. Un événement métier ne produit qu’un lot d’écritures grâce à l’idempotence.
Le registre des invariants nomme owner, règle, seuil et réaction. Si un lot est déséquilibré d’un centime, alors il est refusé avant publication. Le support ne reçoit jamais le droit d’altérer une ligne pour fermer un dossier.
Définir le plan de comptes
Représenter les parties et les états
Des comptes distincts représentent fonds PSP, créance vendeur, revenu de commission, taxe collectée, remboursement à payer, réserve et payout en transit. Ils appartiennent à une entité et une devise. Leur nature détermine le sens d’augmentation, jamais le signe affiché.
Le plan reste assez fin pour expliquer, assez stable pour réconcilier. Créer un compte par commande rend l’exploitation lourde ; tout réunir par vendeur masque les états. Les dimensions commande, sous-commande et événement complètent les comptes sans les multiplier inutilement.
Un catalogue de comptes indique libellé, nature, entité autorisée, devise, sens normal et événements qui peuvent l’utiliser. Son évolution passe une migration explicite. Un compte retiré reste consultable pour les périodes historiques et refuse les nouveaux bookings après sa date de fermeture.
Borner les devises et entités juridiques
Une écriture ne s’équilibre jamais entre euros et livres. Le change produit deux lots reliés par une opération de conversion et leurs montants de référence. La plateforme conserve taux, fournisseur, heure et frais au moment où la valeur change réellement.
Chaque entité juridique possède son périmètre. Un solde vendeur dû par une filiale française ne compense pas silencieusement une dette portée par une société britannique. Les transferts inter-entités deviennent des opérations identifiées et réconciliables.
Produire des écritures équilibrées
Transformer un fait en lot atomique
Un paiement capturé de 120 euros crédite les fonds contrôlés et reconnaît les obligations correspondantes. Le lot contient lignes, compte, montant, devise, direction et dimensions. Toutes les lignes sont validées puis publiées dans une seule transaction.
L’entrée porte type d’événement, identifiant, version et données nécessaires ; la sortie fournit identifiant de lot et écritures. Le contrat refuse champ absent, compte fermé et période verrouillée. La journalisation relie événement, règle de booking et commit applicatif.
Rendre le booking déterministe
Une même version de règle appliquée au même événement produit les mêmes lignes. Les arrondis sont définis par composant et la somme résiduelle rejoint un compte identifié. La génération ne dépend ni de l’ordre d’une liste ni de l’heure du serveur.
Scénario de recette : deux consumers reçoivent simultanément la même capture. Si les clés d’idempotence sont identiques, alors un seul lot est validé et l’autre retrouve son identifiant. Le solde ne double jamais malgré le retry.
Suivre le cycle du paiement
Distinguer autorisation, capture et règlement
L’autorisation réserve une capacité chez le payeur ; elle ne constitue pas encore toujours un fonds contrôlé. La capture crée une créance sur le PSP ; le settlement confirme le montant reçu sur le compte bancaire. Le ledger sépare ces étapes et leurs délais.
Une capture partielle ou multiple référence l’autorisation sans dépasser son plafond. L’expiration libère le reste sans inventer un remboursement. La commande affiche une synthèse, tandis que la finance peut descendre jusqu’à chaque opération PSP.
La chronologie distingue date de l’action, date effective du PSP et date de règlement bancaire. Ces repères expliquent pourquoi un solde de commande, une balance de fonds et un relevé bancaire peuvent se rejoindre à des jours différents. Les rapports en transit les rapprochent sans les fusionner.
Gérer échec et événement tardif
Un webhook peut arriver en retard, être dupliqué ou contredire un statut local. Le connecteur garde version externe, date effective et corrélation. La machine à états décide si un nouveau fait doit produire des écritures ou seulement une alerte.
Par exemple, si un settlement arrive après l’annulation d’une capture supposée échouée, alors les fonds rejoignent un compte d’exception et une file finance. Le système ne les attribue pas au vendeur avant réconciliation de la cause.
Calculer commissions et taxes
Versionner la règle commerciale
La commission peut dépendre de catégorie, vendeur, contrat, promotion, montant et date. La commande capture la version applicable. Le booking calcule base, taux, minimum, plafond et taxes, puis conserve le détail avec les écritures.
Une modification de contrat s’applique aux commandes futures selon une date d’effet. Elle ne recalcule pas les ventes antérieures. Une dérogation possède approbateur et durée ; finance peut comparer revenu attendu et revenu reconnu par version.
Répartir arrondis et fiscalité
Taxe sur commission, taxe sur vente et retenue ne sont pas interchangeables. Chaque composant possède sa base et son bénéficiaire. Les arrondis s’effectuent au niveau défini par la réglementation et la facture, puis se rapprochent du total payé.
Si trois sous-commandes partagent une remise, alors l’allocation suit une méthode versionnée et distribue le reliquat de manière déterministe. La somme des parts égale toujours la remise source. Le test couvre montants faibles, taux différents et remboursement partiel.
Traiter remboursements et litiges
Inverser la valeur au bon périmètre
Un remboursement référence capture, lignes et bénéficiaires. Il réduit fonds, dette vendeur, commission ou taxe selon politique et stade. Le moteur ne copie pas simplement les écritures d’origine lorsque frais non remboursables ou changements fiscaux existent.
Le dossier montre demandé, approuvé, envoyé au PSP et réglé. Une tentative échouée reste en transit ou exception, pas en remboursement terminé. L’acheteur et le support lisent un statut issu des faits financiers.
Isoler chargeback et frais associés
Le litige PSP peut retirer fonds et frais avant la décision finale. Le ledger place le montant dans un compte de chargeback, puis attribue responsabilité selon contrat. Une victoire rétablit la valeur par un nouveau lot, sans effacer le retrait initial.
Si le vendeur a déjà été payé, alors une réserve, un solde futur ou une créance absorbe la part due. Le seuil de dette déclenche blocage du prochain payout avec owner. La vente reste visible et l’historique explique la séquence.
Piloter réserves et reversements
Calculer le disponible sans raccourci
Le montant payable combine créance confirmée, délai de réserve, remboursements, litiges, retenues et minimum de versement. Chaque composant correspond à un compte ou un état. L’écran affiche disponible, en attente et retenu avec leur date probable.
Une règle de rolling reserve déplace une part vers un compte réservé puis la libère à échéance. Le job de libération utilise date effective et idempotence. Une modification de taux n’altère pas les tranches déjà constituées.
Fermer le cycle du payout
La préparation gèle un montant et produit un payout en transit. L’envoi au PSP bancaire, l’acceptation et le règlement sont des états distincts. Un échec remet la valeur disponible seulement après verdict, pour éviter un double versement.
Le fichier ou l’API de paiement contient une référence corrélée au lot. Le retour externe rapproche bénéficiaire, devise et montant. Si une ligne diverge, alors seul le payout concerné reste en exception ; les autres vendeurs avancent sans attendre la résolution de ce dossier.
Rapprocher les sources externes
Comparer opération par opération
Le rapprochement ingère rapports PSP, banque et facturation avec leur heure et empreinte. Il associe référence, montant, devise et type. Les résultats sont match exact, tolérance justifiée, absent interne, absent externe ou conflit.
Le traitement est rejouable : fichier, parseur et version restent conservés. Une correction du mapping ne duplique pas les écritures. La file d’écarts affiche cause probable, ancienneté, exposition et owner finance.
Réconcilier les soldes de clôture
La somme des comptes de fonds doit rejoindre les relevés externes après opérations en transit. La preuve de clôture part du solde initial, ajoute mouvements, identifie transits et arrive au solde final. Un écart inexpliqué bloque la période.
Le monitoring suit montant et âge des exceptions plutôt que leur seul nombre. Si plus de 0,1 % du volume quotidien reste sans correspondance après deux jours, alors finance suspend l’extension du flux et traite les plus fortes expositions.
Corriger sans réécrire l’histoire
Passer une contre-écriture explicite
Une erreur validée est compensée par un nouveau lot qui référence l’original et son motif. Puis la bonne écriture est passée si nécessaire. Le solde courant devient juste, tandis que l’audit conserve l’erreur, sa détection et sa correction.
Les périodes closes interdisent les modifications rétroactives. Une correction tardive prend sa date comptable autorisée et une date effective métier. Les rapports peuvent ainsi expliquer l’écart entre période de vente et période d’ajustement.
Borner les actions manuelles
Le back-office propose des types de correction avec comptes autorisés, justificatif, approbation et plafond. Une saisie libre sur n’importe quel compte est refusée. Les opérations à quatre yeux gardent demandeur et valideur distincts.
Chaque action affiche simulation avant confirmation : soldes touchés, vendeur, commande et reporting. Le rollback d’une correction est lui-même une nouvelle contre-écriture. Le runbook n’utilise jamais une requête SQL directe comme procédure normale.
Expliquer les soldes aux acteurs
Construire un relevé vendeur lisible
Le relevé part des commandes et regroupe vente, commission, taxe, remboursement, réserve et payout. Chaque ligne ouvre son détail et ses dates. Le vendeur peut relier un écart à un dossier sans apprendre le plan de comptes interne.
Solde début, mouvements de période et solde fin se recoupent. Le fichier exporté garde identifiants stables et devise. Une nouvelle présentation ne change pas les données historiques ni les totaux déjà communiqués.
Servir finance sans créer un second calcul
Finance reçoit balances, journaux et dimensions nécessaires à l’intégration comptable. Le mapping vers le grand livre est versionné par entité. Les exports ne recalculent ni commission ni taxe ; ils traduisent des écritures déjà validées.
Le tableau opérateur suit revenu reconnu, fonds contrôlés, dettes vendeurs, réserves et exceptions. Chaque total descend à ses lignes. Une métrique sans chemin d’explication n’entre pas dans la clôture.
Les accès sont séparés par rôle : un vendeur ne voit que ses mouvements, le support consulte le dossier transactionnel et finance accède aux balances d’entité. Les exports signés conservent période, filtre, version et empreinte afin qu’un total transmis puisse être reproduit plus tard.
Contrôler et répondre aux incidents
Automatiser les contrôles permanents
Équilibre par lot, comptes autorisés, séquences, duplicata, soldes impossibles et rapprochement sont vérifiés en continu. L’instrumentation expose taux de booking, latence, files et montants en exception. Chaque alerte nomme dépendance et owner.
Une sonde reconstitue quotidiennement un échantillon de soldes depuis les lignes. Si le résultat diffère de la vue matérialisée, alors les payouts concernés sont gelés et la vue reconstruite. Les écritures sources restent intactes. Le rapport conserve l’écart, la durée de gel, le propriétaire du diagnostic et le résultat après reconstruction.
Rejouer une perte de cohérence
La recette coupe le webhook, duplique une capture, retarde un settlement, échoue un payout et injecte un fichier tronqué. Elle vérifie retry, idempotence, queue, réconciliation et messages. Les entrées et sorties attendues sont consignées.
Scénario d’incident : si le solde vendeur varie sans nouveau lot, alors l’équipe coupe les projections, conserve les preuves et reconstruit depuis le journal. Le retour en service exige écart nul, cause identifiée et contrôle régressif.
Adapter la méthode et éviter les erreurs
Pour qui le ledger devient nécessaire
Il devient essentiel quand la marketplace partage un paiement, diffère les reversements, gère réserves, remboursements ou plusieurs devises. Un modèle simple peut démarrer avec peu de comptes, mais conserve équilibre, immutabilité et corrélation.
Produit finance définit les faits ; ingénierie possède le moteur ; finance gouverne comptes et clôture ; paiement gère le PSP ; support utilise les relevés ; risque décide des réserves. Les responsabilités ne se fondent pas dans un tableur commun.
Erreurs fréquentes dans un ledger marketplace
Modifier un solde, confondre capture et cash, recalculer l’historique avec le contrat courant, effacer une erreur et compenser entre devises sont les échecs majeurs. Ils rendent le résultat impossible à défendre.
Une autre erreur consiste à copier le modèle comptable général sans représenter les événements transactionnels. Le sous-livre doit expliquer le run de la marketplace puis fournir une intégration stable. Sa valeur vient du lien entre fait, écriture et source.
Plan d’action pour installer le ledger
Semaines 1 à 4 : modèle et booking
La première semaine sélectionne capture, commission, remboursement et payout sur vingt commandes. L’équipe reconstitue les montants depuis les sources et liste les écarts. La deuxième définit comptes, invariants, dimensions, devises et ownership. Finance valide les soldes que chaque acteur doit expliquer et les cas volontairement exclus du pilote.
Les semaines trois et quatre implémentent événements, règles de booking, idempotence et journal. Les tests couvrent arrondis, partiels et duplicata. Un import reprend une cohorte historique dans un environnement isolé ; les balances sont comparées aux PSP et relevés existants avant toute exposition. Les divergences possèdent une file, un owner et un verdict documenté.
Semaines 5 à 8 : réconciliation et bascule
La cinquième semaine branche rapprochement, vues vendeur et exports finance. L’instrumentation suit lots refusés, latence, exceptions et montants. Le monitoring possède seuils, owner et runbook. Les corrections manuelles passent par simulation et approbation, puis sont rapprochées à leur justificatif lors de la revue quotidienne.
Les semaines six et sept opèrent en double lecture avec l’ancien calcul. La huitième joue remboursement tardif, chargeback et payout échoué. Le go exige équilibre, écarts expliqués et rollback testé. La bascule gèle l’ancien writer, mais conserve sa consultation jusqu’à clôture de la première période et validation des relevés vendeurs.
- À faire d’abord : reconstruire quatre faits financiers avec leurs contreparties.
- À tester ensuite : duplicata, arrondis, remboursement partiel et payout échoué.
- À différer : les rapports avancés avant un rapprochement stable.
- À refuser : toute correction qui modifie une écriture déjà validée.
Guides complémentaires pour l’opérateur
Relier finance et back-office
Les écrans du back-office opérateur aident à structurer soldes, exceptions et corrections contrôlées.
Le catalogue PIM marketplace fournit les dimensions produit et catégorie utilisées par les règles de commission.
Borner la première livraison
Le MVP marketplace avant ouverture aide à sélectionner les flux financiers indispensables.
La méthode pour ouvrir une première catégorie permet de limiter contrats et scénarios de la cohorte.
Conclusion : un mouvement explicable
Un ledger marketplace fiable enregistre chaque transfert de valeur par un lot équilibré, immuable et corrélé à son fait source.
Comptes, devises, commissions, réserves et remboursements restent versionnés. Les corrections ajoutent une histoire au lieu de l’effacer.
Rapprochement, relevés et contrôles reconstruisent les soldes depuis les mêmes lignes. Le support explique, finance clôture et le vendeur retrouve son montant.
Pour concevoir ce sous-livre et sa bascule, Dawap peut vous accompagner dans votre marketplace opérateur.
