FONDAMENTAUX

MRR et encaissements : que doit publier un SaaS ?

Distinguez revenu récurrent, encaissements, paiements annuels et offres à vie grâce à un exemple SaaS détaillé et des règles de reporting simples.

Publié le · Mis à jour le

Une métrique d’abonnement n’est pas un solde bancaire

Le revenu mensuel récurrent, ou MRR, mesure sur une base mensuelle normalisée la valeur des abonnements récurrents admissibles. Les encaissements mesurent les paiements réellement reçus pendant une période. Ils répondent à deux questions distinctes : « Quel est le rythme de revenu récurrent ? » et « Qu’ont payé les clients ? ». Aucun n’est, à lui seul, du bénéfice.

Un SaaS peut connaître un excellent mois d’encaissements sans forte croissance du MRR en vendant des offres annuelles ou un accès ponctuel. Un autre peut augmenter son MRR alors que les encaissements tardent, avec des factures impayées. Un rapport utile sépare ces mesures au lieu de choisir la capture d’écran la plus flatteuse.

Exemple original : ventes mensuelles, annuelles et à vie

L’exemple suivant est fictif. Supposons dix abonnés mensuels actifs à 20 USD, deux abonnés annuels à 180 USD et trois acheteurs d’accès à vie à 159 USD. Tous les paiements réussissent ce mois-ci ; taxes et frais sont exclus de cet exemple simplifié, sans remise ni remboursement.

Selon la définition de valeur récurrente retenue, les abonnements mensuels contribuent pour 200 USD au MRR et les annuels pour 30 USD, après division de 360 USD par douze. Les achats à vie n’ajoutent pas de MRR, puisqu’aucun paiement récurrent n’est prévu. Le MRR total vaut 230 USD. Les encaissements bruts du mois valent 1 037 USD, pas 230 USD.

Exemple fictif, en USD uniquement
10 mensuels x 20  = 200 encaissés | 200 de MRR
 2 annuels x 180  = 360 encaissés |  30 de MRR
 3 à vie x 159    = 477 encaissés |   0 de MRR
------------------------------------------------
Ce mois          = 1 037 encaissés | 230 de MRR
L’encaissement du mois prochain est inconnu : le MRR n’est pas garanti.

Pourquoi diviser tous les paiements par douze ne fonctionne pas

Un paiement annuel peut être normalisé en MRR parce qu’il achète une période d’abonnement récurrente définie. Diviser tous les encaissements par douze transformerait aussi les paiements mensuels et ventes ponctuelles en valeur récurrente fictive. De même, multiplier par douze un mois de lancement contenant des ventes à vie ne crée pas un revenu annuel récurrent.

Si vous publiez un rythme annualisé, indiquez la formule et sa base. La multiplication simple du MRR par douze est une projection à un instant donné, pas la preuve que les douze prochains mois encaisseront cette somme. Renouvellements, résiliations, changements de prix et échecs de recouvrement peuvent modifier le résultat.

Définissez remises, impayés et date de résiliation

Le MRR n’est pas calculé de manière parfaitement uniforme entre outils. Décidez si les remises récurrentes le réduisent, comment traiter les remises ponctuelles, quels états d’abonnement sont admissibles et quand retirer un abonnement impayé. Appliquez ensuite les mêmes règles à vos comparaisons.

Les analyses Billing de Stripe proposent des rapports de revenu récurrent et des définitions configurables. La documentation distingue analyse d’abonnement et enregistrements de paiement. Avant de rapprocher votre MRR de celui de Stripe, examinez les paramètres et mouvements d’abonnement au lieu de supposer qu’un total différent est forcément un défaut.

Une résiliation prévue à la fin d’une période déjà payée n’est pas non plus une fin d’accès immédiate. Un rapport clair peut montrer les résiliations prévues comme signal d’alerte tout en conservant la valeur récurrente active selon sa politique documentée. Ne comptabilisez pas une perte immédiate puis une seconde perte à l’échéance pour le même abonnement.

Le remboursement change les encaissements, pas forcément le MRR

Ajoutez à l’exemple précédent un remboursement fictif réussi de 20 USD. Les encaissements nets, définis comme paiements moins remboursements réussis, deviennent 1 017 USD. L’effet sur le MRR dépend de l’abonnement : un geste commercial avec service maintenu diffère d’une résiliation.

Demandes de remboursement, remboursements en attente et remboursements réussis ne sont pas interchangeables. Enregistrez l’état et décidez si le rapport classe le remboursement à sa date ou corrige la cohorte du paiement initial. Les deux vues peuvent être utiles, mais elles ne doivent pas partager un libellé inexpliqué.

Frais du prestataire, taxes, litiges et change constituent d’autres frontières. Un rapport marketing intitulé « encaissements nets » doit préciser ce qu’il soustrait. Ne l’appelez pas bénéfice ou revenu comptable s’il ne suit pas la définition financière correspondante.

Rendez visibles devise et définition temporelle

100 USD plus 100 EUR ne forment pas un total de 200 dans une devise unique pertinente. Présentez les devises séparément ou indiquez une source de conversion explicite, la date du taux et la règle d’arrondi. Les unités de l’API Stripe comportent également des cas particuliers : supposer que chaque entier représente des centimes peut corrompre le rapport.

Utilisez un fuseau nommé et un intervalle semi-ouvert, début inclus et fin exclue. Distinguez le MRR à la fin du mois des paiements sur tout le mois. Notez l’actualisation de chaque source : sinon, une mise à jour tardive d’un paiement ou abonnement peut ressembler à une variation soudaine de l’activité.

Un bilan hebdomadaire pour piloter

Gardez un bilan concis avec MRR de fin de période, variation par rapport au précédent instant comparable, paiements réussis de nouveaux clients, renouvellements, achats ponctuels, remboursements et encaissements nets par devise. Ajoutez séparément le nombre d’abonnements dont la fin est programmée. Il s’agit d’un modèle original de reporting, pas d’une affirmation que chaque outil fournit tous ces champs.

Pour chaque métrique, conservez un détail ou un export expliquant le total. Si le MRR monte mais que les encaissements baissent, vérifiez renouvellements annuels, échecs de paiement et dates avant de modifier l’acquisition. Si les encaissements bondissent avec un MRR stable, examinez la répartition entre ventes ponctuelles et récurrentes avant d’annoncer une croissance récurrente.

Reliez l’acquisition une fois les totaux compris

Lorsque les encaissements se rapprochent correctement, comparez la contribution des sources d’acquisition aux premiers achats et aux renouvellements. Explicitez la question : une source qui acquiert un client n’est pas automatiquement responsable de tous ses renouvellements à jamais. C’est une politique d’attribution, pas un fait fourni par le prestataire de paiement.

Le guide de rapprochement porte sur les paiements faisant autorité ; celui d’attribution explique le lien marketing. Ensemble, ils évitent le raccourci consistant à traiter conversions web, rythme d’abonnement et encaissements réels comme une seule et même mesure.

Références

Guides associés

Écart entre analytique et Stripe : rapprocher les revenus

Rapprochez vos données avec Stripe grâce aux identifiants, états de remboursement, devises et dates, sans confondre encaissements, virements et MRR.

Lire le guide →

Attribution des revenus : relier visites et paiements

Découvrez comment relier des visites à des paiements vérifiés, définir une règle d’attribution et rendre visibles sources manquantes, remboursements et devises.

Lire le guide →

Analyse web pour SaaS : mesurer pour décider

Construisez un plan de mesure SaaS utile : acquisition, activation, paiements vérifiés et qualité des données, avec un exemple et un bilan hebdomadaire.

Lire le guide →

Exemple à visée pédagogique. Les données et calculs d’exemple ne représentent pas des résultats commerciaux vérifiés.

Le site public et les articles sont traduits. L’espace de travail privé est actuellement en anglais.