Pregunteu a un fundador de SaaS el 2022 quants ingressos registraria aquest mes, i la resposta era una fórmula de full de càlcul: seients per preu, prorratejat pels dies restants del contracte. Pregunteu la mateixa pregunta avui a un fundador nadiu d'IA, i la resposta honesta és "depèn de quant els nostres clients hagin utilitzat el model". El consum de tokens es pot duplicar en una setmana quan un client posa una funció en producció, o estancar-se quan pausa un experiment. No hi ha un recompte de seients al qual ancorar la previsió.
Aquest canvi de la subscripció al consum no és només una decisió de preus. És un problema comptable, i s'enquadra directament dins de l'ASC 606 —el mateix estàndard de reconeixement d'ingressos que ha regit el SaaS des del 2018, només que aplicat a una entrada molt menys previsible. Si us equivoqueu, no us trobareu davant d'un error d'arrodoniment; us trobareu davant d'un any reafirmat durant la due diligence, just quan menys us ho podeu permetre.
Per què la fixació de preus basada en tokens trenca l'antic model
El reconeixement tradicional d'ingressos de SaaS és relativament indulgent. Un client paga 12.000 dòlars per un pla anual, reconeixeu 1.000 dòlars al mes, i la decisió més important és si una modificació del contracte requereix una reassignació. La contraprestació és fixa. L'obligació de rendiment —l'accés al programari al llarg del temps— és senzilla. Els auditors han vist mil contractes exactament iguals.
La IA i la fixació de preus basada en l'ús eliminen la part fixa. Els clients paguen pels tokens processats, les trucades a l'API realitzades, les execucions d'inferència completades o els segons de càlcul consumits. Aquesta contraprestació és variable per disseny, i l'ASC 606 té una secció sencera —la guia de "contraprestació variable" a l'ASC 606-10-32-11 a 32-13— dedicada exactament a aquest problema. El repte principal no és filosòfic, és pràctic: quants ingressos reconeixeu en un període quan realment no sabeu, en el moment de tancar els vostres llibres, exactament quant acabarà devent un client?
Per a una empresa d'IA en fase inicial, això es fa més difícil abans que es faci més fàcil. Una empresa de SaaS madura pot recolzar-se en anys d'historial d'ús per estimar el consum amb confiança. Una empresa que va llançar el seu model de preus basat en tokens fa vuit mesos no té tals comparables. L'ús pot variar molt a mesura que els clients passen de la prova pilot a la producció, i el patró del trimestre passat pot dir poc sobre el d'aquest trimestre.
Les Dues Formes de Contracte que ho Determinen Tot
Abans de poder reconèixer correctament un dòlar d'ingressos basats en l'ús, heu de saber en quina de les dues estructures us trobeu realment, ja que es comptabilitzen de manera diferent.
Consum pur, sense mínim compromès. El client compra un conjunt de crèdits o acorda pagar per unitat consumida, sense un límit inferior. Si l'acord és un servei senzill (proporcioneu accés a un model allotjat, no llicencieu IP que el client explota de manera independent), generalment no podeu utilitzar l'excepció restringida de "royalties basats en l'ús sobre IP" de l'ASC 606-10-55-65 —que està dissenyada per a acords de llicència com royalties sobre una patent, no per a una API allotjada. En canvi, estimeu la contraprestació variable utilitzant el mètode del valor esperat o de l'import més probable, subjecte a la restricció que no heu de reconèixer imports on una "reversió significativa" sigui probable un cop es resolgui la incertesa.
Mínim compromès més excés. El client es compromet a, per exemple, 2.000 dòlars al mes d'ús i paga més si el supera. Aquí el límit inferior es comporta com una contraprestació fixa —reconegueu-la de manera sistemàtica a mesura que el client rep valor—, mentre que qualsevol cosa per sobre del mínim és una contraprestació variable subjecta a les mateixes regles d'estimació i restricció. Aquest híbrid apareix constantment en la fixació de preus d'IA: una tarifa de plataforma base més inferència mesurada a més a més.
Saber en quina forma us trobeu canvia els vostres assentaments comptables, les vostres notes a peu de pàgina de divulgació i el grau de nerviosisme que hauria de tenir el vostre auditor respecte a les vostres estimacions.
L'Expedient Pràctic que la Majoria d'Empreses d'IA Realment Utilitzen
Aquí teniu la bona notícia: l'ASC 606 té una drecera creada exactament per a aquesta situació, i la majoria de contractes basats en l'ús ben estructurats hi qualifiquen.
L'expedient pràctic de "dret a facturar" (ASC 606-10-55-18) us permet ometre per complet l'estimació de la contraprestació total del contracte. Si el que factureu cada període correspon directament al valor que el client va rebre en aquell període —heu cobrat 0,002 dòlars per 1.000 tokens, el client va utilitzar 4 milions de tokens, factureu 8 dòlars—, simplement podeu reconèixer aquests 8 dòlars com a ingressos en el període en què es van guanyar. Sense previsions, sense anàlisi de restriccions, sense reestimació a cada tancament.
El quid de la qüestió resideix en la frase "correspon directament". Si la vostra fixació de preus té nivells on la tarifa per unitat disminueix a mesura que augmenta el volum, o descomptes agrupats que no s'ajusten clarament al període en què es va produir l'ús, l'expedient pot trencar-se —l'import facturat deixa de representar el valor d'aquell període, i torneu a la completa estimació de la contraprestació variable. Reviseu la vostra estructura de preus amb aquesta prova específicament en ment abans de suposar que l'expedient s'aplica de manera uniforme a tot el vostre llibre de contractes.
La majoria de contractes d'IA basats en el consum també qualifiquen per al tractament de sèries segons l'ASC 606-10-25-14: en lloc de comptabilitzar cada trucada a l'API com la seva pròpia micro-obligació de rendiment, tracteu tot el flux d'ús com una única obligació de rendiment satisfeta al llarg del temps. Això és el que fa que l'expedient de facturació sigui administrativament viable: no esteu fent un seguiment de milers d'obligacions individuals, sinó que esteu fent un seguiment d'un servei continu amb un preu variable.
Crèdits prepagats: Ingressos diferits i el problema de la pèrdua per caducitat (breakage)
Moltes plataformes d'IA venen paquets de crèdits prepagats: compra 500 $ en tokens per avançat i utilitza'ls durant els mesos següents. Aquesta estructura és popular perquè millora el flux de caixa i assegura el compromís, però introdueix dues obligacions comptables que els fundadors solen obviar.
Ingressos diferits sobre el saldo no utilitzat. En el moment que es rep l'efectiu per un paquet prepagat, cap part d'aquest és encara ingrés. És un passiu: es deu al client el servei o un reemborsament. Els ingressos es mouen de la línia d'ingressos diferits a l'estat de resultats només a mesura que els tokens són realment consumits. Un fundador que registra els 500 $ complets el dia que es cobren està sobrevalorant els ingressos i haurà de desfer-ho, normalment en el pitjor moment possible: durant la diligència deguda en la recaptació de fons, quan un auditor reconstrueix el calendari i elimina la diferència d'un període que ja s'ha presentat als inversors.
Pèrdua per caducitat (breakage) de crèdits que mai s'utilitzen. Alguns clients compren un paquet de crèdits i mai els utilitzen completament abans que caduquin. Aquest saldo no utilitzat —la pèrdua per caducitat (breakage)— no són simplement diners gratuïts que es reconeixen el dia que caduquen els crèdits. Segons l'ASC 606, s'espera que estimeu la taxa de pèrdua per caducitat a partir dels patrons històrics de redempció i que reconeixeu aquesta pèrdua per caducitat estimada proporcionalment, com un petit augment dels ingressos juntament amb l'ús real, en lloc d'esperar a la caducitat per registrar-ho tot de cop. Si encara no teniu un historial de redempció (comú per a un nou programa de crèdits), l'enfocament conservador és esperar fins que el tingueu, reconeixent la pèrdua per caducitat només en la seva expiració mentre, i revisar la política un cop tingueu algunes cohorts de dades.
On la disciplina de la limitació realment importa
La "limitació" (constraint) sobre la consideració variable sona abstracta fins que no heu viscut un trimestre on l'ús d'un client important es va multiplicar per 4 i després va tornar al nivell original. L'ASC 606 exigeix que inclogueu la consideració variable en la vostra estimació d'ingressos només en la mesura que sigui probable que no calgui una reversió significativa posteriorment. En la pràctica, això significa:
- Primer any d'un nou model de preus: manteniu un enfocament conservador. Reconeixeu els mínims compromesos i els fets amb confiança; tracteu amb escepticisme real qualsevol projecció més enllà de l'ús facturat/real, ja que no teniu contractes comparables per prendre com a referència.
- A mesura que s'acumula l'historial d'ús: la vostra limitació es pot relaxar, perquè ara teniu una base defensable (l'ús d'aquest client ha variat entre X i Y durant sis mesos seguits) per a una estimació més ajustada.
- En cada tancament: torneu a estimar. La consideració variable no és un número que es "estableix i s'oblida", sinó que es revisa cada període d'informació a mesura que arriba nova informació, amb l'ajust de posada al dia acumulatiu fluint a través del període actual.
Per a un equip financer que gestiona això en centenars o milers de contractes, la solució operativa és alinear el sistema de facturació i el vostre llibre major de reconeixement d'ingressos abans del tancament, no després, de manera que les dades d'ús es conciliïn automàticament en lloc de requerir una pista d'auditoria manual cada final de mes.
Per què això importa fins i tot si sou petits
Si sou una startup d'eines d'IA de dues persones que factura a un grapat de clients per token, és temptador tractar tot això com "el tipus de cosa que gestionarem quan aconseguim una ronda de finançament Sèrie A". Això és un risc real. Els errors en el reconeixement d'ingressos són una de les troballes més comunes en la diligència deguda per a la recaptació de fons en SaaS, i la fixació de preus basada en l'ús multiplica el nombre de decisions que un auditor voldrà veure documentades: quins contractes utilitzen el mètode de facturació ràpida, quina taxa de pèrdua per caducitat heu assumit i per què, com vau gestionar el trimestre en què l'ús d'un client es va disparar.
Fer les coses bé des del primer dia —fins i tot a petita escala— significa que no estareu reconstruint divuit mesos d'historial d'ingressos sota pressió de termini més tard. També significa que els números que utilitzeu internament per prendre decisions de preus i contractació són realment precisos, en lloc d'estar inflats per ingressos diferits no reconeguts que es troben on no haurien de ser.
Manteniu els vostres llibres tan clars com el vostre model de preus
La fixació de preus basada en l'ús i per token és realment més complexa de comptabilitzar que una subscripció mensual plana, però la complexitat és auditable: només requereix documentar l'estructura del vostre contracte, el fonament de la vostra limitació i les vostres suposicions de pèrdua per caducitat a mesura que avança, no adaptar-les més tard. La comptabilitat en text pla de Beancount.io fa que aquest rastre de documentació sigui explícit: cada entrada de reconeixement d'ingressos, saldo d'ingressos diferits i ajust de pèrdua per caducitat resideix en text amb control de versions que vosaltres (o el vostre auditor) podeu traçar línia per línia, en lloc d'estar enterrat en una plataforma de facturació de "caixa negra". Comenceu gratuïtament i manteniu el vostre llibre major tan transparent com el model de preus que esteu construint al seu damunt.