Pregunte a un fundador de SaaS en 2022 cuánto ingreso registraría este mes, y la respuesta era una fórmula de hoja de cálculo: puestos por precio, prorrateado por los días restantes del contrato. Pregunte a un fundador nativo de IA la misma pregunta hoy, y la respuesta honesta es "depende de cuánto hayan usado nuestros clientes el modelo". El consumo de tokens puede duplicarse en una semana cuando un cliente lanza una característica a producción, o estancarse cuando pausan un experimento. No hay un recuento de puestos al que anclar el pronóstico.
Ese cambio de suscripción a consumo no es solo una decisión de precios. Es un problema contable, y recae directamente dentro del ASC 606 — el mismo estándar de reconocimiento de ingresos que ha regido el SaaS desde 2018, solo que aplicado a un insumo mucho menos predecible. Si lo hace mal, no estará ante un error de redondeo; estará ante un año reformulado durante la diligencia debida, justo cuando menos puede permitírselo.
Por qué la Tarificación Basada en Tokens Rompe el Antiguo Manual
El reconocimiento de ingresos tradicional de SaaS es comparativamente indulgente. Un cliente paga $12,000 por un plan anual, usted reconoce $1,000 al mes, y la decisión más importante es si una modificación de contrato requiere una reasignación. La contraprestación es fija. La obligación de desempeño —acceso al software a lo largo del tiempo— es sencilla. Los auditores han visto miles de contratos exactamente iguales.
La tarificación basada en IA y en el uso elimina la parte fija. Los clientes pagan por tokens procesados, llamadas a la API realizadas, ejecuciones de inferencia completadas o segundos de cómputo consumidos. Esa contraprestación es variable por diseño, y el ASC 606 tiene una sección completa —la guía de "contraprestación variable" en ASC 606-10-32-11 a 32-13— dedicada exactamente a este problema. El desafío central no es filosófico, es práctico: ¿cuánto ingreso reconoce en un período cuando realmente no sabe, en el momento de cerrar sus libros, exactamente cuánto terminará debiendo un cliente?
Para una empresa de IA en etapa temprana, esto se vuelve más difícil antes de que se facilite. Un negocio SaaS maduro puede apoyarse en años de historial de uso para estimar el consumo con confianza. Una empresa que lanzó su modelo de tarificación basado en tokens hace ocho meses no tiene tales comparables. El uso puede variar drásticamente a medida que los clientes pasan de la fase piloto a la producción, y el patrón del trimestre pasado puede decir poco sobre el de este trimestre.
Las Dos Formas de Contrato que lo Determinan Todo
Antes de poder reconocer correctamente un dólar de ingresos basados en el uso, necesita saber en cuál de dos estructuras se encuentra realmente, porque se contabilizan de manera diferente.
Consumo puro, sin mínimo comprometido. El cliente compra un conjunto de créditos o acepta pagar por unidad consumida, sin un límite inferior. Si el acuerdo es un servicio directo (usted proporciona acceso a un modelo alojado, no licencia una propiedad intelectual que el cliente explota de forma independiente), generalmente no puede usar la estrecha excepción de "regalías basadas en el uso de propiedad intelectual" en ASC 606-10-55-65 —que está diseñada para acuerdos de licencia como las regalías sobre una patente, no para una API alojada. En su lugar, usted estima la contraprestación variable utilizando el método del valor esperado o del monto más probable, sujeto a la restricción de que no debe reconocer cantidades donde una "reversión significativa" sea probable una vez que la incertidumbre se resuelva.
Mínimo comprometido más exceso. El cliente se compromete, por ejemplo, a $2,000 al mes de uso y paga más si lo excede. Aquí, el límite inferior se comporta como una contraprestación fija —reconózcala de manera sistemática a medida que el cliente recibe valor—, mientras que cualquier cantidad por encima del mínimo es una contraprestación variable sujeta a las mismas reglas de estimación y restricción. Este híbrido aparece constantemente en la tarificación de IA: una tarifa base de plataforma más inferencia medida adicional.
Saber en qué forma de contrato se encuentra cambia sus asientos contables, sus notas a pie de página de divulgación y cuán nervioso debería estar su auditor acerca de sus estimaciones.
El Recurso Práctico que la Mayoría de las Empresas de IA Realmente Utilizan
Aquí están las buenas noticias: el ASC 606 tiene un atajo diseñado para esta situación, y la mayoría de los contratos basados en el uso bien estructurados califican para él.
El recurso práctico de "derecho a facturar" (ASC 606-10-55-18) le permite omitir por completo la estimación de la contraprestación total del contrato. Si lo que factura cada período se corresponde directamente con el valor que el cliente recibió en ese período —usted cobró $0.002 por cada 1,000 tokens, el cliente usó 4 millones de tokens, usted factura $8—, simplemente puede reconocer esos $8 como ingresos en el período en que se obtuvieron. Sin pronósticos, sin análisis de restricciones, sin reestimaciones en cada cierre.
La trampa está en la frase "se corresponde directamente". Si su tarificación tiene niveles donde la tarifa por unidad disminuye a medida que aumenta el volumen, o descuentos por paquetes que no se corresponden claramente con el período en que ocurrió el uso, el recurso práctico puede fallar —el monto facturado deja de representar el valor de ese período, y usted vuelve a la estimación completa de la contraprestación variable. Revise su estructura de precios con esta prueba específicamente en mente antes de asumir que el recurso se aplica uniformemente en su cartera de contratos.
La mayoría de los contratos de IA basados en el consumo también califican para el tratamiento de series bajo ASC 606-10-25-14: en lugar de contabilizar cada llamada a la API como su propia micro-obligación de desempeño, usted trata todo el flujo de uso como una única obligación de desempeño satisfecha a lo largo del tiempo. Esto es lo que hace que el recurso práctico de facturación sea administrativamente viable: usted no está rastreando miles de obligaciones individuales, está rastreando un servicio continuo con un precio variable.
Créditos prepagados: Ingresos diferidos y el problema de la merma
Muchas plataformas de IA venden paquetes de créditos prepagados: compra $500 en tokens por adelantado y úsalos en los meses siguientes. Esta estructura es popular porque mejora el flujo de caja y asegura el compromiso, pero introduce dos obligaciones contables que los fundadores suelen pasar por alto.
Ingresos diferidos sobre el saldo no utilizado. En el momento en que se recibe el dinero por un paquete prepagado, nada de ello es aún un ingreso. Es un pasivo: usted le debe al cliente el servicio o un reembolso. Los ingresos se trasladan de la línea de ingresos diferidos al estado de resultados solo a medida que los tokens se consumen. Un fundador que registra los $500 completos el día que se recaudan está sobreestimando los ingresos y tendrá que revertirlo, generalmente en el peor momento posible: durante la due diligence de recaudación de fondos, cuando un auditor reconstruye el cronograma y elimina la diferencia de un período que ya ha sido presentado a los inversores.
Merma de créditos que nunca se usan. Algunos clientes compran un paquete de créditos y nunca lo agotan antes de que caduque. Ese saldo no utilizado —la merma— no es simplemente dinero gratis que se reconoce el día en que caducan los créditos. Bajo el ASC 606, se espera que usted estime la tasa de merma a partir de los patrones históricos de canje y reconozca esa merma estimada proporcionalmente, como un pequeño incremento en los ingresos junto con el uso real, en lugar de esperar a la caducidad para registrarlo todo de una vez. Si aún no tiene un historial de canjes (común para un nuevo programa de créditos), el enfoque conservador es esperar hasta tenerlo, reconociendo la merma solo al caducar mientras tanto, y revisar la política una vez que tenga algunas cohortes de datos.
Donde la disciplina de la restricción realmente importa
La "restricción" en la consideración variable suena abstracta hasta que se ha vivido un trimestre en el que el uso de un gran cliente se disparó 4x y luego volvió a la normalidad. El ASC 606 le pide que incluya la consideración variable en su estimación de ingresos solo en la medida en que sea probable que no se necesite una reversión significativa más adelante. En la práctica, eso significa:
- Primer año de un nuevo modelo de precios: sea conservador. Reconozca los mínimos comprometidos y los valores reales con confianza; trate cualquier proyección más allá del uso facturado/real con verdadero escepticismo, ya que no tiene contratos comparables contra los cuales comparar.
- A medida que se acumula el historial de uso: su restricción puede relajarse, porque ahora tiene una base defendible (el uso de este cliente ha variado entre X e Y durante seis meses seguidos) para una estimación más precisa.
- En cada cierre: reestime. La consideración variable no es un número que se "establece y se olvida", se revisa en cada período de informe a medida que llega nueva información, con el ajuste acumulativo de puesta al día fluyendo a través del período actual.
Para un equipo de finanzas que gestiona esto en cientos o miles de contratos, la solución operativa es alinear su sistema de facturación y su libro mayor de reconocimiento de ingresos antes del cierre, no después, para que los datos de uso se concilien automáticamente en lugar de requerir un rastro de auditoría manual cada fin de mes.
Por qué esto importa incluso si eres pequeño
Si eres una startup de herramientas de IA de dos personas que factura a un puñado de clientes por token, es tentador tratar todo esto como "el tipo de cosas con las que lidiaremos cuando recaudemos una Serie A". Eso es un riesgo real. Los errores en el reconocimiento de ingresos son uno de los hallazgos más comunes en la due diligence de recaudación de fondos en SaaS, y los precios basados en el uso multiplican el número de juicios que un auditor querrá ver documentados: qué contratos utilizan el recurso de facturación, qué tasa de merma asumió y por qué, cómo manejó el trimestre en que el uso de un cliente se disparó.
Hacer bien la mecánica desde el primer día —incluso a pequeña escala— significa que no estará reconstruyendo dieciocho meses de historial de ingresos bajo la presión de una fecha límite más tarde. También significa que los números que utiliza internamente para tomar decisiones de precios y contratación son realmente precisos, en lugar de estar inflados por ingresos diferidos no reconocidos que se encuentran donde no deberían.
Mantén tus libros tan claros como tu modelo de precios
La contabilidad basada en el uso y en tokens es genuinamente más compleja que una suscripción mensual fija, pero la complejidad es auditable; solo requiere documentar la estructura de tu contrato, el racional de tu restricción y tus supuestos de merma a medida que avanzas, no ajustarlos posteriormente. La contabilidad de texto plano de Beancount.io hace explícito ese rastro de documentación: cada asiento de reconocimiento de ingresos, saldo de ingresos diferidos y ajuste por merma reside en texto con control de versiones que tú (o tu auditor) pueden rastrear línea por línea, en lugar de estar enterrado en una plataforma de facturación de caja negra. Comienza gratis y mantén tu libro mayor tan transparente como el modelo de precios que estás construyendo sobre él.