Calculateur de run rate de sortie

Un revenu mensuel négatif est rejeté avec invalid_input, car un run rate n'est pas défini pour un carnet récurrent négatif.

Comment le revenu récurrent du dernier mois devient un run rate de sortie

L'identité utilisée par ce calculateur est exit_rate égal à monthly_revenue fois douze. monthly_revenue est le revenu récurrent du dernier mois dans une seule devise — pour une activité d'abonnement, le revenu récurrent mensuel, ou MRR —, mais la même identité s'applique à tout carnet récurrent que vous mesurez déjà au rythme mensuel : honoraires de retenue, contrats de maintenance ou usage facturé converti en un run mensuel. Un revenu mensuel négatif n'est pas un run rate légitime : un carnet récurrent négatif annualiserait un chiffre annuel absurde, donc la tâche échoue avec invalid_input plutôt que de renvoyer une annualisation signée qu'un modèle pourrait traiter comme un vrai ARR de sortie.

Contrat d'entrée, forme de la réponse et comportement d'erreur

Zéro est autorisé : un mois avant revenus produit encore un run rate de sortie fini de zéro plutôt qu'une erreur. Un mois fractionnaire tel que mille deux cent trente-quatre point cinquante-six s'annualise à quatorze mille huit cent quatorze point soixante-douze avec le même arrondi half-up monétaire. Envoyez par POST un corps JSON avec un nombre fini obligatoire : monthly_revenue, le revenu récurrent du mois final dans une seule devise. Les alias mrr, monthly_recurring_revenue, last_month_revenue et recurring_revenue pointent vers le même champ pour que la feuille conserve le nom de ses colonnes. Le champ peut arriver comme nombre JSON ou comme chaîne numérique. Les champs manquants, les chaînes vides et les valeurs non finies — NaN, Infinity ou un texte qui ne s'interprète pas comme un nombre — échouent avec invalid_input en nommant monthly_revenue. Ces échecs ne sont pas facturés. Un monthly_revenue négatif échoue car le run rate de sortie n'est pas défini pour un revenu mensuel négatif ; le message nomme le champ pour qu'un formulaire puisse marquer ce contrôle plutôt qu'une alerte générique. Si la validation passe, le corps répète monthly_revenue, indique months_per_year comme douze afin que le client n'ait pas à figer la convention, renvoie exit_rate comme monthly_revenue fois douze arrondi half-up à deux décimales, et inclut une chaîne de formule qui réaffirme l'identité. Exemple : cinquante mille de revenu récurrent du dernier mois donnent months_per_year de douze et un exit_rate de six cent mille. Associez le JSON à votre propre règle sur le mois de sortie et les lignes qui comptent comme récurrentes — l'usage facturé, les services professionnels ponctuels et le revenu différé ne sont pas le même carnet — car cet endpoint multiplie le seul nombre que vous envoyez ; il ne reconstruit pas un grand livre de facturation, ne choisit pas une convention de reconnaissance et n'interroge pas un processeur de paiement.

Où un calculateur de taux de sortie crée de la valeur

Les opérateurs qui clôturent un mois utilisent un calculateur de taux de sortie pour transformer le revenu récurrent du dernier mois en une seule ligne annuelle comparable avant d'ouvrir un modèle ARR complet ou un mémo de levée. Les équipes d'opérations revenus et de relation investisseurs versent le MRR de l'export de facturation dans cette identité et comparent ce run rate de sortie à la rétention nette des revenus et à une marche booked versus billed, au lieu de traiter l'un de ces outils comme un substitut. C'est une recherche et un travail différents de l'ARR des douze derniers mois, de la rétention nette des revenus, d'un score de la règle des quarante et d'une annualisation simple d'un revenu total qui n'est pas récurrent : ces outils partent d'autres lignes et répondent à d'autres questions. Une validation en échec ne consomme pas de solde. Les fondateurs et les partenaires financiers relancent le même champ lorsqu'un dossier de conseil, une data room ou un term sheet demandent l'ARR de sortie, puis épinglent exit_rate à côté d'une reconstruction des douze derniers mois pour que chaque mémo parte d'une seule annualisation d'entrée plutôt que d'un chiffre mensuel non encore mis à l'échelle. Comme l'implémentation est du parse pur de niveau A, chaque appel réussi coûte le tarif de base publié $0.002 sans jetons de modèle ni réseau sortant. Conservez monthly_revenue fini et non négatif, épinglez dans les tests l'exit_rate arrondi, et vous obtenez une annualisation du dernier mois reproductible pour des teasers, des plugins LMS et des workers de bord sans dresser un grand livre à vous.