Le total des frais n'est probablement pas faux. Votre export de frais Stripe et votre rapport de ventes interne mesurent deux couches différentes du même flux de paiement. Une comparaison brute transforme des coûts de traitement ordinaires en écarts fictifs.
Un rapport de ventes suit les commandes et la logique de revenus interne. L'export de frais Stripe suit les événements de frais liés à des encaissements, des remboursements, des litiges ou à d'autres mouvements de solde. Tant que la période, la clé de rapprochement et la base de calcul des montants ne correspondent pas, il est impossible de déterminer si des frais sont manquants ou si les deux fichiers n'étaient tout simplement pas comparables.
Diagnostiquez l'écart avant de totaliser quoi que ce soit
La plupart des mauvaises comparaisons de frais se classifient avant d'écrire la moindre formule. Les deux fichiers divergent généralement parce que le même événement commercial est stocké sous des formes différentes.
| Ce que vous voyez à l'écran | Comment le rapport de ventes interne le stocke | Comment le CSV de frais Stripe le stocke | Ce qui se passe lors d'un rapprochement brut |
|---|---|---|---|
Commande #10428 pour 120.00 | Une ligne identifiée par le numéro de commande, datée en heure locale | Une ligne de frais identifiée par ch_... ou une autre référence Stripe | Aucune correspondance directe, même si les frais se rapportent bien à cette vente |
Vente datée du 2026-05-31 | Date locale de vente dans le rapport de fin de mois | Frais enregistrés juste après minuit UTC le 2026-06-01 | La même vente sort du filtre et semble être un frais manquant |
Le rapport affiche 97.00 de revenus nets sur le produit | Taxes et livraison exclus du montant interne | Frais Stripe calculés sur le montant total facturé au client | Le taux de frais effectif paraît trop élevé, car le dénominateur a changé |
| La commande remboursée n'apparaît plus dans les ventes de la période en cours | La vente d'origine est supprimée ou déduite dans le rapport | Les frais de traitement d'origine restent rattachés à l'historique de l'encaissement | Les frais semblent orphelins ou surestimés par rapport aux ventes actuelles |
| Une ligne de frais supplémentaire apparaît sans vente évidente | Le rapport interne n'a pas de poste pour les frais transfrontaliers, de change ou liés aux litiges | Stripe exporte ces frais comme des événements distincts | Le total des frais Stripe paraît gonflé si vous additionnez toutes les lignes |
| Les montants semblent identiques mais échouent au rapprochement | Le montant ou la clé est stocké en tant que texte | Le montant ou la clé est stocké en tant que nombre ou texte nettoyé | Les recherches exactes échouent avant même que le rapprochement commence |
Chaque ligne appelle une correction différente. Classifiez l'écart en premier, puis corrigez la comparaison.
Définissez ce que mesure réellement chaque fichier
| Fichier | Colonnes habituelles | Ce que le fichier vous dit vraiment |
|---|---|---|
| Rapport de ventes interne | Identifiant commande, date de commande, ventes brutes, remises, taxes, livraison, ventes nettes, frais de traitement éventuellement comptabilisés | Ce que l'entreprise a vendu, facturé ou comptabilisé en interne |
| CSV de frais Stripe | incurred_by, incurred_by_type, fee_description, amount, currency, date des frais, référence de transaction au solde | Ce que Stripe a facturé comme frais, à quelle date, et quel objet les a générés |
Une seule vente peut générer plusieurs événements côté Stripe. L'encaissement initial crée des frais de traitement. Un remboursement ultérieur peut modifier l'économie de cette commande sans annuler les frais d'origine. Un litige peut générer un coût distinct plus tard.
C'est pourquoi ce guide n'est pas la même procédure que le rapprochement d'un CSV de virement Stripe avec un relevé bancaire. Le rapprochement virement-banque prouve la trésorerie. La comparaison frais-ventes prouve si les coûts de traitement ont bien été saisis pour les ventes examinées.
La question pratique est la suivante : parmi les frais Stripe dans le périmètre, lesquels sont déjà reflétés en interne et lesquels sont manquants ou sous-estimés ? Si les fichiers ne permettent pas de répondre à cette question, le problème est structurel, pas arithmétique.
Définissez le périmètre de la comparaison avant de toucher aux formules
Ne totalisez rien tant que les deux fichiers n'utilisent pas la même fenêtre temporelle et la même base de montants.
| Vérification du périmètre | Pourquoi c'est important | Ce qu'il faut uniformiser |
|---|---|---|
| Base de période | Les rapports de ventes utilisent souvent la date locale de commande. Les exports de frais Stripe peuvent utiliser l'UTC ou la date d'enregistrement des frais | Choisissez une base de reporting commune aux deux fichiers avant de filtrer |
| Fuseau horaire | Un encaissement en fin de soirée peut basculer au jour suivant en UTC | Convertissez les dates Stripe dans le même fuseau horaire que votre rapport de ventes |
| Devise | Un côté peut être en devise locale tandis que les lignes de frais Stripe restent en devise de règlement | Ne comparez que les lignes dans la même devise, ou divisez d'abord le rapport |
| Base de montant | Le rapport interne peut exclure les taxes, la livraison ou les remises tandis que les frais Stripe sont calculés sur le montant total facturé au client | Décidez si le dénominateur est le montant facturé au client ou le chiffre d'affaires net interne |
| Périmètre des statuts | Les commandes annulées, les factures impayées ou les encaissements non capturés peuvent figurer dans un rapport de ventes sans frais Stripe finalisés | Limitez la comparaison aux encaissements finalisés |
Si tous les écarts sont d'un jour, testez d'abord la logique de date. Cela signifie généralement un problème de coupure ou de fuseau horaire, pas un frais manquant. L'article Pourquoi les horodatages UTC de Stripe ne correspondent pas aux dates du CSV de relevé bancaire traite le même problème du côté des virements — la règle est identique ici : comparez des dates de reporting local à des dates de reporting local, pas des valeurs UTC brutes à des synthèses locales.
Vérifiez les types importés avant de vous fier aux cellules. Utilisez TYPE() : la fonction vous indique directement si Excel voit du texte ou un nombre.
=TYPE(A2)appliqué à une date ou un montant doit renvoyer1pour une valeur numérique Excel.=TYPE(A2)renvoyant2signifie que la valeur est du texte et ne peut pas encore être comparée en toute sécurité.
Si un montant a été importé en texte avec des virgules, forcez-le à revenir en nombre directement dans la formule :
=CNUM(SUBSTITUE(A2,",",""))Si une référence est stockée en nombre d'un côté et en texte de l'autre, uniformisez-la avant la recherche :
=TEXTE(A2,"0")Si une date est arrivée en texte et que le format est ambigu, extrayez les parties explicitement plutôt que d'espérer qu'Excel devine correctement. Pour un texte au format MM/JJ/AAAA :
=DATE(DROITE(B2,4),GAUCHE(B2,2),STXT(B2,4,2))Pour un texte au format JJ/MM/AAAA, inversez les positions du mois et du jour :
=DATE(DROITE(B2,4),STXT(B2,4,2),GAUCHE(B2,2))Ces vérifications ne résolvent pas l'intégralité de la comparaison. Elles empêchent seulement les problèmes d'import de se déguiser en écarts de frais.
Construisez une clé de liaison, ou admettez que vous n'en avez pas encore
Les comparaisons de frais échouent sur la référence avant l'arithmétique. Le rapport de ventes interne et le CSV de frais Stripe utilisent souvent des identifiants différents pour la même transaction.
Utilisez la liaison la plus solide disponible :
| Option de rapprochement | Fiabilité | Quand l'utiliser |
|---|---|---|
| Identifiant d'encaissement Stripe ou référence de paiement dans les deux fichiers | Maximale | Cas idéal. La ligne de frais peut être directement rattachée à la vente |
| Identifiant de commande intégré aux métadonnées Stripe et présent dans l'export | Élevée | Recommandé si votre plateforme envoie la même référence de commande à Stripe |
| Montant exact + date locale normalisée + devise | Moyenne | Solution de repli uniquement en l'absence de référence durable |
| E-mail client, nom du client ou totaux arrondis | Faible | Revue manuelle uniquement, jamais comme logique de rapprochement principale |
Si votre rapport de ventes interne ne contient que des numéros de commande et que votre export de frais Stripe ne contient que des identifiants d'encaissement Stripe, ces deux fichiers seuls ne permettent pas un rapprochement fiable ligne par ligne. Exportez un fichier de liaison qui associe la commande à l'encaissement Stripe. Sans cette liaison, la revue n'est défendable qu'au niveau des totaux agrégés.
Quand la clé existe mais que les types diffèrent, corrigez l'incompatibilité dans la formule de recherche avant de créer des colonnes auxiliaires. Si la référence interne en A2 est du texte et que la colonne clé côté Stripe est numérique :
=RECHERCHEX(CNUM(A2),Stripe!$F:$F,Stripe!$G:$G,"Aucune correspondance")Si la référence interne est numérique et que la clé côté Stripe est du texte :
=RECHERCHEX(TEXTE(A2,"0"),Stripe!$F:$F,Stripe!$G:$G,"Aucune correspondance")Ne comparez pas sur le montant brut seul, sauf si le fichier est très petit et que vous vérifiez chaque ligne manuellement.
Séparez les types de frais avant de conclure à des frais manquants
Un CSV de frais Stripe n'est pas une série de lignes « frais de traitement » répétées tout au long du mois. Si vous totalisez toutes les lignes de frais ensemble et que vous comparez ce total à une colonne de frais de traitement dans le rapport de ventes, vous surestimerez presque toujours l'écart.
Commencez par grouper les lignes de frais.
| Ligne de frais Stripe | Comparer directement aux ventes en cours dans le périmètre ? | Pourquoi |
|---|---|---|
| Frais de traitement sur un encaissement capturé | Oui | C'est le frais principal que la plupart des équipes s'attendent à voir face aux ventes en cours |
| Impact de frais lié à un remboursement ultérieur | À suivre séparément du total des ventes en cours | La vente peut avoir quitté le rapport en cours tandis que l'économie du frais d'origine reste pertinente |
| Frais transfrontaliers ou de conversion de devise | Poste séparé | Modifie le taux effectif et est souvent invisible dans les synthèses de ventes internes |
| Coût lié à un litige ou à un impayé | Poste d'exception distinct | C'est réel, mais ce n'est pas la même chose qu'un coût de traitement standard |
| Frais de produit non liés aux paiements ou frais de compte | À exclure de la comparaison frais-ventes | Ces frais appartiennent à une autre analyse de coûts, pas à un test de frais par vente |
Divisez le fichier selon ce qui a généré les frais avant de calculer quoi que ce soit.
Les rapports internes comptabilisent souvent une colonne de frais de traitement basée sur un taux attendu, tandis que l'export Stripe révèle des composantes supplémentaires qui n'ont jamais figuré dans cette estimation. L'inverse est aussi possible quand les fichiers utilisent des bases de période différentes. Dans les deux cas, c'est un problème de périmètre avant d'être un problème comptable.
Effectuez la comparaison qui identifie réellement les frais manquants ou sous-estimés
Une fois la période, le fuseau horaire, la base de montants et la clé de liaison stabilisés, la comparaison devient mécanique.
- Filtrez le CSV de frais Stripe sur la fenêtre de reporting en utilisant la date locale normalisée, pas le texte brut importé.
- Supprimez les lignes de frais qui n'appartiennent pas à la comparaison frais-ventes en cours.
- Associez chaque ligne de frais restante à la clé de liaison la plus solide disponible.
- Agrégez les lignes de frais Stripe au même niveau de granularité que le rapport de ventes interne.
- Comparez le frais comptabilisé en interne au total Stripe à ce même niveau.
- Classifiez chaque écart avant de corriger quoi que ce soit.
Un résultat utile ressemble à ceci :
| Clé de rapprochement | Vente brute dans le rapport | Frais dans le rapport interne | Frais dans le CSV Stripe | Écart | Ce que ça signifie généralement |
|---|---|---|---|---|---|
ORD-10428 | 120.00 | 3.78 | 3.78 | 0.00 | Correctement comptabilisé |
ORD-10429 | 240.00 | 5.20 | 6.10 | 0.90 | Le rapport interne a sous-estimé le frais réel |
ORD-10430 | 88.00 | 2.55 | 0.00 | 2.55 | Mauvaise période, mauvaise clé, ou ligne Stripe absente du périmètre |
ORD-09871 | 0.00 dans le rapport en cours | 0.00 | 3.40 | 3.40 | Frais rattaché à une vente qui a disparu du rapport ou a été remboursée |
| Aucune clé de liaison | 150.00 | 4.35 | 4.35 sur deux lignes Stripe | 0.00 total, mais non prouvé ligne par ligne | Le total de la période peut être juste même si la preuve par transaction est insuffisante |
C'est à ce stade que vous pouvez distinguer les vrais problèmes des écarts attendus :
- Un frais manquant est un frais présent dans Stripe, dans le périmètre, et sans montant correspondant dans le rapport interne ou la comptabilité.
- Un frais sous-estimé est un frais présent des deux côtés, mais dont le montant interne est inférieur parce qu'il a ignoré une partie du coût Stripe réel.
- Un écart de calendrier est un frais qui appartient à l'activité commerciale examinée mais tombe dans une autre fenêtre de reporting selon la base choisie.
- Un frais non prouvé est un frais dont le total semble juste mais qui ne peut pas être rattaché à une vente faute de clé de liaison.
Si votre rapport de ventes interne n'a pas de colonne de frais, utilisez les données de frais réels de Stripe pour identifier ce qui aurait dû être comptabilisé, puis mesurez l'écart par rapport aux charges ou provisions qui existent ailleurs dans vos enregistrements.
N'utilisez pas le pourcentage seul comme preuve. Le taux mixte n'est qu'un contrôle de vraisemblance à effectuer après que la comparaison ligne par ligne ou par groupe est classifiée.
Ce qu'une revue aboutie doit prouver
À la fin de la revue, vous devez pouvoir répondre à plus que « les totaux sont proches. »
| Question | Ce que la comparaison aboutie doit vous indiquer |
|---|---|
| Quelles ventes sont dans le périmètre ? | Période exacte, fuseau horaire et limite de devise utilisés |
| Quelles lignes de frais Stripe appartiennent à ces ventes ? | Ensemble des frais de traitement après séparation des lignes non comparables |
| Quels frais figurent déjà dans le rapport interne ? | Montant rapproché et nombre de lignes rapprochées ou total groupé |
| Quels frais sont manquants ou sous-estimés ? | Liste d'exceptions claire avec montant et raison probable |
| Quelles lignes ne peuvent toujours pas être prouvées ? | Transactions nécessitant un export de liaison ou une correction de périmètre |
Si les fichiers ne partagent pas de clé utilisable, filtrer davantage ne réglera pas le problème. Exportez le fichier de liaison ou acceptez que la comparaison ne soit défendable qu'au niveau des totaux agrégés.
Quand la routine fichier par fichier devient le vrai coût
Cela devient coûteux quand chaque clôture exige la même routine : normaliser les dates, corriger les types, séparer les catégories de frais, reconstruire la clé de rapprochement, agréger les lignes Stripe et expliquer les mêmes exceptions à chaque cycle.
