Demandez à un fondateur de SaaS en 2022 combien de revenus il enregistrerait ce mois-ci, et la réponse était une formule de feuille de calcul : nombre de sièges multiplié par le prix, au prorata des jours restants dans le contrat. Posez la même question à un fondateur d'entreprise d'IA native aujourd'hui, et la réponse honnête est "cela dépend de l'utilisation du modèle par nos clients". La consommation de jetons peut doubler en une semaine lorsqu'un client met une fonctionnalité en production, ou stagner lorsqu'il met une expérience en pause. Il n'y a pas de nombre de sièges pour ancrer la prévision.
Ce passage de l'abonnement à la consommation n'est pas seulement une décision de tarification. C'est un problème comptable, et il s'inscrit pleinement dans la norme ASC 606 — la même norme de reconnaissance des revenus qui régit le SaaS depuis 2018, mais appliquée à un facteur beaucoup moins prévisible. Si vous vous trompez, vous n'êtes pas confronté à une erreur d'arrondi ; vous êtes confronté à un exercice financier révisé pendant la vérification diligente, au moment même où vous pouvez le moins vous le permettre.
Pourquoi la tarification basée sur les jetons rompt avec l'ancien modèle
La reconnaissance traditionnelle des revenus SaaS est relativement indulgente. Un client paie 12 000 par mois, et la décision la plus délicate est de savoir si une modification de contrat nécessite une réaffectation. La contrepartie est fixe. L'obligation de performance — l'accès au logiciel au fil du temps — est simple. Les auditeurs ont vu un millier de contrats similaires.
L'IA et la tarification basée sur l'utilisation suppriment la partie fixe. Les clients paient pour les jetons traités, les appels API effectués, les exécutions d'inférence terminées ou les secondes de calcul consommées. Cette contrepartie est variable par conception, et l'ASC 606 contient une section entière — les directives relatives à la "contrepartie variable" dans l'ASC 606-10-32-11 à 32-13 — consacrée précisément à ce problème. Le défi principal n'est pas philosophique, il est pratique : combien de revenus reconnaissez-vous au cours d'une période lorsque vous ne savez pas réellement, au moment où vous clôturez vos comptes, exactement combien un client finira par devoir ?
Pour une entreprise d'IA en phase de démarrage, cela devient plus difficile avant de devenir plus facile. Une entreprise SaaS mature peut s'appuyer sur des années d'historique d'utilisation pour estimer la consommation avec confiance. Une entreprise qui a lancé son modèle de tarification basé sur les jetons il y a huit mois n'a pas de comparables de ce type. L'utilisation peut varier considérablement à mesure que les clients passent de la phase pilote à la production, et le modèle du trimestre dernier peut en dire peu sur celui de ce trimestre.
Les deux formes de contrats qui déterminent tout
Avant de pouvoir reconnaître correctement un dollar de revenu basé sur l'utilisation, vous devez savoir laquelle des deux structures vous utilisez réellement — car elles sont comptabilisées différemment.
Consommation pure, sans minimum engagé. Le client achète un pool de crédits ou accepte de payer par unité consommée, sans seuil minimum. Si l'arrangement est un service direct (vous fournissez un accès à un modèle hébergé, et non une licence de propriété intellectuelle que le client exploite indépendamment), vous ne pouvez généralement pas utiliser l'exception étroite des "redevances basées sur l'utilisation de la propriété intellectuelle" de l'ASC 606-10-55-65 — celle-ci est conçue pour les accords de licence comme les redevances sur un brevet, et non pour une API hébergée. Au lieu de cela, vous estimez la contrepartie variable en utilisant la méthode de la valeur attendue ou du montant le plus probable, sous réserve de la contrainte que vous ne devriez pas reconnaître des montants où un "redressement significatif" est probable une fois l'incertitude résolue.
Minimum engagé plus dépassement. Le client s'engage à, par exemple, 2 000 $ par mois d'utilisation et paie plus s'il le dépasse. Ici, le seuil se comporte comme une contrepartie fixe — reconnaissez-la de manière systématique à mesure que le client reçoit de la valeur — tandis que tout ce qui dépasse le minimum est une contrepartie variable soumise aux mêmes règles d'estimation et de contrainte. Cet hybride apparaît constamment dans la tarification de l'IA : des frais de plateforme de base plus une inférence mesurée en sus.
Savoir quelle forme vous utilisez modifie vos écritures de journal, vos notes de bas de page des divulgations, et à quel point votre auditeur devrait être inquiet concernant vos estimations.
L'expédient pratique que la plupart des entreprises d'IA utilisent réellement
Voici la bonne nouvelle : l'ASC 606 contient un raccourci conçu précisément pour cette situation, et la plupart des contrats basés sur l'utilisation bien structurés y sont éligibles.
L'expédient pratique du "droit de facturer" (ASC 606-10-55-18) vous permet d'éviter complètement d'estimer la contrepartie totale du contrat. Si ce que vous facturez chaque période correspond directement à la valeur que le client a reçue au cours de cette période — vous avez facturé 0,002 — vous pouvez simplement reconnaître ces 8 $ comme revenus dans la période où ils ont été gagnés. Pas de prévisions, pas d'analyse des contraintes, pas de réestimation à chaque clôture.
La difficulté réside dans la phrase "correspond directement". Si votre tarification comporte des paliers où le taux par unité diminue à mesure que le volume augmente, ou des remises groupées qui ne correspondent pas clairement à la période au cours de laquelle l'utilisation a eu lieu, l'expédient peut échouer — le montant facturé ne représente plus la valeur de cette période, et vous êtes de retour à l'estimation complète de la contrepartie variable. Revoyez votre structure de tarification en gardant spécifiquement ce critère à l'esprit avant de supposer que l'expédient s'applique uniformément à l'ensemble de votre portefeuille de contrats.
La plupart des contrats d'IA basés sur la consommation sont également éligibles au traitement en série en vertu de l'ASC 606-10-25-14 : au lieu de comptabiliser chaque appel API comme sa propre micro-obligation de performance, vous traitez l'ensemble du flux d'utilisation comme une seule obligation de performance satisfaite au fil du temps. C'est ce qui rend l'expédient de facturation administrativement réalisable — vous ne suivez pas des milliers d'obligations individuelles, vous suivez un service continu avec un prix variable.
Crédits Prépayés : Revenus Différés et le Problème des Crédits Non Utilisés (Breakage)
De nombreuses plateformes d'IA vendent des packs de crédits prépayés — achetez 500 $ de jetons à l'avance, utilisez-les au cours des mois suivants. Cette structure est populaire car elle améliore la trésorerie et fidélise les clients, mais elle introduit deux obligations comptables que les fondateurs négligent régulièrement.
Les revenus différés sur le solde inutilisé. Au moment où l'argent est perçu pour un pack prépayé, rien n'est encore considéré comme revenu. C'est un passif — vous devez au client soit le service, soit un remboursement. Les revenus ne passent de la ligne des revenus différés au compte de résultat qu'à mesure que les jetons sont réellement consommés. Un fondateur qui enregistre l'intégralité des 500 $ le jour de leur encaissement surestime les revenus et devra corriger cela, généralement au pire moment possible : lors de la diligence raisonnable pour une levée de fonds, lorsqu'un auditeur reconstruit le calendrier et retire la différence d'une période déjà présentée aux investisseurs.
Les crédits non utilisés (breakage). Certains clients achètent un pack de crédits et ne l'utilisent jamais entièrement avant son expiration. Ce solde inutilisé — le breakage — n'est pas simplement de l'argent gratuit que vous comptabilisez le jour de l'expiration des crédits. Selon l'ASC 606, vous êtes censé estimer le taux de crédits non utilisés (breakage) à partir des modèles historiques de rachat et comptabiliser ce breakage estimé de manière proportionnelle, comme une légère augmentation des revenus parallèlement à l'utilisation réelle, plutôt que d'attendre l'expiration pour tout enregistrer d'un coup. Si vous n'avez pas encore d'historique de rachat (ce qui est courant pour un nouveau programme de crédits), l'approche prudente consiste à attendre d'en avoir un, en ne reconnaissant le breakage qu'à l'expiration entre-temps, et à revoir la politique une fois que vous disposez de quelques cohortes de données.
Là où la discipline des contraintes compte réellement
La "contrainte" sur la contrepartie variable semble abstraite jusqu'à ce que vous ayez vécu un trimestre où l'utilisation d'un gros client a quadruplé puis est revenue à la normale. L'ASC 606 vous demande d'inclure la contrepartie variable dans votre estimation de revenus seulement dans la mesure où il est probable qu'une annulation significative ne sera pas nécessaire ultérieurement. En pratique, cela signifie :
- Première année d'un nouveau modèle de tarification : soyez conservateur. Comptabilisez les minimums engagés et les montants réels avec confiance ; traitez toute projection au-delà de l'utilisation facturée/réelle avec un réel scepticisme, car vous n'avez pas de contrats comparables sur lesquels vous baser.
- À mesure que l'historique d'utilisation s'accumule : votre contrainte peut s'assouplir, car vous disposez maintenant d'une base défendable (l'utilisation de ce client a varié entre X et Y pendant six mois consécutifs) pour une estimation plus précise.
- À chaque clôture : réestimez. La contrepartie variable n'est pas un chiffre "défini une fois pour toutes" — elle est réexaminée à chaque période de rapport à mesure que de nouvelles informations apparaissent, avec l'ajustement cumulatif de rattrapage passant par la période actuelle.
Pour une équipe financière gérant cela sur des centaines ou des milliers de contrats, la solution opérationnelle consiste à aligner votre système de facturation et votre registre de reconnaissance des revenus avant la clôture, et non après — de sorte que les données d'utilisation se réconcilient automatiquement au lieu de nécessiter une piste d'audit manuelle à chaque fin de mois.
Pourquoi cela est important même si vous êtes petit
Si vous êtes une startup d'outils d'IA de deux personnes facturant une poignée de clients par jeton, il est tentant de considérer tout cela comme "le genre de chose dont nous nous occuperons lorsque nous lèverons une Série A." C'est un risque réel. Les erreurs de reconnaissance des revenus sont l'une des constatations les plus courantes lors de la diligence raisonnable pour une levée de fonds SaaS, et la tarification basée sur l'utilisation multiplie le nombre de décisions que l'auditeur voudra voir documentées : quels contrats utilisent l'expédient de facturation, quel taux de crédits non utilisés (breakage) vous avez supposé et pourquoi, comment vous avez géré le trimestre où l'utilisation d'un client a grimpé en flèche.
Appliquer les bonnes mécaniques dès le premier jour — même à petite échelle — signifie que vous ne reconstruirez pas dix-huit mois d'historique de revenus sous la pression des délais plus tard. Cela signifie également que les chiffres que vous utilisez en interne pour prendre des décisions en matière de tarification et d'embauche sont réellement précis, plutôt qu'gonflés par des revenus différés non reconnus là où ils ne devraient pas l'être.
Gardez vos comptes aussi clairs que votre modèle de tarification
La tarification basée sur l'utilisation et les jetons est effectivement plus complexe à comptabiliser qu'un abonnement mensuel fixe, mais cette complexité est vérifiable — elle exige simplement de documenter votre structure contractuelle, votre logique de contrainte et vos hypothèses de crédits non utilisés (breakage) au fur et à mesure, plutôt que de les ajuster après coup. La comptabilité en texte brut de Beancount.io rend cette piste de documentation explicite : chaque écriture de reconnaissance des revenus, chaque solde de revenus différés et chaque ajustement de crédits non utilisés (breakage) se trouve dans un texte versionné que vous (ou votre auditeur) pouvez retracer ligne par ligne, plutôt que d'être enfoui dans une plateforme de facturation opaque. Commencez gratuitement et gardez votre grand livre aussi transparent que le modèle de tarification que vous construisez.