Inicio › Blog › Bookings vs Revenue: una reconciliación grado CFO en una hoja de cálculo

Bookings vs Revenue: una reconciliación grado CFO en una hoja de cálculo

La mayoría de las empresas no tienen un problema de bookings vs revenue. Tienen un problema de reconciliación entre bookings y revenue, que es distinto. Los números están bien en ambos sistemas. Lo que falta es el puente que explique por qué no concuerdan. Este es el puente de cinco pasos que cierra el 95% de la brecha, además de cómo construirlo como una sola hoja de cálculo que no miente.

La discusión eterna

Cada trimestre, Ventas reporta un número de bookings. Cada trimestre, Finanzas reporta un número de revenue. Los dos nunca coinciden. La conversación sobre el porqué se convierte en un ejercicio forense de contabilidad: tres personas en una llamada de Zoom revisando correos, enmiendas de contrato y la fecha en que alguien contra-firmó un redline a las 11:47 PM del último día del trimestre. Para cuando la varianza queda explicada, la reunión terminó y nadie entiende el negocio mejor que hace 60 minutos.

La razón es simple. Bookings y revenue miden cosas distintas. Bookings mide el valor del contrato comprometido en el periodo. Revenue mide el valor ganado en el periodo bajo ASC 606. Los dos números divergen cada vez que los términos del contrato incluyen un ramp, una enmienda, un inicio de periodo parcial, un compromiso plurianual o una consideración no en efectivo. Lo cual es casi siempre.

El problema de reconciliación no es averiguar cuál número es correcto. Ambos lo son. El problema es documentar el puente: cada dólar de diferencia, atribuido a una partida específica, en un formato que sobreviva al próximo trimestre.

Qué exige ASC 606 realmente, en lenguaje claro

Desde que entró en vigor ASC 606, el estándar de reconocimiento de ingresos se resume en cinco pasos. Identificas el contrato, identificas las obligaciones de desempeño dentro del mismo, determinas el precio de la transacción, asignas el precio a las obligaciones de desempeño y reconoces ingresos cuando (o conforme) esas obligaciones se satisfacen.

Para un contrato típico de B2B SaaS, la implicación práctica es esta. La revenue de suscripción se reconoce de forma proporcional a lo largo del término, los servicios profesionales se reconocen conforme se entregan y cualquier cuota única de setup se reconoce al entregarse (a menos que sea no-distinta, en cuyo caso se incorpora al flujo de suscripción). Los ramps plurianuales se reconocen al valor contractual anual promedio, con un activo de contrato o un saldo de ingresos diferidos que se acumula o se libera según el calendario de facturación.

Ese es todo el marco que usan la mayoría de los equipos de finanzas B2B SaaS. Las complicaciones vienen de los casos límite: enmiendas, inicios de mes parciales, clientes que cancelan con reembolso, swap deals donde el cliente cambia un SKU por otro a mitad de contrato. Esos casos límite son donde ocurre el trabajo de reconciliación.

Las cinco partidas que explican el 95% de la brecha

He reconstruido esta reconciliación en tres empresas B2B SaaS distintas. Las categorías de partidas son notablemente consistentes en todas.

1. Ramp deals. Tomemos un contrato de tres años a $100K Año 1, $150K Año 2, $200K Año 3. El Valor Total del Contrato es $450K, registrado como booking en el periodo en que cierra el deal. La revenue se reconoce de forma proporcional al valor anual promedio de $150K por año. Supongamos que al cliente se le factura anualmente según el calendario del contrato: $100K en Y1, $150K en Y2, $200K en Y3. En el Año 1, la revenue GAAP es $150K pero las facturaciones son solo $100K, así que la empresa registra un activo de contrato (cuenta por cobrar no facturada) de $50K. No se crea ingreso diferido en este escenario, porque las facturaciones nunca exceden la revenue reconocida. Al cierre del Año 3, el activo de contrato se ha liquidado a cero ($50K creado en Y1, sin cambio en Y2 con $150K facturado contra $150K reconocido, luego reducido $50K en Y3 cuando se facturan $200K contra $150K reconocidos). El puente: bookings $450K, revenue Año 1 $150K, facturaciones Año 1 $100K, activo de contrato creado $50K. La mayoría de las discusiones de reconciliación son alguien olvidando uno de esos cuatro números, o peor, confundiendo activo de contrato (revenue ganada antes de facturar) con ingreso diferido (efectivo cobrado antes de la revenue).

2. Enmiendas a mitad de término. Un cliente sube de $50K/año a $80K/año a nueve meses de un contrato de 12 meses. El uplift anualizado es de $30K de ARR incremental, y ese es el número que Ventas debe publicar en la caminata de ARR. Pero solo quedan tres meses del término, así que la cifra de bookings incremental en el periodo es 3/12 × $30K = $7.5K de valor del término restante. La revenue se ajusta durante esos tres meses al nuevo rate de $80K, y el ingreso diferido del contrato original se sigue liberando como si nada hubiera cambiado para la porción no actualizada. La columna del puente muestra "Uplift de enmienda" con ambas cifras señaladas: delta de ARR y delta de TCV del término restante. Elegir un solo número sin etiquetar cuál es cuál es como esta categoría causa discusiones recurrentes.

3. Inicios de periodo parcial. Un contrato que empieza el día 17 del mes crea dos meses parciales: el mes de inicio con 14 días de revenue y un mes final que puede o no ser parcial dependiendo de cuándo termine el término. La mayoría de las hojas de cálculo computan revenue con prorrateo diario. Algunas la computan con prorrateo mensual. Los dos métodos producen números distintos, y si Ventas y Finanzas están usando métodos distintos, la reconciliación se rompe cada trimestre.

4. Add-ons no-distintos. Un cliente compra la plataforma por $60K y "Premium Support" por $20K. ¿Son dos obligaciones de desempeño distintas o una sola? Bajo ASC 606, la respuesta depende de si el soporte es separable de manera significativa. Si no lo es, ambos se reconocen de forma proporcional como un solo flujo, lo que significa $80K en 12 meses en lugar de $60K más $20K-al-entregar. Ventas registra los $20K como si fueran upfront. Finanzas los reconoce de forma proporcional. Puente: "Diferimiento por no-distinto."

5. Cancelaciones y reembolsos. Un cliente cancela a los 7 meses de un contrato de 12 meses con reembolso. Los bookings se revierten por la porción no facturada. La revenue se revierte por cualquier monto sobre-reconocido. El saldo de ingresos diferidos cae a cero. La mayoría de las herramientas de reconciliación manejan esto mal porque tratan el contrato como una sola línea en lugar de un flujo que debe deshacerse. El puente: "Reversa por churn" con el monto reembolsado señalado por separado del revenue futuro no reconocido.

El ejemplo trabajado de 20 deals

El modelo más pequeño que funciona tiene 20 deals, suficientes para cubrir cada categoría arriba. Elige cinco contratos de new business (limpios), cuatro ramps plurianuales, tres enmiendas a mitad de término, tres inicios de periodo parcial, tres bundles con add-ons no-distintos y dos cancelaciones. Camina cada deal desde la fecha de contrato hasta el reconocimiento mensual hasta el final del término.

Constrúyelo en tres pestañas. Pestaña uno: la taxonomía del deal, una fila por deal, columnas para fecha de contrato, término, ACV, TCV, calendario de facturación, marcadores de enmienda, fecha de cancelación. Pestaña dos: la cuadrícula mensual de reconocimiento, una columna por mes, una fila por deal, poblada por una fórmula que lee la taxonomía y aplica la regla de reconocimiento correcta. Pestaña tres: el resumen del puente, bookings menos revenue, atribuido a cada una de las cinco categorías con activo de contrato e ingreso diferido rastreados como columnas separadas.

La reconciliación funciona cuando el resumen del puente explica matemáticamente la varianza entre bookings y revenue al dólar. No "aproximadamente". Al dólar. Si no, una de las cinco categorías tiene un caso faltante.

Por qué los CFOs no confían en el número de bookings

El número de bookings, como lo reporta Ventas, casi siempre está inflado en relación con lo que Finanzas puede reconocer a lo largo del término del contrato. No porque Ventas sea deshonesta. Ventas cuenta TCV como un solo número mientras Finanzas tiene que aplicar descuentos, promedio de ramps y diferimientos no-distintos a ese mismo TCV.

La solución es publicar bookings en múltiples granularidades: TCV, ARR, MRR, facturaciones, revenue reconocida. Cada una mide algo diferente y cada una es correcta para una conversación diferente. Las reuniones de pronóstico deben usar ARR. Los modelos de flujo de caja deben usar facturaciones. Las discusiones del estado de resultados deben usar revenue reconocida. Cuando Ventas y Finanzas empiezan a usar el número correcto para la conversación correcta, las discusiones desaparecen en su mayoría.

Cuándo graduarse a software

La reconciliación en una sola hoja de cálculo funciona hasta unos 200-500 contratos activos. Después de eso, tres cosas se rompen. La hoja se vuelve lenta, la carga de entrada manual se convierte en un trabajo de tiempo completo y el rastro de auditoría se vuelve demasiado largo para que un humano lo defienda. Ese es el punto donde Maxio, Sage Intacct, Chargebee o uno de los proveedores de RevRec nicho gana su precio.

Por debajo de 200 contratos activos, la hoja de cálculo usualmente le gana al software en flexibilidad. Puedes modelar un caso límite en 20 minutos. El software requiere un proyecto de configuración. La mayoría de los equipos que veo migran a software alrededor de 300-400 contratos activos, que es aproximadamente cuando la hoja empieza a perder más tiempo del que cuesta el software.

La instalación de medio día

Si tus números de bookings y revenue no se reconcilian limpiamente hoy, esta es la intervención de medio día:

1. Identifica los últimos 20 deals representativos. Asegúrate de que las cinco categorías estén cubiertas. (1 hora)
2. Construye el modelo de hoja de cálculo de tres pestañas. (2 horas)
3. Que un líder de Ventas y un líder de Finanzas caminen el resumen del puente juntos. (1 hora)
4. Escribe un documento de política de una página que codifique las reglas del puente. Publícalo. (30 minutos)
5. Agenda una revisión trimestral de las categorías del puente. Los nuevos casos límite se agregan a la política, no se tapan. (15 minutos de calendario)

Esa es toda la intervención. No requiere software nuevo, headcount nuevo, ni un engagement de consultoría de 90 días. Requiere cuatro horas y la disposición de poner por escrito la política que todos han estado improvisando por años.