Le compte Amazon affiche une somme qui vient d’être libérée. Le tableau de trésorerie l’ajoute aux encaissements, puis la compte une seconde fois lorsque le versement apparaît. À la réunion suivante, le responsable e-commerce croit disposer d’un budget supplémentaire pour ses achats de stock ou sa publicité. La banque, elle, ne montre qu’une partie de ce montant. Le problème commence par une confusion entre changement d’état et nouveau mouvement.
La vraie question est de savoir quelle preuve permet de faire passer chaque somme du différé au groupe de paiement, puis du paiement annoncé à l’encaissement constaté. Une transaction peut changer de statut sans créer une seconde vente. Un groupe peut être identifié sans que son rapprochement bancaire soit terminé. Ces étapes doivent rester lisibles séparément pour éviter une décision commerciale fondée sur de l’argent compté deux fois.
Le scénario ci-dessous suit des transactions fictives en euros et en dollars. Il montre pourquoi 200 euros différés, 120 euros libérés sans groupe documenté et un groupe de 180 euros ne forment pas 500 euros encaissés. Un exercice téléchargeable vérifie les calculs, les doublons et plusieurs faux rapprochements. Il ne consulte aucun compte vendeur et n’effectue aucune opération financière.
Notre agence marketplace pour les marques et les vendeurs accompagne la mise en place de ce pilotage. Le reporting des ventes et des opérations marketplace permet de présenter ensemble la preuve disponible, les écarts ouverts et la prochaine vérification, sans remplacer la comptabilité ni les contrôles de votre équipe finance.
Pour qui : une trésorerie vendeur qui change sans nouvelle vente
Reconnaître le symptôme dans les décisions commerciales
Cette méthode concerne une marque qui vend sur Amazon et constate des écarts entre son export financier, son suivi des versements et ses relevés bancaires. Le signal typique est une hausse du montant « disponible » que personne ne parvient à relier à de nouvelles commandes. Un autre signal apparaît lorsque deux actualisations successives augmentent le total alors que les mêmes identifiants reviennent dans les lignes.
Le responsable marketplace doit pouvoir répondre à une question simple : la variation vient-elle d’une nouvelle transaction, d’un changement de statut, d’un rattachement à un paiement ou d’un encaissement ? Cette réponse conditionne l’arbitrage entre une promotion, un réassort et le maintien d’une réserve de fonctionnement. Un graphique de chiffre d’affaires ne suffit pas à distinguer ces événements.
Délimiter ce qui sera réellement rapproché
Commencez par un compte vendeur, une devise et un groupe de paiement. Le périmètre restreint permet de comparer les pièces sans convertir les montants ni répartir des frais communs. Le scénario porte sur des mouvements financiers déjà normalisés. Il ne recalcule ni la TVA, ni le barème des commissions, ni le résultat fiscal du vendeur ; chacun de ces sujets demande ses propres justificatifs.
Si l’équipe ne dispose que d’un montant global copié depuis un écran, elle ne peut pas encore automatiser un rapprochement détaillé. Elle doit d’abord obtenir les transactions et les références utiles par un moyen autorisé. L’accès aux données doit rester limité aux comptes accompagnés. Un export d’une autre marque ne devient pas une pièce acceptable parce que son montant ressemble au versement recherché.
Lire les trois statuts sans fabriquer un second encaissement
La note Amazon du 30 avril 2025 explique le passage d’une transaction différée à DEFERRED_RELEASED lorsqu’elle est libérée. Il s’agit d’une évolution déjà documentée, pas d’une nouveauté d’octobre 2026. Les deux autres statuts distinguent une transaction encore différée (DEFERRED) d’une transaction libérée (RELEASED). Conserver cette histoire évite de transformer la libération en nouvelle vente.
| État source | Lecture | Décision interne |
|---|---|---|
| Différée | Transaction encore différée. | Ne pas la présenter comme encaissée. |
| Libérée | Transaction libérée. | Rechercher son rattachement et la preuve de paiement. |
| Après différé | Transaction libérée après un différé. | Actualiser son état sans additionner ses observations. |
Conservez le libellé source et ajoutez une lecture métier distincte. « Libérée, groupe non documenté » est une qualification de votre suivi, pas un quatrième statut officiel. Cette précision évite qu’un collaborateur interprète une couleur verte comme une garantie de virement reçu. Le montant reste consultable, mais son usage dans le prévisionnel dépend de la preuve réellement disponible.
Paradoxalement, une meilleure collecte peut faire baisser le total affiché : elle supprime un double comptage entre l’observation initiale et sa mise à jour. Ce recul n’est pas nécessairement une perte de revenu. Le reporting doit expliquer la correction, conserver l’ancienne présentation pour l’audit et empêcher que la direction compare deux courbes dont les règles de calcul diffèrent silencieusement.
Conserver une transaction et plusieurs observations de son état
Séparer l’identité du mouvement et l’historique de collecte
La référence Finances v2024-06-19 décrit notamment transactionId, transactionStatus, totalAmount et les identifiants associés. Dans votre stockage, conservez le contexte du vendeur avec ces données. Les observations brutes servent à retrouver ce qui a été reçu ; la projection courante sert à calculer un état à un instant donné.
Le cas fictif utilise T1, 120 euros, observée une première fois comme différée puis comme libérée après différé. Les deux observations restent archivées. La projection ne conserve qu’une valeur courante de 120 euros. Additionner les deux lignes produirait 240 euros pour la même identité. L’idempotence du chargement doit empêcher qu’une relance du même import aggrave encore cette erreur.
Refuser les correspondances fondées uniquement sur le montant
L’exercice attribue un numéro de révision local aux observations. Ce numéro n’est pas un champ Amazon ; il représente ici un ordre déjà qualifié. En production, une réponse arrivée plus tard n’est pas automatiquement la preuve d’un état plus récent. Un ancien export rejoué doit être reconnu comme tel. Deux observations incompatibles doivent ouvrir une vérification, plutôt qu’être départagées arbitrairement par leur ordre d’insertion.
Lorsque deux sources emploient des identifiants différents, ne les fusionnez pas parce qu’elles portent toutes deux 120 euros. Il faut une correspondance documentée et vérifiée sur les pièces disponibles. À défaut, affichez un rapprochement en attente. La règle du scénario « même identifiant, état actualisé » ne garantit pas que tous les rapports et tous les événements Amazon partagent une identité universelle.
Relier les transactions au groupe de paiement sans présumer la couverture
Suivre le chemin documenté par Amazon
Le tutoriel de composition d’un paiement commence par listFinancialEventGroups de Finances v0. Il récupère ensuite les transactions avec listTransactions, le filtre FINANCIAL_EVENT_GROUP_ID, la valeur du groupe et transactionStatus=RELEASED. Il prévoit aussi de poursuivre les pages lorsqu’un jeton suivant est présent.
Ce parcours est une preuve de rattachement bien plus solide qu’une sélection « toutes les ventes du mardi ». Un versement ne correspond pas nécessairement à votre journée de commandes ou à votre semaine commerciale. Conservez le groupe comme objet propre, avec son identifiant, sa devise et les pièces qui expliquent sa composition. La période du tableau de direction reste un axe d’analyse, pas une clé de jointure.
Ne pas extrapoler le filtre RELEASED aux anciens différés
Le tutoriel consulté utilise explicitement RELEASED, alors que la documentation distingue aussi DEFERRED_RELEASED. Il ne faut donc pas annoncer que ce seul filtre démontre la couverture de tous les anciens différés. Une transaction libérée après différé dont le groupe n’est pas établi conserve une file de vérification séparée. L’exemple respecte cette limite : T1 ne participe pas au groupe G1.
Sur un dossier réel, l’équipe d’intégration doit qualifier les identifiants et les pièces nécessaires pour couvrir ce cas, puis les confronter aux montants du paiement. Si une transaction de ce statut apparaît dans un groupe de votre projection, le contrôle pédagogique la place en revue : il ne la déclare ni impossible ni automatiquement rapprochée. Cette prudence évite de masquer une couverture incomplète sous un total plausible.
Exemple concret : 500 euros suivis, mais seulement 175 euros constatés
Le vendeur fictif S1 possède les cinq transactions suivantes. T1 a deux observations successives ; les autres n’en ont qu’une dans le jeu de données. Les montants sont signés et la devise fait partie du contrôle. G1 est supposé complet et fermé pour ce scénario, avec un montant annoncé de 180 euros. Ces hypothèses sont testables ; elles ne sont pas déduites de la seule présence des lignes.
| Transaction | Dernier état retenu | Traitement |
|---|---|---|
| T1 : 120 € | Libérée après différé. | Groupe encore non documenté. |
| T2 : 200 € | Libérée, groupe G1. | Composante positive de G1. |
| T3 : −20 € | Libérée, groupe G1. | Remboursement déduit dans G1. |
| T4 : 200 € | Encore différée. | Reste dans le suivi des différés. |
| T5 : 50 USD | Libérée, sans groupe. | Conservée dans une vue USD séparée. |
Réconcilier les catégories avant la banque
La projection courante en euros vaut 200 euros différés, 120 euros libérés sans groupe documenté et 180 euros rattachés à G1. Le total de ces catégories vaut 500 euros. Il décrit uniquement les transactions du jeu fictif ; ce n’est ni un solde officiel du compte Amazon, ni une créance comptable validée, ni un budget disponible. Les 50 dollars restent hors de cette addition.
En additionnant les deux observations de T1, le même export produirait 620 euros. En mélangeant ensuite les devises, une autre erreur afficherait « 550 » à partir des seuls états courants. Aucun de ces nombres ne mérite le libellé « euros disponibles ». Le premier défaut confond versions et mouvements ; le second supprime l’unité monétaire. Les deux doivent être visibles dans la recette du reporting.
Conserver les 5 euros manquants comme un écart ouvert
Le détail de G1 donne 200 − 20 = 180 euros. Le mouvement bancaire fictif, rattaché par une référence vérifiée à G1 et au bon vendeur, vaut 175 euros. L’écart est donc de 5 euros. Il représente environ 2,78 % du montant attendu de ce groupe. Ce ratio décrit l’exercice ; il ne constitue pas un seuil universel de tolérance ni une mesure des pertes habituelles des vendeurs Amazon.
Le dossier conserve « groupe expliqué, réception partielle à éclaircir ». Il ne transforme pas les 5 euros en commission, frais bancaires ou retenue sans justificatif. Une charge documentée pourrait expliquer ultérieurement la différence ; une autre pièce pourrait corriger le montant attendu. Tant que cette preuve manque, la finance garde une action ouverte et le cockpit ne présente pas G1 comme intégralement rapproché.
Distinguer paiement annoncé et réception bancaire vérifiée
Lire le groupe avec sa devise et son signe
Le tutoriel Amazon sur le montant et le statut d’un paiement retient les groupes dont ProcessingStatus vaut Closed. Il décrit OriginalTotal comme le montant du versement ou de la charge, avec sa valeur et son code devise. Votre écran doit conserver cette possibilité de charge ; un montant signé n’est pas toujours une entrée positive.
La preuve bancaire reste une autre pièce. Pour l’exercice, nous fournissons une correspondance explicite entre le mouvement et G1. Dans un système réel, cette correspondance peut demander la lecture de références ou une validation manuelle tracée. Elle ne doit pas être obtenue en prenant le premier mouvement bancaire du même montant. Deux virements de 180 euros peuvent concerner des groupes différents.
Attribuer des verdicts que l’équipe peut expliquer
Le contrôle local refuse la clôture si le groupe est incomplet ou encore ouvert. Il distingue ensuite le détail qui ne rejoint pas le montant annoncé, la banque absente, la référence non rapprochée et l’écart de montant. Ce vocabulaire appartient au processus proposé. Il aide un collaborateur à savoir s’il manque des données Amazon, une pièce bancaire ou une explication financière.
Un mouvement de 180 USD, provenant d’un autre compte ou associé à G2 ne ferme pas G1. Même avec une devise correcte, une référence incertaine impose une revue. L’objectif n’est pas de ralentir chaque rapprochement : les cas dont l’identité, la couverture et le montant sont établis peuvent avancer rapidement, tandis que les autres restent explicitement à traiter.
Empêcher une collecte incomplète de produire un faux solde
La référence de listTransactions avertit que les événements peuvent ne pas inclure les commandes des dernières 48 heures. Elle prévoit des pages vides et demande de poursuivre avec les mêmes arguments jusqu’à un nextToken nul. Une absence dans la première réponse ne prouve donc ni l’absence de transaction ni la fin du parcours.
Pour une recherche temporelle, la borne de début est incluse et celle de fin exclue. Une plage dépassant 180 jours renvoie un résultat vide selon cette référence. En recette, vérifiez les paramètres réellement envoyés avant de conclure que le vendeur n’a aucun mouvement. Le cockpit devrait afficher la période demandée et la dernière collecte complète, sans donner un statut rassurant à une requête mal cadrée.
Le tutoriel des dernières transactions décrit des décompositions imbriquées et des types de frais ouverts à de nouvelles valeurs. Notre règle de calcul proposée consiste à choisir un niveau de total et à utiliser les détails pour l’expliquer. Additionner un total à ses propres composantes peut créer une recette supplémentaire fictive. Une valeur inconnue doit rester visible jusqu’à sa qualification.
Les entrées du traitement comprennent le vendeur, les filtres et la période demandée. Sa sortie doit distinguer parcours complet et actualisation interrompue, même si la première page contient des montants plausibles. Prévoyez un repli sur le dernier résultat validé avec son ancienneté visible. La journalisation conserve les paramètres et la page en échec, sans exposer les données financières dans des logs accessibles à tous. Une dernière page absente ne transforme jamais un écart en zéro.
Recetter les faux rapprochements avant de financer une décision
Exécuter un exemple qui échoue au bon endroit
Le fichier rapprochement_versement.py utilise uniquement la bibliothèque standard Python et les données fictives décrites ci-dessus. Ses 21 contrôles vérifient les catégories, le rejeu, les observations contradictoires, les devises et plusieurs conditions de rapprochement. Il n’appelle aucune API Amazon, ne lit aucun relevé bancaire réel et ne démontre pas la complétude d’un connecteur en production.
Le scénario positif remplace les 175 euros par un mouvement de 180 euros correctement rattaché : le résultat devient rapproché. Les scénarios négatifs conservent ce montant tout en changeant le vendeur, la devise ou le groupe ; ils restent refusés. Une autre vérification retire T3 : le détail de G1 vaut alors 200 euros au lieu des 180 annoncés et l’écart est détecté avant le contrôle bancaire.
python3 rapprochement_versement.py
# 21 contrôles réussis
# Différé : 200 EUR ; libéré sans groupe : 120 EUR
# Groupe : 180 EUR ; banque : 175 EUR ; écart : 5 EURTransformer les contrôles en critères de réception
La recette métier présente en entrée les pièces de G1 et attend en sortie un écart ouvert de 5 euros. La responsabilité du verdict financier revient à la finance ; le responsable marketplace décrit sa conséquence sur le budget de réassort. L’intégrateur démontre l’idempotence en rejouant le même import sans modifier les catégories. Une capture montrant seulement « synchronisation réussie » ne remplace ni ce calcul, ni la preuve de rejeu, ni l’attribution de la prochaine action.
Fixez un seuil d’escalade selon votre contexte, tout en séparant priorité et preuve. Un écart faible peut être revu plus tard sans devenir un rapprochement réussi. La récurrence d’un petit montant sur plusieurs groupes peut justifier une investigation prioritaire. Mesurez donc les groupes restant inexpliqués, leur ancienneté et les sommes concernées, plutôt que le seul pourcentage de lignes importées.
Erreurs fréquentes : fermer le tableau avant de fermer l’écart
- À faire maintenant : conserver les 5 euros de G1 dans une file attribuée à la finance et retrouver la pièce qui explique la différence.
- À différer : engager les 120 euros de T1 dans un réassort en les considérant déjà encaissés, tant que le rattachement au paiement manque.
- À refuser : fermer le groupe grâce à un ajustement sans justificatif ou en y affectant un virement de même montant mais d’une autre référence.
Effacer les différés quand une date attendue arrive
Une date prévue sert à organiser une revue. Elle n’autorise pas votre traitement à changer lui-même le statut source. Dans le cas fictif, T4 reste différée tant qu’aucune nouvelle observation qualifiée ne prouve autre chose. Un calendrier peut déclencher une vérification, pas fabriquer une libération ou une réception bancaire. Cette séparation protège les prévisions contre les transitions automatiques trop optimistes.
De même, faire disparaître T1 de la file parce qu’elle est libérée laisserait ses 120 euros sans suivi jusqu’au paiement. Gardez une action de recherche du groupe ou de la pièce manquante. L’indicateur utile est la somme libérée dont le rattachement reste à documenter, avec une ancienneté expliquée. Ce montant n’est pas nécessairement perdu ; il est encore insuffisamment rapproché.
Confondre correction de reporting et récupération d’argent
Supprimer le double comptage de T1 corrige une présentation erronée. Cela ne récupère pas 120 euros auprès d’Amazon. Expliquer les 5 euros de G1 par une pièce recevable ferme une investigation ; cela ne signifie pas forcément qu’un remboursement sera demandé. Le suivi doit distinguer correction interne, demande de justification et contestation documentée pour éviter de gonfler artificiellement les gains annoncés.
Une autre erreur consiste à rapprocher les versements au prorata du chiffre d’affaires des SKU. Cette répartition peut servir à une analyse explicitement conventionnelle, mais elle ne prouve pas l’identité des transactions composant un groupe. Gardez l’analyse de rentabilité séparée du rapprochement des mouvements. Une offre rentable peut produire un encaissement tardif, et un versement reçu ne démontre pas sa marge.
Plan d’action : passer d’un groupe témoin à une revue fiable
Choisir le dossier et écrire les preuves attendues
Réunissez le responsable du compte vendeur et un interlocuteur finance autour d’un groupe déjà identifiable. Sélectionnez une seule devise et conservez les exports ou réponses autorisés avec leur date de collecte. Écrivez les questions auxquelles le rapprochement doit répondre : quelles transactions appartiennent au groupe, quel montant est annoncé, quelle réception est constatée et quel écart reste ouvert ? Cette préparation évite de commencer par un écran dont personne n’a défini les verdicts.
Attribuez ensuite chaque preuve à une source et chaque anomalie à un responsable. Le vendeur fournit le contexte commercial, la finance valide la lecture du mouvement bancaire et l’intégration explique les limites de collecte. Si une référence manque, notez précisément laquelle et la prochaine vérification. Le dossier témoin doit pouvoir être repris par un collègue sans conversation orale indispensable pour comprendre les chiffres ou les conventions retenues.
Recevoir le calcul et les cas refusés
Rejouez le dossier deux fois et comparez les résultats. Introduisez volontairement une observation dupliquée, un remboursement absent et un virement de même montant portant une autre référence. Demandez au système de montrer la cause du refus, pas seulement un statut rouge. Vérifiez aussi le comportement lorsque la collecte s’interrompt : les données précédemment validées doivent rester identifiables et l’interface doit signaler ce qui manque à l’actualisation.
Consignez les résultats dans une fiche de réception courte. Elle contient les montants attendus, les pièces utilisées, les limites connues et les décisions encore manuelles. La validation concerne ce périmètre précis. Elle ne permet pas d’annoncer que tous les comptes, toutes les devises ou tous les statuts sont couverts. L’ajout d’un nouveau cas doit reprendre cette démarche avant de modifier les indicateurs utilisés par la direction.
- Livrable finance : détail signé de G1 égal à 180 euros, pièce bancaire de 175 euros et écart de 5 euros conservé avec son responsable.
- Livrable intégration : résultat identique après deux imports et refus démontré du mauvais vendeur, de la mauvaise devise et du groupe incomplet.
- Décision vendeur : budget d’achat fondé sur la réception vérifiée, avec hypothèses de prévision affichées séparément pour les sommes encore suivies.
Installer la revue et élargir avec des critères explicites
Ouvrez une file des groupes non rapprochés avec un propriétaire et une prochaine date de revue. Suivez séparément les différés, les sommes libérées sans rattachement établi, les groupes documentés et les écarts bancaires. Une revue hebdomadaire peut convenir au pilote, mais sa cadence doit être adaptée aux engagements et au volume du vendeur. Aucun délai proposé ici ne remplace les conditions applicables à votre compte Amazon.
Élargissez seulement lorsque les cas refusés sont compris et que le rejeu reste stable. Pour un besoin récurrent sur plusieurs canaux, un cockpit tel que Ciama pour le pilotage marketplace peut être étudié selon les sources et connecteurs à qualifier. La décision doit partir des opérations réellement couvertes, du temps de traitement observé et du coût de maintien, sans supposer qu’un produit dispose déjà de chaque rapprochement particulier.
Prolonger le rapprochement vers les incidents, la marge et le prévisionnel
Le suivi d’un différé ne couvre pas toute la gestion financière du compte. Pour organiser la qualification et l’escalade d’un écart, consultez le dossier sur les incidents financiers Amazon. Pour expliquer le passage du prix de vente à la contribution puis au cash, le margin bridge marketplace fournit un cadre complémentaire.
Une fois les mouvements qualifiés, leur temporalité peut alimenter le prévisionnel de trésorerie à treize semaines. Le dossier sur les retards de versement et le besoin en fonds de roulement aide à examiner les conséquences sur les achats et le financement du stock. Ces analyses utilisent les preuves de rapprochement ; elles ne les remplacent pas.
Conclusion : une somme libérée reste à suivre jusqu’à sa preuve de réception
Le changement de statut d’une transaction Amazon doit expliquer une évolution de son état, sans créer artificiellement une vente ou un encaissement supplémentaire. Conserver l’identité du mouvement et ses observations permet de corriger le double comptage tout en gardant une histoire vérifiable. La libération après différé mérite une place explicite dans ce suivi.
Le scénario laisse trois catégories en euros et une vue USD séparée. G1 vaut 180 euros, la banque en montre 175 et les 5 euros restants demeurent inexpliqués. T1 conserve ses 120 euros libérés sans groupe documenté ; T4 reste différée pour 200 euros. Cette lecture donne à chaque équipe une prochaine vérification sans présenter l’ensemble comme une trésorerie disponible.
Un reporting marketplace construit autour des preuves et des écarts rend ces distinctions utilisables au quotidien. Les indicateurs doivent montrer leur périmètre, leur fraîcheur et leurs limites, puis aider à prioriser les dossiers dont le traitement change réellement une décision d’achat, de promotion ou de réassort.
Dawap vous accompagne pour cadrer ce fonctionnement avec votre équipe finance et vos responsables e-commerce. Notre agence marketplace relie les opérations vendeur aux décisions de pilotage, avec des critères de réception concrets et un suivi des écarts qui reste compréhensible lorsque le volume augmente.
