Table des Matières
Si votre MRR dans Stripe ne correspond pas à ce que rapporte votre équipe financière, les chiffres ne sont probablement pas erronés : ils répondent à des questions différentes.
Les processeurs de paiement, les app stores et les plateformes de facturation appliquent chacun leurs propres règles sur le moment où le revenu compte, si les abonnements en pause et en retard restent dans le total, et ce qu'est un « client ». Les réconcilier signifie recalculer à partir des états d'abonnement bruts au même endroit, sans faire la moyenne des tableaux de bord.
Les quatre raisons pour lesquelles les chiffres divergent
1. Moment de la reconnaissance. Une plateforme rapporte le revenu quand la facture est envoyée ; une autre le rapporte quand le paiement est encaissé. D'un côté du mois à l'autre, cela suffit à écarter deux tableaux de bord exacts de plusieurs milliers de dollars.
2. Les comptes en retard et en pause restent dans le MRR. La plupart des outils de gestion d'abonnements comptent chaque abonnement existant dans le revenu mensuel récurrent, y compris les comptes en retard de paiement ou temporairement en pause. L'abonnement existe, donc il est compté, ce qui explique exactement pourquoi le revenu rapporté dépasse le revenu collecté.
3. Pas de définition partagée du mouvement MRR. Les nouveaux MRR, les MRR d'expansion, de réactivation, de contraction et de churn sont des catégories distinctes. Les processeurs de paiement enregistrent les transactions ; ils ne les divisent pas par type de mouvement, donc une mise à niveau et une nouvelle inscription peuvent se retrouver dans le même bucket.
4. Identité client par plateforme. La même personne s'abonnant via votre site web et votre app iOS est deux dossiers clients dans deux systèmes, car aucun système ne peut voir l'autre. Chaque plateforme compte un client ; ensemble elles en rapportent deux. Baremetrics apparie les dossiers sur l'adresse e-mail et les fusionne en un seul client qui vous paie deux fois, ce qui maintient le nombre de clients, ARPU, et la LTV sans dérive au moment où vous ajoutez une deuxième source de facturation. La limite est utile à connaître : si quelqu'un s'inscrit sur votre site avec une adresse professionnelle et achète l'abonnement à l'app avec un identifiant Apple personnel, il n'y a rien à appairer et ils restent deux dossiers.
À quoi cela ressemble en chiffres
La raison pour laquelle cela compte plus qu'un simple argument d'arrondi est que les erreurs vont dans des directions opposées. Voici un exemple travaillé — chiffres illustratifs, pas de données clients :
Une entreprise SaaS facture via Stripe et l'App Store.
| Stripe | App Store | |
| Abonnements actifs rapportés | 412 | 190 |
| Revenu d'abonnement rapporté | $61,800 | $14,200 |
| En retard (échoué, pas encore annulé) | 18 abonnements / 2 700 $ | — |
| En pause | 9 abonnements / 1 350 $ | — |
Additionnez les deux tableaux de bord et vous obtenez 76 000 $ MRR sur 602 clients, ou 126,25 $ ARPU.
Maintenant, corrigez les deux problèmes. Supprimez les abonnements en retard et en pause que Stripe compte toujours : 61 800 $ − 2 700 $ − 1 350 $ = $57,750 de revenu récurrent collectible. Puis supprimez les 61 personnes qui s'abonnent sur les deux plateformes avec le même e-mail : 602 − 61 = 541 clients réels.
Corrigé : 71 950 $ MRR sur 541 clients, soit 132,99 $ ARPU.
Donc la somme naïve surestime le MRR de 4 050 $ et des sous-estime l'ARPU d'environ 5 %. Deux erreurs, signes opposés, l'une d'elles flatteuse — c'est pourquoi additionner les tableaux de bord semble assez proche jusqu'au moment où vous utilisez l'ARPU pour modéliser le délai de récupération sur les dépenses d'acquisition.
Ce que chaque source rapporte réellement
| Source | Ce qu'elle vous donne | Ce qu'elle ne donne pas |
| Stripe | Dossiers de transactions, métadonnées complètes, attributs client, frais | Cohortes de churn, MRR d'expansion, prévisions |
| Braintree, Chargebee, Recurly | États d'abonnement, facturation | Définitions MRR cohérentes entre les plateformes |
| Apple App Store Connect | Rapports et événements d'abonnés | Détails au niveau des clients comparables à Stripe |
| Google Play | Rapports et événements d'abonnés | Configuration clés en main — la connexion peut nécessiter du temps d'ingénierie |
| Shopify Partners (tableau de bord natif) | Installations, évaluations, état de publication, revenu à vie | Toute métrique de revenu récurrent pour votre app |
| QuickBooks, Xero | Comptabilité, dépenses, compte de résultat | Mouvement des revenus au niveau de l'abonnement |
Deux mises en garde qui piègent les gens. Les revenus Shopify s'écoulent dans le MRR mais Les frais Shopify sont exclus, donc le revenu net inclusif des frais ne correspondra pas aux propres rapports de Shopify. Et QuickBooks et Xero sont des sources comptables, pas des sources de facturation — connecter l'une d'elles ne remplace pas une intégration de facturation, bien que Forecast+ en exige une pour modéliser la piste et les dépenses.
Quelles sources connecter
| Si vous vendez par… | Connecter | Pourquoi |
| Votre site uniquement | Votre plateforme de facturation | Source unique, pas de rapprochement nécessaire |
| Site + applications mobiles | Plateforme de facturation + Apple App Store Connect + Google Play | Les abonnés mobiles se désabonnent selon une courbe différente que le web |
| Une application Shopify | Shopify Partners + votre plateforme de facturation | Le tableau de bord des partenaires rapporte les revenus à vie, pas le MRR |
| Migration des plateformes de facturation | Les deux, par le chevauchement | Empêche la transition de se lire comme un pic de désabonnement |
| Un processeur sans connecteur natif | API ouverte ou importation CSV | Environ une journée d'ingénierie pour le chemin API |
Connectez chaque plateforme sur laquelle vous facturez, même les mineures. Une source représentant 3 % des revenus distord toujours le taux de désabonnement mixte si elle manque.
Baremetrics normalise chaque source connectée dans un MRR unifié unique et rapporte plus de 28 métriques d'abonnement par rapport à celui-ci, avec l'option de segmenter par source. Pour les processeurs non pris en charge, il y a trois solutions de secours : l' API ouvert (environ une journée de travail d'ingénierie), l'importation CSV pour les données historiques et les contrats ponctuels, et l'entrée manuelle d'abonnement dans le tableau de bord. Pour la liste d'intégration complète et les étapes de configuration, voir Comment connecter plusieurs sources de données dans Baremetrics.
Séparé des sources de revenus, quelques connecteurs changent ce que vous pouvez faire avec les données unifiées plutôt que ce qui y entre : HubSpot synchronise les attributs CRM dans les deux sens afin qu'ils soient utilisables comme segments, QuickBooks et Xero alimentent la piste et les dépenses via Forecast+, Intercom affiche le contexte d'abonnement dans les conversations d'assistance, Slack fournit des résumés de métriques, Zapier gère l'importation et l'exportation d'attributs, et un serveur MCP expose vos métriques aux outils d'IA comme Claude et Cursor.
Comparaison des performances entre les plateformes
Une fois les sources unifiées, le mouvement utile n'est pas le nombre mixte — c'est la répartition. Les abonnés de l'app store et les abonnés de facturation directe diffèrent généralement sur la rétention, le revenu moyen et revenu mensuel récurrent d'expansion, et l'écart est souvent assez important pour changer l'orientation des dépenses marketing. Chaque métrique peut être limitée à une seule source, et les segments peuvent être construits à partir des métadonnées Stripe, des données des abonnés Apple et Google, des attributs HubSpot, des données Intercom ou des attributs personnalisés poussés via l'API.
Comparaison des outils sur le support multi-source
Le support multi-source est l'un des rares domaines où les outils d'analyse d'abonnement diffèrent véritablement — moins dans la question de savoir s'ils peuvent unifier les sources que dans les plateformes qu'ils atteignent et ce que vous pouvez faire avec le résultat.
| Baremetrics | ChartMogul | |
| Sources de facturation natives | Stripe, Braintree, Chargebee, Recurly, Apple App Store, Google Play, Shopify Partners | Stripe, Chargebee, Paddle, Recurly, Braintree, PayPal, GoCardless et plus |
| MRR unifié + segment par source | Oui | Oui |
| Relance native sur sources unifiées | Oui — Stripe, Braintree, Recurly | Non — via des partenaires tiers |
| Prévisions financières à partir de données comptables | Oui — Forecast+ avec QuickBooks ou Xero | Non |
| Exporter les données unifiées vers un entrepôt de données | Non | Oui — Snowflake, BigQuery, Redshift, S3, Azure (Pro et supérieur) |
Résumé honnête : ChartMogul atteint davantage de plateformes de facturation natives, notamment PayPal et GoCardless, et peut pousser les données unifiées dans un entrepôt de données. Baremetrics va plus loin une fois les données unifiées — récupération native des paiements échoués et prévisions financières à partir de votre compte de résultat réel, dans le même outil plutôt que d'être ajoutée après coup.
À savoir que la qualité du rapprochement est un véritable différenciateur ici et pas seulement une affirmation marketing : la critique récurrente dans les avis publics de ChartMogul sur G2 et Product Hunt est que ses chiffres ne correspondent pas à ceux de Stripe et nécessitent une correction manuelle. C'est le mode de défaillance que cette catégorie entière est censée prévenir, donc il vaut la peine de tester sur vos propres données pendant un essai quelconque plutôt que de prendre la parole de l'un ou l'autre fournisseur.
Où cette approche a des limites
Être honnête à propos des contraintes :
- PayPal et GoCardless n'ont pas de connecteur natif. Il en va de même pour Paddle, Maxio ou Zuora. Les revenus facturés par leur intermédiaire entrent via l'API ouverte — environ une journée d'ingénierie — ou par CSV.
- Aucune exportation d'entrepôt de données. Si votre équipe envisage de placer les données d'abonnement unifiées dans Snowflake ou BigQuery aux côtés des données produit, Baremetrics n'offre actuellement pas cette solution.
- Recover ne couvre pas toutes les sources. La récupération des paiements échoués fonctionne uniquement sur Stripe, Braintree et Recurly. Chargebee est une source de données prise en charge mais pas une source Recover, tout comme les app stores ou Shopify Partners — les revenus de ces plateformes sont donc unifiés dans vos mesures tandis que le churn involontaire doit être géré ailleurs.
- La réconciliation ne corrige pas les données en amont. Si une plateforme de facturation a mal étiqueté les états d'abonnement, l'unification des sources expose le problème plutôt que de le résoudre.
Questions fréquemment posées
-
Pourquoi mon MRR dans Stripe ne correspond-il pas à ce que mon équipe financière signale ?
Stripe est d'abord un processeur de paiement, donc son chiffre de MRR compte les abonnements actifs — y compris les comptes en pause et les intervalles de délinquance non résolus — plutôt que les revenus récurrents collectés. Les équipes financières les éliminent généralement, d'où le décalage. Baremetrics recalcule le MRR à partir des états d'abonnement et sépare les nouveaux, expansions, réactivations, contractions et MRR résiliés en catégories distinctes, afin que le chiffre rapporté reflète les revenus que vous avez réellement collectés.
-
Quels outils d'analyse d'abonnement peuvent unifier plus d'une source de facturation ?
Baremetrics et ChartMogul se connectent à plusieurs sources de facturation et les normalisent en un seul chiffre de MRR, avec la possibilité de les segmenter à nouveau par source. La différence pratique est la couverture et ce qui se passe ensuite : ChartMogul atteint plus de plateformes de facturation natives, y compris PayPal et GoCardless, tandis que Baremetrics ajoute une récupération native des paiements échoués et des prévisions financières en plus des données unifiées. Vérifiez les détails du plan actuel de chaque vendeur pour savoir combien de sources votre niveau inclut, car cela varie et change.
-
Puis-je voir le MRR séparément pour les abonnés de l'app store par rapport aux clients qui achètent directement sur mon site ?
Oui. Chaque mesure peut être filtrée sur une seule source connectée, afin que vous puissiez comparer la rétention, l'ARPU et l'expansion du MRR pour les abonnés de l'App Store ou de Google Play par rapport à vos clients de facturation directe. C'est important car les abonnés mobiles et web se comportent rarement de la même façon, et un nombre fusionné cache cela. Les équipes utilisent généralement cette répartition pour décider quel canal d'acquisition mérite plus de dépenses.
-
Si le même client s'abonne via deux plateformes, suis-je compté en double ?
Non. Baremetrics fait correspondre les enregistrements de clients entre les sources connectées sur l'adresse e-mail, de sorte que quelqu'un avec un abonnement au site web facturé via Stripe et un deuxième abonnement via l'App Store est fusionné en un seul client vous payant deux fois, plutôt que deux clients payant une seule fois chacun. Le nombre de clients est le dénominateur de l'ARPU, LTV, et le taux de churn, donc compter une personne deux fois réduit l'ARPU et sous-estime la valeur à vie sur toute votre base. Cela signifie également qu'un client qui annule l'un des deux abonnements se lit comme une contraction plutôt que comme un événement de churn, ce qui s'est réellement produit. L'exception est un client qui a utilisé des adresses e-mail différentes sur chaque plateforme — sans identifiant commun, ces enregistrements restent séparés.
-
La connexion d'une deuxième plateforme de facturation en milieu d'année casse-t-elle mes lignes de tendance historiques ?
Non. Baremetrics extrait l'historique complet des transactions d'un processeur de paiement lorsque vous le connectez, et non seulement l'activité à partir de la date de connexion. Donc ajouter une source en juillet rétrospectif complète l'historique complet de cette plateforme plutôt que de commencer une nouvelle ligne à zéro, et vos graphiques de rétention de cohorte et les graphiques de mouvement du MRR s'approfondissent au lieu de se réinitialiser. C'est aussi pourquoi connecter une plateforme sur laquelle vous avez facturé pendant des années vaut le coup même si vous l'abandonnez.
-
Puis-je exporter les données d'abonnement unifiées dans un entrepôt de données ?
Pas avec Baremetrics. Il n'y a pas de poussée native vers Snowflake, BigQuery, Redshift, S3 ou Azure, donc les équipes qui ont besoin de données d'abonnement unifiées à côté des données produit dans un entrepôt devront construire ce chemin via l'API. ChartMogul propose des exportations d'entrepôt natives sur ses plans Pro et Enterprise, ce qui est un avantage réel pour les équipes matures en données disposant d'outils BI existants.
-
Que se passe-t-il pour ma déclaration de revenus lorsque je migre d'une plateforme de facturation à une autre ?
Connectez les deux plateformes et gardez-les connectées pendant la période de chevauchement. Si vous déconnectez l'ancienne source au moment du basculement, chaque abonnement dessus se lit comme résilié et votre taux de churn augmente pendant un mois qui n'a eu aucune annulation réelle. Exécuter les deux sources pendant la transition maintient l'intégrité des historiques d'abonnement afin que la migration ne s'affiche pas comme un événement de revenus.
