Trampas MRR: 9 anti-patrones que falsean el crecimiento

Un fundador abre el dashboard, ve 14.200 € de MRR y se siente seguro. Tres semanas después, el cliente más grande cancela, el pago de otro falla y, en una mirada más detallada, 2.100 € de ese total eran tarifas de onboarding que nunca se van a repetir. La verdadera base recurrente era 9.800 €. Nadie mintió, nadie se equivocó en el Excel. La definición de ingresos recurrentes mensuales estaba simplemente mal.

Esta guía no responde a la pregunta “qué es MRR” (eso lo cubre el glosario sobre la definición MRR). Responde a la pregunta más operativa: qué trampas inflan el MRR en casi cualquier cuenta Stripe por debajo de 100k de facturación, cómo reconocerlas y cómo eliminarlas del reporting MRR. Si vuestro update semanal a inversores o cofundadores incluye un número MRR que no podéis desmontar en treinta segundos, al menos una de estas trampas MRR está activa.

Por qué un MRR limpio es tan raro

Stripe es un motor de facturación, no una herramienta para calcular el MRR. La API devuelve subscriptions, invoices, charges y customers, pero no devuelve un valor MRR ya calculado. Cada fundador que lee el MRR desde Stripe está construyendo implícitamente una definición MRR propia. La mayoría de esas definiciones MRR están incompletas, porque la realidad es desordenada: los trials conviven con las suscripciones activas, los prepagos anuales parecen un salto enorme del MRR, los cupones reducen el total realmente facturado, las tarjetas fallidas se quedan semanas en estado past_due.

Las trampas de abajo no son hipótesis. Son los anti-patrones que aparecen con más frecuencia en cuentas Stripe reales, ordenados por impacto financiero sobre el valor MRR reportado. Cada trampa describe: qué ocurre, cómo detectarla en Stripe y cómo debería verse la contribución limpia a los ingresos recurrentes mensuales.

Trampa 1: las tarifas únicas se cuentan como recurrentes

Tarifas de setup, paquetes de onboarding, trabajos de implementación, horas de consultoría, formación, migraciones de datos. Todo eso aparece en Stripe como Charge o Invoice Line Item. Quien lee los reports de Stripe sobre el “Total Volume” termina empujando automáticamente esos importes hacia la base recurrente.

Detección en Stripe. En cada Subscription Item, el objeto price tiene un campo recurring. Si recurring es null, la línea no es recurrente. Un paquete de onboarding de 1.500 € tiene típicamente type: "one_time", recurring: null y aparece, aun así, en la misma invoice que la subscription mensual, porque Stripe las factura juntas.

Reporting limpio. Filtra todas las Subscription Items con price.recurring != null e incluye solo su importe mensual normalizado en el MRR. La línea de onboarding es facturación, no es recurrente. Va en la línea “Servicios” de la cuenta de pérdidas y ganancias, no en la métrica MRR.

Trampa 2: los trials ya están en la base

En Stripe, una subscription comienza su ciclo de vida con status: trialing antes incluso de que se cobre nada. Quien filtra por status != canceled arrastra los trials hacia el MRR. Resultado: un mes de crecimiento MRR parece excepcional, porque arrancaron 30 trials, de los cuales solo 4 acabarán convirtiéndose en cuentas pagadoras y aportando MRR real.

Detección en Stripe. El status de una subscription puede ser trialing, active, past_due, unpaid, canceled, incomplete, incomplete_expired o paused. trialing significa: ningún primer pago exitoso todavía. incomplete significa lo mismo (el pago inicial nunca pasó).

Reporting limpio. Solo las subscriptions con status: active O past_due (con regla de gracia definida, ver Trampa 4) entran en el MRR. Los trials se siguen en una métrica MRR separada “Trial pipeline”, con su propia tasa de conversión, que no tiene nada que ver con el valor MRR reportado.

Trampa 3: los pagos anuales no se normalizan al mes

Un cliente firma un contrato anual y paga 2.400 € por adelantado. En Stripe aparece una invoice de 2.400 €. Quien extrae reports basados en volumen ve en ese mes un salto MRR de 2.400 €, seguido de estancamiento en los meses siguientes porque no llegaron nuevos pagos anuales.

Detección en Stripe. Subscription Item price.recurring.interval es month, year, week o day. interval_count lo multiplica (por ejemplo interval: month, interval_count: 3 = trimestral). Cualquier valor distinto de month con interval_count: 1 debe normalizarse.

Normalización limpia:

Plan anual: contribución mensual = unit_amount / 100 / 12
Plan trimestral: contribución mensual = unit_amount / 100 / 3
Plan semanal: contribución mensual = unit_amount / 100 × 4.345

Estos importes normalizados entran en la base recurrente todos los meses a partir del current_period_start de la subscription, no como efecto puntual en el mes de pago.

Trampa 4: los pagos fallidos se quedan atascados en la base

Stripe marca como past_due las subscriptions con pago fallido. En los 7 a 21 días siguientes intenta los Smart Retries. Durante ese periodo el cliente parece todavía pagando, pero no genera cashflow real. Sin una regla clara, todas las subscriptions past_due acaban en el MRR y sobrestiman sistemáticamente el valor MRR real.

Detección en Stripe. Subscription con status: past_due, latest_invoice.attempt_count > 0 y latest_invoice.next_payment_attempt en el futuro. Tras el error final de los retries, el status pasa a unpaid o canceled (según la configuración Smart Retry).

Reporting limpio. Una regla dura, definida una vez, aplicada siempre. Dos opciones son limpias: (a) past_due permanece en la métrica durante 7 días y luego se excluye, o (b) past_due sale de inmediato de la base y solo se reactiva tras un retry exitoso. Importante: la misma regla cada mes, documentada.

Trampa 5: cupones y descuentos se ignoran

Un cliente en el plan de 99 €/mes con un cupón lifetime del 30% contribuye 69,30 € al MRR, no 99 €. Stripe aplica el descuento solo al generar la invoice. Quien suma directamente unit_amount de subscription ignora completamente el descuento y sobrestima el MRR.

Detección en Stripe. Subscription discount contiene coupon con percent_off o amount_off y duration (forever, once, repeating). Los descuentos a nivel customer están en customer.discount y se aplican a todas las subscriptions del cliente.

Reporting limpio. Contribución efectiva = precio de tarifa × (1 − percent_off / 100), o precio − amount_off. Con duration: once el descuento solo vale un periodo, con repeating durante N meses, con forever es permanente. La contribución cambia cuando el descuento expira.

Trampa 6: varias subscriptions activas por cliente se vuelven una sola

Un customer Stripe puede tener todas las subscriptions activas que quiera. Los clientes SaaS B2B suelen tener una subscription base más subscriptions separadas para add-ons (asientos adicionales, módulos premium, workspaces facturados aparte). Código que lee solo la primera o la última subscription por customer subestima sistemáticamente el MRR.

Detección en Stripe. Customer.subscriptions es una lista, no un único objeto. Algunos clientes tienen tres o cuatro subscriptions en paralelo, cada una con estado, plan y descuento propios.

Reporting limpio. Itera por todas las subscriptions de cada customer, suma las contribuciones mensuales normalizadas de todas las que tengan status: active (o past_due por regla) y price.recurring != null.

Trampa 7: subscriptions multidivisa sumadas en bruto

Si una parte de los clientes paga en EUR, otra en USD y otra en GBP, la suma bruta de los importes carece de sentido. 1.000 USD + 1.000 EUR + 1.000 GBP, expresados en euros, oscilan entre 2.700 € y 3.300 € según el tipo de cambio del día.

Detección en Stripe. Subscription Item price.currency (usd, eur, gbp, etc.). Las cuentas Stripe pueden tener varias divisas activas a la vez.

Reporting limpio. Define una divisa de reporting (típicamente EUR para fundadores europeos, USD para estadounidenses). Convierte todas las demás divisas con un tipo FX consistente, idealmente el de fin de mes del BCE. El tipo cambia mes a mes, el método se mantiene fijo.

Trampa 8: “Bookings” y “Net” se mezclan

Algunos fundadores reportan dos números, “Bookings” (suma de precios de tarifa) y “Net” (después de descuentos), y los mezclan en el tiempo porque herramientas distintas usan definiciones distintas. Los decks para inversores muestran el número mayor, los forecasts internos el menor. Resultado: nadie confía ya en la métrica MRR.

Detección en Stripe. Subscription latest_invoice.subtotal (antes de descuentos e impuestos) vs. total (después de descuentos, antes de impuestos) vs. amount_paid (efectivamente cobrado).

Reporting limpio. Elige una definición, documéntala, úsala en todos los reports. Recomendación: Net (después de descuentos, antes de impuestos), porque refleja el cashflow real generado mes a mes.

Trampa 9: las subscriptions en pausa siguen contando

Stripe permite subscriptions en estado paused (vía pause_collection). El cliente conserva el acceso, pero Stripe no factura. Sin regla explícita, las subscriptions en pausa permanecen en el MRR e inflan el valor MRR reportado.

Detección en Stripe. Subscription pause_collection no es null. El campo behavior indica qué ocurre durante la pausa (keep_as_draft, mark_uncollectible, void).

Reporting limpio. Las subscriptions en pausa salen del MRR hasta que la pausa termine y el siguiente pago sea exitoso. El número de subscriptions en pausa es una métrica de health separada, indicador temprano de churn, paralela a la base recurrente principal.

Impacto de las trampas: un ejemplo numérico

Una cuenta con 18.500 € nominales se lee activamente con las 9 trampas. Tras la limpieza:

Limpieza	Impacto
Excluir tarifas de onboarding (Trampa 1)	−1.200 €
Excluir subscriptions en trial (Trampa 2)	−2.100 €
Normalizar pago anual (Trampa 3)	−800 € (de 2.400 € a 200 €/mes)
Excluir past-due > 7 días (Trampa 4)	−450 €
Aplicar cupones (Trampa 5)	−340 €
Capturar al completo multi-sub (Trampa 6)	+1.100 €
Normalizar FX a EUR (Trampa 7)	−180 €
Excluir subs en pausa (Trampa 9)	−250 €
Valor limpio	14.280 €

El valor MRR nominal sobrestimaba la base recurrente en un 30%. Con la cifra MRR limpia el fundador toma decisiones distintas sobre hiring, runway de caja e hipótesis de crecimiento.

Cómo verificar las trampas una vez al mes

Día 1 de cada mes: snapshot. Nunca a mitad de mes, con eventos de billing en curso. Snapshot justo después de las 00:00 UTC del primer día es ideal.

Ocho filtros aplicados con coherencia. Sin trials, sin pausas, regla past-due definida, líneas únicas excluidas, planes anuales y trimestrales normalizados, cupones aplicados, tipo de cambio a la divisa de reporting, suma de todas las subscriptions activas por cada customer.

Calcula el bridge MRR contra el mes anterior. Nuevo MRR + Expansión − Contracción − Churn − Reactivación debe explicar exactamente la diferencia entre el valor MRR del mes pasado y el actual. Si no cuadra, al menos una trampa MRR está activa.

Documenta mensualmente qué cubre exactamente la definición MRR. Una nota corta basta: qué estados se incluyen, qué método FX, qué umbral past-due. Esa nota cambia como mucho una vez al año.

Para la lógica de forecasting que parte de una base limpia, la guía de forecasting cubre cómo pasar de la cifra limpia a un modelo confiable. Para el dashboard completo que aloja esta métrica, la guía del dashboard de 8 métricas cubre el layout en una sola pantalla.

Rutina semanal de auditoría MRR

Incluso con una definición MRR limpia, una rutina semanal mantiene la calidad del dato. Cada lunes por la mañana, diez minutos: abre el panel de subscriptions de Stripe, cuenta cuántas subscriptions están en past_due desde hace más de 7 días y compara con la semana anterior. Examina cada nueva subscription de la semana para confirmar que price.recurring no es null. Comprueba que ningún cupón nuevo se ha aplicado sin reflejarse en los cálculos. Anota en una línea el delta de la base recurrente con una sola causa atribuible. Esta rutina de higiene de datos no sustituye al snapshot mensual, pero intercepta las trampas MRR antes de que se propaguen a un report enviado a inversores o cofundadores. Tres descuidos por semana descubiertos tarde se convierten en un report equivocado a fin de mes, y un report MRR equivocado en manos de un inversor cuesta mucho más que diez minutos de un lunes por la mañana.

FAQ

¿Qué trampa MRR tiene el mayor impacto financiero?

En la mayoría de las cuentas Stripe por debajo de 100k de facturación es el pago anual no normalizado (Trampa 3), seguido de las tarifas de onboarding incluidas (Trampa 1) y los trials en la base (Trampa 2). Juntas, esas tres pueden inflar la base recurrente entre un 20 y un 40%. El valor MRR parece correcto hasta que una comparación con el mes siguiente muestra que la “tasa de crecimiento” era solo un boom de onboarding o un único pago anual.

¿Cómo sé si mis datos Stripe entregan un MRR limpio?

Tres tests rápidos. Primero: el bridge debe cuadrar. Nuevo MRR + Expansión − Contracción − Churn − Reactivación debe explicar exactamente la diferencia entre dos snapshots consecutivos. Segundo: la tasa de conversión de trials no debe aparecer en ninguna parte de la base, sino como métrica separada. Tercero: un pago anual de 2.400 € debe contribuir 200 €/mes a los ingresos recurrentes mensuales, no 2.400 € en el mes de pago. Si uno de esos tests falla, al menos una trampa está activa.

¿Las subscriptions past-due deben permanecer en el MRR?

No hay una respuesta universalmente correcta, solo una regla coherente. Dos opciones limpias: (a) past-due permanece 7 días en la base y luego sale hasta el retry exitoso, o (b) past-due sale de inmediato. Lo importante es que la regla sea la misma cada mes y esté documentada. La incoherencia entre meses es la verdadera trampa MRR.

¿Cómo gestiona un MRR limpio las subscriptions multidivisa?

Elige una divisa de reporting, convierte todas las demás con el tipo FX de fin de mes de una fuente oficial (BCE para reporting en EUR, Federal Reserve para USD). El tipo cambia cada mes, el método se mantiene fijo. Nunca sumar en bruto importes de subscriptions en divisas distintas: el valor MRR puede oscilar entre un 10 y un 20% según el tipo del día.

¿Cuál es la diferencia entre “Bookings MRR” y “Net MRR”?

Bookings MRR es la suma de los precios de tarifa de todas las subscriptions activas. Net es esa suma tras la aplicación de todos los cupones y descuentos, antes de impuestos. La versión Net refleja el cashflow real que la base recurrente genera cada mes y es la cifra de reporting más fiable. Bookings sobrestima sistemáticamente en cualquier cuenta que use descuentos o cupones promocionales.

¿Cada cuánto debería revisar la definición de MRR?

Una vez al año, o cuando se introduce un nuevo tipo de plan (anual, trimestral, basado en uso), o cuando se añade un nuevo segmento de clientes (por ejemplo, enterprise con contratos custom). La regla debe quedar documentada y visible como configuración en la herramienta de reporting, para que un cambio en la definición MRR sea una decisión consciente y no un drift silencioso del valor reportado.

¿Por qué el valor MRR del Stripe Dashboard no basta?

Stripe Sigma y el Stripe Dashboard muestran reports de volumen y una estimación MRR basada en supuestos simplificados: los trials se excluyen, pero los past-due se cuentan, el tratamiento FX no es configurable, charges únicos pueden colarse en algunas queries Sigma. Para un update semanal a menudo no basta, porque la definición no es gobernable y no todas las nueve trampas se interceptan de forma limpia.

Deja de calcular el MRR en una hoja de cálculo. MRR limpio, ARR y el waterfall completo, gratis hasta 10.000 € →

Free Tool
Try the MRR Dashboard Template →
Interactive calculator, no signup required.