Votre export des ventes indique 10 000 $. Votre banque affiche 9 000 $. Vous vérifiez la formule, copiez les chiffres dans une autre feuille, et vous ne pouvez toujours pas dire à votre responsable si de l’argent manque.
Pour une petite entreprise e-commerce ou de services, une réponse utile est une explication courte avec des justificatifs derrière chaque ajustement : 500 $ remboursés, 300 $ de frais et 200 $ encore en attente de règlement. Vous savez maintenant ce qui est arrivé, ce qui n’est pas encore arrivé et ce qui doit être examiné.
Parcourez le pack d’entraînement de quatre fichiers ci-dessous pour construire cette explication. Vous pouvez le suivre dans Excel, puis utiliser les mêmes règles pour demander une analyse vérifiable dans RowSpeak.
Points clés :
- Séparez les ventes payées, l’activité de la plateforme, les versements et les crédits bancaires réels. Ils enregistrent des événements différents.
- Suivez un exemple complet de 10 000 $ → 9 000 $ et vérifiez chaque versement par rapport à ses transactions et à son justificatif bancaire.
- Gardez les fonds en attente visibles. Un dépôt manquant n’est pas automatiquement des frais ou une perte.
- Utilisez le téléchargement, le prompt et le test d’échec à 10 $ pour vérifier le résultat d’un outil avant de faire confiance à votre rapport d’activité.
- RowSpeak peut aider à analyser les fichiers et à expliquer le résultat ; vous validez toujours les règles de correspondance et les écarts non résolus.
Pourquoi les ventes et les dépôts diffèrent généralement
Une commande payée enregistre ce que le client a payé. Un versement est un transfert depuis votre plateforme de paiement. Un crédit bancaire enregistre l’argent crédité sur votre compte. Les remboursements, les frais de traitement et le moment du transfert peuvent faire différer ces montants sans qu’il s’agisse d’une erreur.
Le rapprochement des ventes consiste à suivre ces enregistrements jusqu’à ce que l’écart ait une explication. Un contrôle ventes-banque nécessite aussi les soldes au début et à la fin de la période : une partie des liquidités peut provenir des ventes d’un mois antérieur, et une partie des liquidités de ce mois peut arriver plus tard.
La documentation de Stripe sur le rapprochement des versements décrit comment faire correspondre un versement à son lot de transactions, y compris les paiements, les remboursements et les frais. Elle indique aussi que son rapport regroupe les versements par date d’arrivée estimée, qui peut différer de la date de comptabilisation bancaire. D’autres plateformes ont des exports et des règles différents ; vérifiez les vôtres avant de copier un modèle.
Ce guide compare les ventes payées aux mouvements de trésorerie. Il ne détermine pas le chiffre d’affaires comptable reconnu, le traitement fiscal, ni l’exactitude d’un état financier.
Étape 1 : Rassemblez quatre fichiers et définissez chaque ligne
Le téléchargement contient un exemple synthétique de septembre 2026 pour DemoStore. Tous les montants sont en USD, les dates utilisent UTC, et le solde initial de la plateforme est zéro. Ce sont des enregistrements d’entraînement inventés, avec des réponses calculées indépendamment ; il ne s’agit pas de résultats clients ni d’une exécution RowSpeak enregistrée.
| Fichier | Une ligne signifie | Champs à inspecter |
|---|---|---|
| orders.csv | Une commande payée | order_id, order_date, paid_sales, currency |
| processor-activity.csv | Un événement de paiement, de remboursement ou de frais | event_id, order_id, payout_id, signed_amount |
| payouts.csv | Un transfert envoyé par la plateforme | payout_id, payout_amount, bank_reference |
| bank.csv | Un crédit bancaire comptabilisé | bank_row_id, posted_date, reference, credit |
Conservez les originaux inchangés. Travaillez à partir de copies et notez l’export et le compte d’origine de chaque fichier. Dans un export réel de lignes de commande, plusieurs lignes peuvent appartenir à une même commande ; tranchez cette question avant de compter les commandes ou de rapprocher les paiements.
Pour cet exercice, septembre est réputé complet. L’échantillon ne comprend ni taxes, ni frais d’expédition, ni conversion de devise, ni litiges, ni réserves, ni commandes impayées, ni ajustements de périodes antérieures. Les fichiers réels peuvent nécessiter des lignes distinctes pour chacun.
Étape 2 : Convenez de la période avant de rapprocher les montants
Rédigez votre règle de reporting en une phrase :
Expliquez les ventes payées du 1er au 30 septembre de DemoStore et les dépôts bancaires de septembre en USD, avec les soldes d’ouverture et de clôture de la plateforme présentés séparément.
Ne filtrez pas chaque fichier sur order_date. Une commande, son remboursement, le versement de la plateforme et la comptabilisation bancaire peuvent avoir lieu à quatre dates différentes.
Pour un contrôle réel de fin de mois, obtenez le solde d’ouverture de la plateforme, le solde de clôture et les transferts envoyés mais pas encore comptabilisés aux deux bornes. Vérifiez aussi les remboursements de septembre portant sur des commandes d’août. Sans ces enregistrements, un export des commandes du mois en cours ne peut pas expliquer tous les mouvements de trésorerie.
Dans ce jeu de données, les soldes d’ouverture et les transferts en transit sont nuls. Le seul solde de clôture est la commande O105 : 200 $ encaissés le 30 septembre, sans versement encore attribué. Gardez ce montant dans un tableau des fonds en attente et vérifiez-le par rapport à un versement ultérieur ; ne le qualifiez pas d’argent manquant.
Étape 3 : Expliquez l’écart de 1 000 $ à l’aide des enregistrements sources
Commencez par cinq commandes payées :
| Commande | Montant payé | Ajustement ou étape suivante |
|---|---|---|
| O101 | 3 000 $ | Inclus dans le versement P01 |
| O102 | 2 500 $ | Remboursement de 300 $ ; activité restante dans P01 |
| O103 | 2 000 $ | Inclus dans le versement P02 |
| O104 | 2 300 $ | Remboursement de 200 $ ; activité restante dans P02 |
| O105 | 200 $ | Toujours sur la plateforme au 30 septembre |
| Total | 10 000 $ | Avant remboursements et frais de plateforme |
Les événements de remboursement E03 et E07 totalisent 500 $. Les événements de frais E04 et E08 totalisent 300 $. Le solde non réglé de clôture de la plateforme est E09, 200 $.
Figure : calculée indépendamment à partir des enregistrements synthétiques téléchargeables. Il s’agit d’un graphique explicatif, et non d’une capture d’écran produit.
Le résultat est :
Ventes payées 10 000 $
Moins remboursements 500 $
Moins frais de plateforme 300 $
Moins fonds non réglés de clôture 200 $
Dépôts bancaires attendus 9 000 $
Dépôts bancaires réels 9 000 $
Écart inexpliqué 0 $
Ce pont simple fonctionne parce que les autres flux et soldes d’ouverture de l’échantillon sont nuls. Pour des données réelles, présentez les fonds d’ouverture comme une addition, les fonds de clôture comme une déduction, et documentez séparément les autres ajustements de plateforme et les transferts en transit. N’inventez jamais un « ajustement de calendrier » simplement pour atteindre zéro.
Étape 4 : Vérifiez chaque versement, puis vérifiez la banque
Un total global concordant peut masquer des erreurs qui s’annulent. Vérifiez aussi chaque lot individuellement.
| Versement | Activité source | Versement net | Justificatif bancaire | Écart |
|---|---|---|---|---|
| P01 | 3 000 $ + 2 500 $ − 300 $ de remboursement − 120 $ de frais | 5 080 $ | B01 : 5 080 $ comptabilisés le 10 septembre | 0 $ |
| P02 | 2 000 $ + 2 300 $ − 200 $ de remboursement − 180 $ de frais | 3 920 $ | B02 : 3 920 $ comptabilisés le 25 septembre | 0 $ |
Utilisez une référence de versement fiable pour relier le transfert à la banque. Si une référence est absente, utilisez le montant, le compte, la devise et une fenêtre de dates documentée pour identifier des correspondances possibles. Deux dépôts du même montant restent ambigus jusqu’à confirmation par une personne.
Il existe aussi un piège de tableur : une commande peut avoir à la fois un paiement et un remboursement. Si vous joignez la table des commandes à chaque événement, puis additionnez paid_sales, le montant de la commande apparaît deux fois. Additionnez les ventes à partir de la table de commandes d’origine ; additionnez l’activité de trésorerie à partir de la table d’événements. Comparez les résultats au bon niveau.
Dans le fichier d’activité, les remboursements et les frais sont déjà négatifs. Additionnez signed_amount pour chaque versement ; soustraire à nouveau ces valeurs négatives gonflerait le résultat. Le ZIP inclut expected-payout-matches.csv et expected-bridge.csv comme corrigés.
Étape 5 : Demandez à RowSpeak une explication que vous pouvez vérifier
Une fois les règles claires, le flux de travail d’analyse de données de RowSpeak peut vous aider à inspecter les exports, calculer des synthèses et transformer les résultats en un rapport lisible. Commencez par les entrées synthétiques avant de téléverser des fichiers métier.
Téléversez uniquement les quatre CSV d’entrée et utilisez cette demande. Gardez les fichiers corrigés hors de l’exécution pour pouvoir comparer ensuite.
Aidez-moi à rapprocher les ventes payées et les dépôts bancaires de DemoStore du 1er au 30 septembre 2026. Utilisez les quatre CSV joints. Tous les montants sont en USD ; les dates sont en UTC. Gardez les données sources inchangées. Chaque ligne de orders correspond à une commande payée ; chaque ligne de processor correspond à un événement. Les remboursements et les frais sont déjà négatifs.
Vérifiez d’abord les ID uniques, les clés manquantes, les devises et la couverture des sources. Comparez chaque montant de commande avec son événement de paiement ; signalez les écarts. Calculez les ventes à partir de orders, pas à partir d’une table jointe aux événements de remboursement. Groupez signed_amount de processor par payout_id. Conservez les événements avec payout_id vide comme activité non réglée. Comparez chaque lot avec payouts.payout_amount, puis faites correspondre son bank_reference à bank.reference et bank.credit. Ne devinez pas les correspondances ambiguës et ne traitez pas un versement envoyé comme une réception bancaire.
Affichez les ID sources pour les ventes, remboursements, frais, fonds non réglés, correspondances de versements et éléments non appariés. Le solde d’ouverture de la plateforme et les transferts en transit sont nuls dans cet exercice. Les autres types d’ajustement sont absents. Retournez un pont ventes-banque, un tableau de correspondance des versements et un tableau d’exceptions. Étiquetez les causes inconnues comme non résolues ; n’ajoutez jamais de frais d’équilibrage. Terminez par un court résumé pour le responsable et les contrôles nécessitant encore une approbation.
Attendu : 10 000 $ de ventes payées, 500 $ de remboursements, 300 $ de frais, 200 $ non réglés et 9 000 $ d’encaissements bancaires. Les deux versements correspondent. O105 est un élément en attente expliqué ; l’écart inexpliqué est nul. Ce sont des attentes calculées, et non une garantie du résultat de quelque outil d’IA que ce soit.
Pour des documents financiers confidentiels, utilisez des fichiers anonymisés ou discutez d’un déploiement privé avant de téléverser. Ce guide utilise des fichiers exportés ; il ne suppose ni connexion bancaire en direct, ni suivi automatique des règlements, ni agent de vérification indépendant dans RowSpeak.
Étape 6 : Testez un échec avant d’utiliser le résultat mensuel
Faites une copie de bank.csv. Faites passer le crédit de B02 de 3 920 à 3 910, puis répétez la demande avec cette copie et les trois autres entrées d’origine.
Le total bancaire devrait devenir 8 990 $, et P02 devrait afficher un manque de 10 $. Les remboursements, les frais et les fonds en attente doivent rester inchangés. Si l’outil ajoute discrètement des frais de 10 $, modifie O105 ou déclare que tout correspond, demandez les lignes sources et gardez le rapport en brouillon.
Avant de partager, vérifiez :
- Chaque paiement de commande correspond à son montant source, et chaque crédit bancaire a une correspondance approuvée.
- Les remboursements et les frais apparaissent une seule fois, avec les bons signes.
- Les fonds en attente ont des ID sources et une date de suivi.
- Les ID manquants, les événements en double et les correspondances ambiguës restent visibles.
- Les soldes d’ouverture et de clôture, les devises, les règles de dates et l’exhaustivité ont un responsable qui peut les confirmer.
La liste de contrôle plus large pour la revue des rapports générés par IA couvre d’autres vérifications, notamment les explications non étayées et les lignes en double.
Ce qu’il faut envoyer à votre responsable
Pour l’échantillon inchangé, une note utile est :
Les ventes payées de septembre s’élevaient à 10 000 $. Les encaissements bancaires étaient de 9 000 $ après 500 $ de remboursements, 300 $ de frais de plateforme et 200 $ encore non réglés à la fin du mois. Les deux lots de versements correspondent aux crédits bancaires. Le solde en attente de 200 $ concerne O105 et nécessite une vérification lors d’un versement ultérieur. Aucun écart inexpliqué ne subsiste dans le périmètre indiqué de l’échantillon.
Conservez cette note avec les versions des entrées, les règles de correspondance, les décisions sur les exceptions et l’approbation du réviseur. Pour le mois suivant, le flux de travail de reporting CSV récurrent explique comment conserver ces règles tout en actualisant les fichiers.
Rendez votre prochaine clôture plus facile à expliquer
Transformez l’écart inexpliqué en liste de vérification.
Essayez l’exemple à quatre fichiers dans RowSpeak avant votre prochaine revue de fin de mois. Vérifiez le résultat de 9 000 $, puis exécutez le test d’échec de 10 $ pendant que vous avez encore le temps d’examiner les exceptions.
Commencez par les fichiers synthétiques. Vérifiez le résultat avant de l’appliquer à une vraie clôture.
