Presupuesto vs Real: El ciclo semanal del fundador
Publicado el 18 de febrero de 2026 · Jules, Founder of NoNoiseMetrics · 18min de lectura
Las startups rara vez mueren en una semana dramática. Mueren en una cadena de semanas donde nadie comparó lo que se suponía que iba a pasar con lo que realmente pasó. El MRR creció un poco más lento de lo esperado. Los costes subieron un poco. El churn empeoró silenciosamente. El forecast nunca se actualizó. El runway se acortó y nadie se dio cuenta hasta que era incómodo de corregir.
Presupuesto vs real es el hábito que detecta esa deriva. No es un ritual financiero ni un entregable para el board — es una comparación semanal de 10 minutos entre tu forecast y la realidad que te dice si cambiar de comportamiento ahora o el mes que viene. Para la mayoría de fundadores SaaS en fase temprana, esa comparación se reduce a seis números, una tabla y una decisión.
Este artículo cubre qué significa presupuesto vs real, cómo ejecutar el ciclo semanal, una plantilla completa de informe presupuesto vs real, un ejemplo SaaS trabajado con porcentajes de varianza, y los errores que convierten la revisión en burocracia. La guía financiera para startups de Y Combinator identifica el hábito de presupuesto vs real como una de las prácticas financieras de mayor impacto para fundadores en fase temprana.
¿Qué es presupuesto vs real?
Presupuesto vs real es la comparación entre los números planificados y los resultados reales en ingresos, costes y caja. El presupuesto es el forecast: lo que esperabas que pasara. Los reales son lo que el negocio produjo. La varianza — la diferencia entre ambos — es lo que requiere una decisión.
Cuatro conceptos que pertenecen al mismo ciclo:
Presupuesto — lo que planeaste gastar y ganar. Un compromiso orientado al futuro. Real — lo que el negocio produjo en un periodo dado. Los números reales. Varianza presupuestaria — la diferencia entre presupuesto y real, en valor absoluto o porcentaje. Informe presupuesto vs real — la comparación estructurada que muestra los tres, con una acción adjunta a las varianzas significativas.
En lenguaje de fundador: “¿El mes fue como esperaba? Si no, ¿qué cambió y qué hago diferente esta semana?”
Eso es todo. Los forecasts y presupuestos solo son útiles si este ciclo de comparación se ejecuta regularmente. Un forecast que nunca se contrasta con la realidad es storytelling con seguridad. Un presupuesto que nunca se compara con los reales es decoración.
Para el modelo financiero que produce el forecast contra el que se ejecuta este ciclo, consulta la guía minimalista de 8 inputs.
Cada forecast necesita un MRR baseline limpio. Obtén el tuyo desde Stripe en 90 segundos →
Por qué presupuesto vs real importa más de lo que los fundadores esperan
El argumento para ejecutar presupuesto vs real no es que sea buena higiene financiera. Es que sin él, el negocio puede derivar significativamente antes de que nadie lo note — y cuanto más tiempo pasa sin detectar la deriva, menos palancas hay disponibles para corregirla.
Los fallos de ingresos se acumulan silenciosamente. Un fallo de €500 en MRR en enero parece pequeño. Si el nuevo MRR es consistentemente un 15% por debajo del plan, para el mes seis la brecha es material. El ciclo de presupuesto vs real detecta el patrón en el mes dos, no en el mes seis.
Los costes derivan sin decisión. La mayoría de sobrecostes no son dramáticos. Son una suscripción de herramienta que se renovó, una factura de API que subió con el uso, un freelance que asumió más trabajo. El presupuesto vs real mensual los detecta antes de que se incrusten estructuralmente.
El churn es la variable oculta más peligrosa. Los fundadores modelan el churn como un porcentaje fijo en su modelo financiero, y luego olvidan comprobar si el churn real coincide con la suposición. Con un 3% de churn mensual vs el 1,5% modelado, la diferencia en número de clientes al mes doce es casi del 20%. El negocio que lo detecta en el mes dos puede mejorar la retención. El que lo detecta en el mes diez tiene un problema estructural.
El churn involuntario es parcialmente recuperable — pero solo si se detecta pronto. Una parte significativa de lo que aparece como “MRR cancelado” en realidad es churn por pago fallido, no cancelaciones voluntarias. Los datos de Stripe hacen visible la distinción: una suscripción marcada como cancelada tras un pago fallido es recuperable mediante una secuencia de dunning si se detecta en días. Semanas después, el cliente ya siguió adelante. El presupuesto vs real que incluye una línea de pagos fallidos detecta esta ventana de recuperación. NoNoiseMetrics muestra el churn por pagos fallidos vs voluntario por separado desde Stripe exactamente por esta razón.
El runway es la métrica que no puede estar equivocada. Un cálculo de runway solo es útil si los inputs — burn rate y saldo de caja — reflejan lo que realmente pasó. Un modelo que no se ha actualizado contra los reales mostrará runway basado en suposiciones obsoletas. Fundadores se han sorprendido con runways cortos antes, y la causa es casi siempre un modelo que divergió de la realidad meses antes sin que nadie ejecutara la comparación.
El ciclo semanal de 10 minutos
La revisión semanal no necesita ser complicada. Cinco pasos, una tabla, una decisión:
Paso 1: Recoger los números actuales. Cada semana: MRR final, nuevo MRR, MRR cancelado, saldo de caja. Mensualmente: costes fijos reales, costes variables reales. Fuentes: Stripe para ingresos y churn, feed bancario o herramienta contable para costes. Un dashboard limpio de ingresos recurrentes hace que este paso tome menos de dos minutos.
Paso 2: Comparar contra el presupuesto. Rellena la tabla de comparación (plantilla abajo). Para cada línea: presupuesto, real, varianza en dólares, varianza en porcentaje.
Paso 3: Señalar solo la varianza significativa. No toda diferencia justifica acción. Usa umbrales: varianza de ingresos por encima del 5%, varianza de gastos por encima del 10%, varianza de runway por encima de 0,5 meses, tasa de churn más del 50% por encima de la suposición. Por debajo de esos umbrales: anótalo, no actúes.
Paso 4: Escribe una acción por varianza señalada. Una. No un documento estratégico, no una retrospectiva. Una acción concreta, un responsable, esta semana. Churn por encima del umbral → revisa los eventos de cancelación y pagos fallidos en Stripe hoy. Gasto por encima del umbral → identifica la partida que se movió y decide si recortarla.
Paso 5: Actualiza el modelo si la realidad cambió claramente. No cada semana — solo cuando una suposición haya cambiado de forma demostrable. El nuevo MRR ha estado por debajo del plan durante tres semanas consecutivas → actualiza la suposición. Un fallo de una semana es ruido. Un patrón de tres semanas es señal.
El ciclo debería tomar 10 minutos si los datos son accesibles. Si toma una hora, el problema es la infraestructura de datos, no el proceso.
Informe presupuesto vs real: la plantilla completa
Un informe presupuesto vs real de fase fundador debería caber en una pantalla y producir una decisión. Aquí está la estructura completa:
Bloque de ingresos
| Métrica | Presupuesto | Real | Varianza | Varianza % |
|---|---|---|---|---|
| MRR final | €12.000 | €11.400 | −€600 | −5,0% |
| Nuevo MRR | €1.800 | €1.500 | −€300 | −16,7% |
| MRR de expansión | €400 | €380 | −€20 | −5,0% |
| MRR cancelado (voluntario) | €300 | €360 | +€60 | +20,0% |
| MRR cancelado (pago fallido) | €100 | €220 | +€120 | +120,0% |
Bloque de costes
| Métrica | Presupuesto | Real | Varianza | Varianza % |
|---|---|---|---|---|
| Costes fijos | €5.500 | €5.500 | €0 | 0,0% |
| Costes variables | €2.000 | €2.700 | +€700 | +35,0% |
| Gasto total | €7.500 | €8.200 | +€700 | +9,3% |
Bloque de caja
| Métrica | Presupuesto | Real | Varianza |
|---|---|---|---|
| Burn mensual | €2.100 | €3.400 | +€1.300 |
| Caja disponible | €48.900 | €47.600 | −€1.300 |
| Runway | 11,0 meses | 9,7 meses | −1,3 meses |
Bloque de acciones
| Señal | Umbral | Estado | Acción esta semana |
|---|---|---|---|
| Churn por encima del plan | +50% | ⚠️ Churn por pago fallido +120% | Ejecutar secuencia de dunning sobre la cohorte de pagos fallidos |
| Costes variables por encima del plan | +10% | ⚠️ +35% | Identificar el driver de coste API; configurar alerta de uso |
| Nuevo MRR por debajo del plan | −15% | ⚠️ −16,7% | Revisar caída de activación en Stripe; verificar conversión de trial |
| Runway por debajo del plan | −0,5 meses | ⚠️ −1,3 meses | Congelar experimentos que no generan ingresos hasta confirmar recuperación |
Separar el MRR cancelado en componentes voluntario y de pago fallido es el cambio más accionable que la mayoría de fundadores pueden hacer en su informe presupuesto vs real. El churn voluntario requiere trabajo de producto y retención — más lento de arreglar. El churn por pago fallido es recuperable en días si se detecta. Tratarlos como el mismo número desperdicia la ventana de recuperación.
Ejemplo presupuesto vs real: un mes SaaS completo
Escenario: Una herramienta SaaS de analytics, mes cuatro. El presupuesto se definió usando el modelo financiero de la revisión del mes pasado.
Inputs del presupuesto (del modelo del mes pasado):
- MRR inicial: €10.000
- Nuevo MRR: €1.800
- Expansión: €400
- Churn (total): €400
- Costes fijos: €5.500
- Costes variables: €2.000
- Caja: €50.000
Lo que realmente pasó:
- MRR inicial: €10.000 (correcto)
- Nuevo MRR: €1.500 (falló por €300)
- Expansión: €380 (cerca)
- Churn voluntario: €360 (ligeramente por encima)
- Churn por pago fallido: €220 (significativamente por encima; el modelo tenía €100)
- Costes fijos: €5.500 (según el plan)
- Costes variables: €2.700 (por encima en €700 — costes de API crecieron con el uso)
El cálculo:
MRR final = 10.000 + 1.500 + 380 − 360 − 220 = 11.300
(El presupuesto era 10.000 + 1.800 + 400 − 300 − 100 = 11.800)
Varianza MRR: −€500, o −4,2%
Gasto total: 5.500 + 2.700 = 8.200
Gasto presupuestado: 5.500 + 2.000 = 7.500
Varianza de gasto: +€700, o +9,3%
Burn mensual: 8.200 − 11.300 = −3.100 (todavía cash-flow positivo)
Burn presupuestado: 7.500 − 11.800 = −4.300
El negocio es cash-flow positivo en ambos casos, pero genera €1.200 menos de caja de lo presupuestado.Qué debería hacer el fundador, concretamente:
El fallo de MRR es de €500 — por debajo del umbral de alerta del 5% sobre MRR, pero el nuevo MRR falló un 16,7% y fue compensado parcialmente por menor churn. El churn por pago fallido de €220 contra una suposición de €100 es el hallazgo más accionable. Son clientes recuperables. Una secuencia de dunning activada durante la semana captura una fracción significativa de ellos.
El sobrecostes de costes variables es €700. Con €2.700 reales vs €2.000 presupuestados, es un sobrecostes del 35%. Para un producto pesado en IA o APIs, esto a menudo significa que el uso creció más rápido de lo modelado — lo cual es un buen problema — pero el modelo de costes necesita actualizarse. Si el producto crece, los costes variables crecerán con él, y el modelo financiero necesita reflejarlo o las proyecciones de runway serán optimistas.
Acciones esta semana:
- Sacar la lista de pagos fallidos de Stripe; activar secuencia de recuperación por email vía Brevo
- Revisar dashboard de uso de API; configurar alerta de facturación al 80% del real del mes pasado
- Actualizar modelo financiero: suposición de nuevo MRR → €1.600 (entre plan y reales); suposición de costes variables → €2.400
Eso es todo. Sin deck para el board. Sin reunión de finanzas. Tres acciones concretas de una revisión de 10 minutos.
Los datos del KeyBanc Capital Markets SaaS Survey muestran que las empresas SaaS que ejecutan revisiones semanales de presupuesto vs real detectan la deriva de costes una media de seis semanas antes que las que hacen revisiones mensuales — una diferencia significativa en la etapa por debajo de €1M de ARR.
Fórmula de varianza presupuestaria
La mecánica es simple:
Varianza presupuestaria (absoluta) = Real − Presupuesto
Varianza presupuestaria (%) = (Real − Presupuesto) / Presupuesto × 100La convención de signos importa. Para líneas de ingresos, una varianza negativa es mala (ganaste menos de lo planeado). Para líneas de costes, una varianza positiva es mala (gastaste más de lo planeado). Algunos fundadores invierten el signo en las líneas de costes para que “todo lo malo = negativo” — ambas convenciones funcionan mientras sean consistentes.
Ejemplo:
Nuevo MRR presupuestado: €1.800
Nuevo MRR real: €1.500
Varianza: €1.500 − €1.800 = −€300
Varianza %: −€300 / €1.800 = −16,7%Costes variables presupuestados: €2.000
Costes variables reales: €2.700
Varianza: €2.700 − €2.000 = +€700
Varianza %: +€700 / €2.000 = +35,0%Para fundadores que usan una métrica de burn combinada, la varianza es:
Burn presupuestado = Ingresos presupuestados − Costes presupuestados
Burn real = Ingresos reales − Costes reales
Varianza de burn = Burn real − Burn presupuestadoSi el burn real es mayor que el burn presupuestado (el negocio quemó más caja de lo esperado), la varianza es positiva y negativa — positiva en sobrecostes y negativa en ingresos. Muestra ambos componentes para saber qué palanca mover.
El ciclo presupuesto vs real en el sistema de forecasting
Presupuesto vs real no funciona solo. Es un paso en un ciclo operativo continuo:
Modelo financiero (suposiciones)
→ Forecast (outputs mensuales proyectados)
→ Presupuesto (plan de gasto por periodo)
→ Reales (lo que el negocio produjo)
→ Varianza (brecha entre plan y realidad)
→ Decisión (acción o actualización de suposición)
→ Modelo financiero actualizadoSin el paso de reales-a-decisión, el ciclo está roto. Un forecast que nunca se compara con los reales da a los fundadores falsa confianza — el modelo se ve bien, el runway parece adecuado, pero las suposiciones subyacentes se han desviado de la realidad.
El paso de decisión-a-modelo es igual de importante. Si notas que el nuevo MRR ha estado un 15% por debajo del plan durante tres meses consecutivos y no actualizas el modelo, el modelo financiero está mintiendo sobre el runway. Actualizar la suposición es incómodo porque acorta el runway — pero lo hace preciso, que es para lo que sirve el modelo.
Para la capa de forecast de MRR, el modelo de 3 inputs está diseñado para integrarse con este ciclo de presupuesto vs real — lo suficientemente ligero para actualizar cada semana junto con la comparación de reales.
Para la capa de planificación de escenarios que hace el modelo testeable bajo estrés, consulta Modelado de escenarios para bootstrappers: prueba de estrés en 15 minutos.
El informe State of the Cloud de Bessemer identifica los datos automatizados de MRR como la inversión en infraestructura de mayor impacto para mejorar la precisión y cadencia de las revisiones presupuesto vs real.
Errores comunes de presupuesto vs real
Hacerlo mensual y perder la deriva. Las revisiones mensuales detectan problemas después de cuatro semanas de acumulación. Un pulso semanal sobre MRR y burn toma diez minutos y detecta el mismo problema en la semana uno, cuando todavía es fácil de arreglar. Para SaaS en fase temprana donde la base de MRR es frágil, semanal es casi siempre mejor.
Demasiadas líneas de presupuesto. Una tabla de presupuesto vs real con 40 filas no se revisa consistentemente. Condensa a los seis números que mueven el negocio: MRR, nuevo MRR, churn, costes variables, burn, runway. Añade líneas solo cuando una decisión requiere más granularidad.
Sin umbral de varianza. Cada pequeña diferencia crea ruido. Establece umbrales explícitos — fallo de ingresos por encima del 5%, gasto por encima del 10%, caída de runway por encima de 0,5 meses — y solo señala esos. Por debajo del umbral: anótalo, no actúes. Esto evita que la revisión se convierta en un evento de ansiedad semanal.
Comparar contra un presupuesto de fantasía. Si las suposiciones del presupuesto fueron optimistas de entrada, la comparación mide lo lejos que la realidad aterrizó de la fantasía. Un presupuesto útil debería ser ligeramente incómodo de comprometerse — alcanzable en un escenario razonable, no aspiracional en uno perfecto.
Sin acción adjunta a la varianza. Una revisión que produce “interesante, vamos a vigilarlo” no es una revisión — es reporting. Cada varianza señalada debería producir una decisión, un responsable y un plazo. De lo contrario, el proceso se convierte en burocracia semanal en lugar de una herramienta de toma de decisiones.
Tratar todo el churn como equivalente. El churn voluntario (el cliente eligió irse) y el churn involuntario (pago fallido) requieren respuestas completamente distintas. Combinarlos en una sola línea de churn oculta qué tipo está causando la varianza y desperdicia la ventana de recuperación para pagos fallidos.
Automatizar presupuesto vs real
La principal fricción para ejecutar la revisión semanal es recoger los números manualmente. Tres inversiones en automatización se recuperan rápido:
Automatizar los datos de MRR desde Stripe. Nuevo MRR, MRR cancelado (separado entre voluntario y pago fallido), MRR de expansión y MRR final se pueden extraer de los eventos de suscripción de Stripe sin cálculo manual. NoNoiseMetrics hace esto automáticamente y muestra el waterfall semanal de MRR en el dashboard — el bloque de ingresos de la tabla presupuesto vs real se rellena solo.
Configurar alertas de facturación de Stripe para monitorizar costes variables. Si los costes variables incluyen costes de API facturados vía Stripe o servicios cloud, configura alertas de presupuesto en el dashboard de cada proveedor. La alerta se dispara cuando el gasto se acerca al umbral, no después de que llegue la factura.
Usar un tracker ligero y fijo para costes. Los costes fijos no cambian mucho mes a mes. Una lista simple de costes recurrentes con importes mensuales, actualizada solo cuando algo cambia, es suficiente. Agrégalo en una celda en lugar de construir un modelo de costes multipestaña.
La revisión semanal que tomaba 45 minutos manualmente típicamente toma 10 minutos cuando los datos de MRR están automatizados y los costes se mantienen en un solo tracker.
Estructura JSON para un tracker de presupuesto vs real
{
"budget_vs_actual": {
"period": "2026-04",
"currency": "EUR",
"revenue": {
"mrr_budget": 12000,
"mrr_actual": 11300,
"mrr_variance": -700,
"mrr_variance_pct": -5.8,
"new_mrr_budget": 1800,
"new_mrr_actual": 1500,
"expansion_mrr_budget": 400,
"expansion_mrr_actual": 380,
"churn_voluntary_budget": 300,
"churn_voluntary_actual": 360,
"churn_failed_payment_budget": 100,
"churn_failed_payment_actual": 220
},
"costs": {
"fixed_budget": 5500,
"fixed_actual": 5500,
"variable_budget": 2000,
"variable_actual": 2700,
"total_budget": 7500,
"total_actual": 8200,
"total_variance_pct": 9.3
},
"cash": {
"burn_budget": -4300,
"burn_actual": -3100,
"runway_budget_months": 11.0,
"runway_actual_months": 9.7
},
"variance_flags": {
"new_mrr_below_threshold": true,
"failed_payment_churn_above_threshold": true,
"variable_costs_above_threshold": true,
"runway_below_target": true
},
"actions": [
{
"flag": "failed_payment_churn",
"action": "Activar secuencia de dunning para la cohorte de pagos fallidos",
"owner": "founder",
"due": "esta semana"
},
{
"flag": "variable_costs",
"action": "Identificar el driver de coste API; configurar alerta de uso al 80% del real",
"owner": "founder",
"due": "esta semana"
},
{
"flag": "new_mrr",
"action": "Revisar conversión trial-to-paid en Stripe; verificar caída de activación",
"owner": "founder",
"due": "esta semana"
}
]
}
}El array actions es la adición más importante a una estructura JSON estándar de presupuesto vs real. Cierra el ciclo entre los números y las decisiones — que es la única razón para ejecutar la revisión en primer lugar.
FAQ
¿Qué es presupuesto vs real?
Presupuesto vs real es la comparación entre lo que un negocio planeó ganar y gastar (el presupuesto) y lo que realmente produjo en un periodo dado (los reales). La diferencia entre ellos — la varianza presupuestaria — determina si hay que cambiar algo y qué. Para fundadores SaaS, esta comparación típicamente cubre MRR, nuevo MRR, churn, costes variables, burn rate y runway.
¿Qué debería incluir un informe de presupuesto vs real?
Un informe presupuesto vs real de fase fundador debería incluir: un bloque de ingresos (MRR presupuestado vs real, nuevo MRR y churn — separado entre voluntario y pago fallido), un bloque de costes (fijos y variables), un bloque de caja (burn rate y runway), y un bloque de acciones listando una respuesta concreta por varianza señalada. Debería caber en una pantalla y tomar menos de 10 minutos en completar.
¿Qué es la varianza presupuestaria y cómo se calcula?
La varianza presupuestaria es la diferencia entre un número presupuestado y el resultado real: Varianza = Real − Presupuesto. En porcentaje: Varianza % = (Real − Presupuesto) / Presupuesto × 100. Para líneas de ingresos, una varianza negativa significa rendimiento inferior. Para líneas de costes, una varianza positiva significa gasto excesivo. Ambas deberían activar revisión si superan el umbral del fundador (típicamente 5% para ingresos, 10% para costes).
¿Cuál es un ejemplo de presupuesto vs real para una empresa SaaS?
Un ejemplo común: un fundador SaaS presupuesta €12.000 de MRR final y €7.500 en costes. Los reales llegan a €11.300 de MRR y €8.200 en costes. La varianza de ingresos es −€700 (−5,8%), causada principalmente por un fallo de nuevo MRR de €300 y un churn por pago fallido que duplicó el monto presupuestado. El sobrecostes es €700 (+9,3%), causado por el crecimiento de uso de API. Acciones: activar secuencia de recuperación de pagos fallidos, investigar el driver de coste API, actualizar el modelo financiero con suposiciones revisadas.
¿Cuál es la diferencia entre presupuesto vs real y real vs presupuesto?
Es la misma comparación descrita desde direcciones diferentes. “Presupuesto vs real” (presupuesto primero) enfatiza el plan como la baseline y muestra cómo la realidad se desvió. “Real vs presupuesto” (reales primero) muestra lo que pasó y cómo se compara con el plan. El cálculo y la utilidad son idénticos. El orden es una preferencia de presentación.
¿Con qué frecuencia debería un fundador SaaS revisar presupuesto vs real?
Semanalmente para productos en fase temprana donde el MRR es todavía frágil y el runway está por debajo de 18 meses. Mensualmente para productos más establecidos con patrones de crecimiento estables. La versión semanal es un pulso más corto — seis métricas clave, una tabla, una decisión — no una revisión completa del modelo. Las revisiones mensuales son más profundas e incluyen actualización de suposiciones.
¿Por qué es importante el churn por pago fallido en una revisión de presupuesto vs real?
El churn por pago fallido es la parte del “MRR cancelado” que viene de fallos de pago en lugar de cancelaciones voluntarias. Es parcialmente recuperable — una secuencia de dunning bien temporizada puede recapturar entre un 20–40% del churn por pago fallido en días. Si el churn por pago fallido se combina con el voluntario en el informe presupuesto vs real, la ventana de recuperación es invisible. Separar las dos líneas crea la oportunidad de actuar sobre la porción recuperable inmediatamente.
Hacer forecast desde un MRR sucio es hacer forecast mal. Empieza con números en los que puedas confiar →