Écart entre analytique et Stripe : rapprocher les revenus

Les deux chiffres désignent-ils la même chose ?

Le tableau de bord analytique affiche 840 USD. Stripe affiche un autre total. Cet écart ne prouve pas encore que l’un des systèmes est défectueux. L’un peut compter les paiements clients réussis et l’autre un solde, un virement, une estimation de revenu récurrent ou une autre période. Le rapprochement commence par une définition, pas par la modification du plus petit chiffre.

Pour chaque rapport, notez métrique, compte, mode réel ou test, devise, périmètre produit, fuseau, bornes de dates et règle de remboursement. Consignez aussi sa dernière actualisation. Tant que ces éléments ne concordent pas, deux captures côte à côte comparent des libellés, pas des comptes rapprochés.

Séparez quatre vues financières

Pour analyser l’acquisition, une définition initiale utile est celle des encaissements bruts : montant des paiements réussis dans un périmètre donné. Les encaissements nets peuvent ensuite déduire les remboursements réussis selon une règle explicite. Ni l’un ni l’autre n’est automatiquement du bénéfice ou du chiffre d’affaires reconnu en comptabilité.

Un rapport de solde Stripe comprend les mouvements de solde dans la devise de règlement. Un virement représente une sortie d’argent avec son calendrier et son regroupement propres. Le MRR décrit un rythme de revenus d’abonnement, pas simplement l’argent encaissé ce mois-ci. Choisissez le rapport qui répond à la question au lieu d’exiger l’égalité de toutes les vues.

Stripe décrit Balance summary comme un rapport de rapprochement du solde et renvoie le rapprochement des virements automatiques vers un rapport distinct. Cette différence compte lorsque votre tableau marketing est organisé par date de paiement plutôt que de règlement.

Un rapprochement fictif vérifiable

L’exemple fictif en USD ci-dessous utilise la période des paiements et affecte les remboursements réussis à leur cohorte de paiement d’origine. Il exclut frais, corrections de taxes, litiges, conversion de devise et virements ; ajoutez des champs séparés si ces éléments relèvent de votre question. La règle explicite permet de reproduire le résultat.

A contribue pour 100 USD, pas 200 USD, même si sa notification est livrée deux fois. B contribue pour 40 USD après remboursement partiel réussi. Le remboursement demandé sur C reste en attente ; cet exemple ne le déduit donc pas des remboursements réussis. Affichez séparément le montant en attente au lieu de le masquer.

COHORTE FICTIVE DE PAIEMENTS, EN USD
Paiement  Encaissé  Remboursement réussi  En attente
A         100,00     0,00                  0,00
B          60,00    20,00                  0,00
C          40,00     0,00                 10,00

Encaissements bruts = 100 + 60 + 40 = 200 USD
Remboursements réussis = 20 USD
Net selon cette règle = 200 - 20 = 180 USD
En attente, présenté séparément = 10 USD

Comparez les objets de référence, pas les notifications

Stripe peut livrer des événements webhook en double et n’en garantit pas l’ordre de réception. Une intégration robuste vérifie les signatures, conserve les identifiants traités et met à jour des enregistrements de paiement ou de remboursement de référence, plutôt que d’ajouter un revenu à chaque notification. Plusieurs objets événement peuvent concerner le même objet sous-jacent : dédupliquer seulement les événements ne constitue pas un modèle financier complet.

Pour enquêter, exportez le plus petit ensemble d’écarts : compte du prestataire, mode, identifiant du paiement, devise, montant et horodatages pertinents. Comparez ces lignes au prestataire. Un paiement absent, un mauvais périmètre ou un enregistrement dupliqué est plus exploitable qu’un pourcentage d’écart dans un graphique.

Traitez la page de remerciement comme un événement d’interface, pas comme une autorité comptable. Elle peut être rechargée, bloquée ou jamais atteinte. L’état du paiement côté serveur doit établir la réussite financière.

Explicitez les règles de remboursement et de date

Une demande de remboursement n’est pas toujours un remboursement terminé. Stripe documente notamment les états en attente et en échec, et un paiement peut faire l’objet de remboursements partiels. Suivez identifiants et états actuels plutôt que de supposer que toute demande réduit immédiatement les encaissements achevés.

Choisissez entre deux questions. « Que s’est-il passé aujourd’hui ? » déduit les remboursements traités aujourd’hui des paiements traités aujourd’hui. « Combien cette cohorte d’acquisition a-t-elle conservé ? » relie les remboursements à la cohorte initiale. Les deux sont utiles, mais leurs totaux quotidiens diffèrent, surtout lorsqu’un ancien achat est remboursé.

Utilisez un intervalle semi-ouvert, début inclus et borne suivante exclue, pour ne pas compter deux fois un paiement à minuit. Distinguez heure de l’événement chez le prestataire et heure d’ingestion. Une livraison tardive relève de la règle temporelle métier définie, pas automatiquement du moment de réception par le traitement.

Conservez devises et périmètre produit

Les montants de l’API Stripe suivent des unités propres aux devises, avec devises sans décimales et cas particuliers. Ne divisez pas systématiquement par 100. Conservez la devise à côté de chaque montant et formatez selon la convention applicable.

N’additionnez pas USD et EUR dans un total sans libellé. Si une devise de reporting unique est nécessaire, précisez source de change, date et arrondi, et préservez les montants d’origine. Vérifiez aussi si le compte connecté contient d’autres produits : le revenu de tout le compte n’est pas automatiquement celui de votre SaaS.

Terminez par des exceptions expliquées

Classez les écarts restants : livraison tardive, remboursement non résolu, transaction de test exclue, mauvais produit, frontière de fuseau ou historique importé incomplet. Attribuez à chacun un identifiant et un responsable. Relancez la même comparaison après correction en conservant les preuves initiales.

Le rapprochement est terminé lorsque la population correspondante concorde selon les mêmes définitions et que les exceptions sont expliquées. L’attribution marketing peut encore manquer pour un vrai paiement. Gardez ce problème distinct : un total financier fiable n’exige pas d’inventer une source visiteur.

Références

• Stripe : signatures webhook, doublons et ordre de livraison
• Stripe : remboursements et états
• Stripe : montants et unités des devises
• Stripe : rapport Balance summary

Guides associés