MRR Stripe: como calcular corretamente

O MRR Stripe não é uma métrica nativa. O Stripe mostra receita, não receita recorrente mensal. O cálculo do MRR Stripe exige normalizar os dados brutos de assinatura: dividir os planos anuais por 12, excluir taxas únicas, lidar com rateios e contar apenas assinaturas ativas. O número “MRR” exibido no dashboard do Stripe está errado para a maioria dos SaaS com mistura de intervalos de cobrança. Este guia explica por que o número MRR Stripe em Billing → Overview é pouco confiável, percorre passo a passo como calcular o MRR a partir do Stripe corretamente e cobre todos os casos limites — trials, descontos, cupons e planos anuais — que a maioria dos guias pula.

MRR Stripe: o “MRR” nativo do Stripe não é normalizado. MRR correto = soma de todos os valores de assinaturas ativas convertidos em equivalentes mensais, excluindo taxas únicas, trials e assinaturas pausadas. Os planos anuais devem ser divididos por 12.

Calcule seu MRR a partir do Stripe → MRR normalizado com tratamento correto de planos anuais, gratuito até 10 000 € de MRR.

O Stripe mostra o MRR?

Sim e não. O Stripe Billing exibe um número “MRR” na seção Billing → Overview. O problema: ele não está corretamente normalizado.

O que o MRR do Stripe realmente conta: O Stripe calcula o MRR pegando todas as assinaturas ativas e somando seus valores convertidos para base mensal. A lógica de conversão soa correta, mas trata mal os casos limite para a maioria dos SaaS.

Por que está errado para empresas com planos anuais: O cálculo do MRR Stripe para assinaturas anuais é inconsistente. Em algumas configurações ele distribui o valor anual corretamente em 12 meses. Em outras — especialmente quando você mistura cobrança anual e mensal, ou quando clientes foram migrados manualmente entre planos — ele mostra a cobrança anual completa no mês do recebimento e zero nos demais.

O problema dos trials: O Stripe pode incluir ou excluir trials do MRR conforme sua configuração. Se um trial tem o primeiro período em 0 €, normalmente é excluído. Se usa um cupom de 100 % no primeiro mês, pode ser contado como 0 € de MRR ou excluído de forma inconsistente.

O teste prático: Compare o número MRR do Stripe com a soma manual dos valores dos seus planos ativos. Se baterem com diferença de poucos euros, o cálculo do Stripe funciona para sua configuração. Se divergirem — sobretudo se o número do Stripe disparar nos meses de renovação — você tem um problema de normalização de planos anuais. A maioria dos SaaS com mais de 15 % de clientes anuais verá divergência significativa, tipicamente 20-40 % de inflação nos meses de pico de renovação.

Para as regras completas sobre o que entra no MRR e o que não entra — incluindo rateios, taxas de setup e cobranças únicas — veja o guia de cálculo do MRR.

Por que um MRR Stripe correto importa

O MRR é a métrica fundadora sobre a qual quase todos os outros números SaaS são construídos. Errar nele e a cascata quebra.

Taxa de churn = MRR perdido ÷ MRR inicial. Se o MRR inicial está inflado por picos de planos anuais, o denominador do seu churn está errado: o churn parece menor nos meses de renovação intensa e maior nos meses calmos, oscilando seu sinal de retenção mais importante.

LTV = ARPU ÷ taxa de churn mensal. ARPU = MRR ÷ clientes. Inflar o MRR infla o ARPU e infla o LTV. Suas decisões de gasto com aquisição se apoiam num número errado em 20-40 %.

NRR e GRR: ambos usam o MRR inicial como denominador. Mesmo problema.

Forecasting: se você projeta o MRR à sua taxa de crescimento atual, um falso pico de renovações anuais faz o crescimento deste mês parecer maior do que é. Sua previsão de 6 meses estoura, e você se surpreende quando o crescimento “desacelera” no mês seguinte.

O MRR correto é a fundação. Tudo o mais decorre dele. Os 15 minutos investidos em normalizar seu cálculo de MRR Stripe valem mais do que quase qualquer outra tarefa de analytics que você faria esta semana. Faça uma vez, crie o hábito de checar mensalmente, e cada outra métrica SaaS calculada terá chão sólido. Construa errado uma vez e passará meses depurando LTV inflados e taxas de churn erradas antes de rastrear o problema até a origem.

O que o Stripe mostra em vez do MRR

O dashboard Stripe Billing fornece várias cifras de receita. Entender o que cada uma representa ajuda a identificar qual precisa correção.

“MRR” em Billing Overview: Estimativa do Stripe da receita recorrente mensal. Não confiável pelos motivos acima. Use como verificação de sanidade, não como sua fonte primária de MRR.

Net volume (aba Payments): Total de cobranças recebidas em um período. Inclui taxas únicas, taxas de setup e o valor total dos pagamentos de assinatura anual. É fluxo de caixa, não MRR. Um plano anual cobrado a 480 € aparece como 480 € em net volume no mês da cobrança e 0 € nos 11 meses seguintes.

Subscription revenue: Em Stripe Billing → Revenue → Subscription Revenue você vê a atividade mensal de cobrança de assinaturas. Mais útil, mas ainda mistura intervalos de cobrança e não normaliza planos anuais para equivalentes mensais.

Revenue Recognition (recurso pago): O add-on Revenue Recognition do Stripe calcula receitas reconhecidas corretamente segundo ASC 606, distribuindo a assinatura anual de 480 € em 12 meses a 40 €/mês. É preciso do ponto de vista contábil, mas é a receita reconhecida — não o MRR operacional que você usaria para acompanhar o crescimento.

Como calcular o MRR a partir dos dados do Stripe corretamente

A abordagem correta: pegue todas as assinaturas ativas, converta cada uma para seu equivalente mensal, some tudo.

A fórmula:

MRR = Σ (valor_assinatura × quantidade × fator_conversao_mensal)

Onde fator_conversao_mensal é:

Cobrança mensal: 1,0
Cobrança anual: 1/12 = 0,0833
Cobrança trimestral: 1/3 = 0,333
Cobrança semanal: 52/12 = 4,333

Cálculo passo a passo:

Passo 1. Liste todas as assinaturas ativas. Ativa = status active ou trialing (se você conta trials no MRR). Exclua canceled, past_due, paused e incomplete.

Passo 2. Para cada assinatura, obtenha o valor do plano e o intervalo de cobrança. No modelo de dados do Stripe: subscription.items[0].price.unit_amount (em centavos) e subscription.items[0].price.recurring.interval.

Passo 3. Converta para valor mensal.

valor_mensal = unit_amount / 100.0 × quantidade × fator_conversao_mensal

Passo 4. Some todos os valores mensais. Essa soma é seu MRR normalizado.

Abordagem via API Stripe:

import stripe

stripe.api_key = 'rk_live_...'  # chave restrita, somente leitura

subscriptions = stripe.Subscription.list(status='active', limit=100, expand=['data.items.data.price'])
mrr = 0
for sub in subscriptions.auto_paging_iter():
    for item in sub['items']['data']:
        price = item['price']
        amount = price['unit_amount'] / 100.0
        qty = item['quantity']
        interval = price['recurring']['interval']
        interval_count = price['recurring']['interval_count']
        
        # Normalizar para mensal
        if interval == 'month':
            monthly = amount * qty / interval_count
        elif interval == 'year':
            monthly = amount * qty / (12 * interval_count)
        elif interval == 'week':
            monthly = amount * qty * (52 / 12) / interval_count
        elif interval == 'day':
            monthly = amount * qty * (365 / 12) / interval_count
        
        mrr += monthly

print(f"MRR: {mrr:.2f} €")

Este script trata todos os intervalos de cobrança corretamente. Para assinaturas multi-item (clientes com add-ons), soma todos os itens.

Lidando com casos limite

Trials

Incluir trials no MRR? A convenção varia. A maioria dos founders SaaS exclui trials gratuitos do MRR porque nenhuma receita é recebida. Se um trial converte em plano pago, adicione a assinatura ao MRR no momento da conversão.

Trials “trialing-mas-pagos” (onde o período de trial usa um cupom descontando para 0 €): exclua-os do MRR até o cupom expirar e o cliente pagar preço cheio.

Implementação Stripe: filtre por status = 'active' apenas (não trialing) para excluir todos os trials do MRR.

Descontos e cupons

Cupons que reduzem o valor cobrado afetam o caixa recebido mas tipicamente NÃO são subtraídos do MRR na contabilidade SaaS padrão. O MRR representa o preço de tabela — a receita “comprometida”. Usar preço de tabela também evita flutuações de MRR quando cupons por tempo limitado expiram.

No entanto, se um cupom representa um compromisso de preço permanente (um desconto negociado que nunca expira), use o valor descontado no MRR. Consulte subscription.discount.coupon.duration; se forever, use o preço descontado.

Cupom Stripe no cálculo do MRR:

# Apenas para cupons permanentes
if sub.get('discount') and sub['discount']['coupon']['duration'] == 'forever':
    coupon = sub['discount']['coupon']
    if coupon.get('percent_off'):
        monthly *= (1 - coupon['percent_off'] / 100)
    elif coupon.get('amount_off'):
        monthly -= coupon['amount_off'] / 100.0  # converter centavos

Planos anuais: o caso limite crítico

Os planos anuais são a fonte mais comum de inflação do MRR quando calculado errado. A correção: dividir sempre os valores dos planos anuais por 12.

Plano anual: 480 €/ano → contribuição MRR: 40 €/mês

Se você conta os 480 € como MRR no mês da renovação, seu MRR dispara a cada renovação anual e parece menor nos meses sem renovação. A versão normalizada (40 €/mês constante) é o que você quer acompanhar para métricas de crescimento.

O que fazer com meses parciais: quando um cliente assina no meio do mês, alguns times rateiam a contribuição MRR do primeiro mês. A maioria dos founders pula o rateio por simplicidade — adiciona o valor mensal completo na data de criação da assinatura e remove na data de cancelamento. A diferença geralmente é imaterial em early stage.

Para o tratamento completo do que um MRR normalizado inclui e exclui — e por que o número nativo do Stripe erra para muitas configurações de cobrança — o guia de definição do MRR cobre todos os casos.

Stripe Sigma: abordagem SQL

O Stripe Sigma permite consultar seus dados Stripe diretamente em SQL. Aqui uma query Sigma para MRR normalizado:

WITH active_subs AS (
  SELECT
    s.id,
    si.price_unit_amount / 100.0 as price_amount,
    si.quantity,
    p.recurring_interval,
    p.recurring_interval_count
  FROM subscriptions s
  JOIN subscription_items si ON si.subscription_id = s.id
  JOIN prices p ON p.id = si.price_id
  WHERE s.status = 'active'
)
SELECT
  SUM(
    CASE recurring_interval
      WHEN 'month' THEN price_amount * quantity / recurring_interval_count
      WHEN 'year'  THEN price_amount * quantity / (12.0 * recurring_interval_count)
      WHEN 'week'  THEN price_amount * quantity * 52.0 / (12.0 * recurring_interval_count)
      ELSE 0
    END
  ) AS normalized_mrr
FROM active_subs;

Isso lida com intervalos mensais, anuais e semanais com a normalização correta.

Limitações do Sigma para tracking de MRR: O Sigma te dá o MRR de agora. Não armazena snapshots históricos de MRR — então você não pode ver como o MRR estava em 1º de janeiro. Para análise de tendência, precisaria executar essa query diariamente e armazenar resultados externamente, ou usar uma ferramenta que mantém o histórico automaticamente.

O Sigma também não cobre:

O waterfall MRR (decomposição new/expansion/contraction/churn) sem manter tabelas mensais de snapshots
Tracking de conversão trial-para-pago no nível de MRR
Decomposição de MRR por plano e por coorte sem complexidade adicional de query

O Sigma é a ferramenta certa se você tem habilidades SQL e uma pergunta pontual sobre seus dados Stripe. Para monitoramento contínuo do MRR, o overhead de manutenção das queries Sigma à medida que seu pricing evolui torna ferramentas analytics dedicadas mais práticas para a maioria dos founders.

Movimentos de MRR: além de um único número

Uma vez que você tem MRR normalizado, a próxima camada é entender o que está dirigindo as mudanças mês a mês. O Stripe te dá o MRR total — um número estático. O que você realmente precisa para entender o crescimento é um waterfall MRR:

Net New MRR = New MRR + Expansion MRR − Contraction MRR − Churned MRR

New MRR: receita de clientes que não existiam no mês anterior. Expansion MRR: receita adicional de clientes que fizeram upgrade (pagam mais este mês do que no anterior). Contraction MRR: receita reduzida de clientes que fizeram downgrade. Churned MRR: receita de clientes que cancelaram.

O Stripe não calcula essa decomposição nativamente. Ele sabe que cancelamentos aconteceram mas não rastreia expansion vs contraction vs novas assinaturas no formato waterfall. O Stripe Sigma pode reconstruí-lo unindo dois snapshots mensais de assinaturas, mas exige que você mantenha esses snapshots por conta própria.

Por que o waterfall importa:

Uma taxa de crescimento de MRR te diz o resultado. O waterfall te diz a causa. Dois negócios crescendo MRR a 10 % ao mês podem parecer idênticos em um único gráfico de MRR mas ter motores muito diferentes:

Negócio A: 15 % new MRR, 8 % churned MRR → crescimento puxado por aquisição, vulnerável se a aquisição desacelerar
Negócio B: 8 % new MRR, 3 % expansion MRR, 2 % churned MRR → crescimento de fonte mista, mais defensável

O waterfall também é a ponte entre MRR e Net Revenue Retention (NRR): NRR = (MRR inicial + expansion − contraction − churn) ÷ MRR inicial. Se você calcula NRR manualmente, precisa dos componentes do waterfall.

Para planejamento de ARR, multiplique seu MRR mensal normalizado por 12. ARR = MRR × 12. As mesmas regras de normalização se aplicam: planos anuais ÷ 12, depois × 12 = valor do plano anual, o que está correto.

Ferramentas de terceiros para MRR Stripe

Ferramenta	Normalização MRR	Tendências históricas	Preço inicial
NoNoiseMetrics	✅ Correta (anual ÷12)	✅ Histórico completo	Gratuito → 79 €/mês
ChartMogul	✅ Correta	✅ Histórico completo	100 €+/mês
Baremetrics	✅ Correta	✅ Histórico completo	108 €+/mês
Stripe Sigma	✅ (via SQL)	❌ Apenas ponto no tempo	~10 €/mês
Planilha manual	Depende	❌ Requer manutenção	Gratuito

Para o panorama amplo do que a camada analytics do Stripe entrega vs o que requer ferramentas externas, veja a análise de lacunas do Stripe Analytics.

FAQ

O Stripe mostra o MRR?

O Stripe Billing Overview exibe uma cifra de MRR, mas ela é frequentemente imprecisa para negócios com planos anuais ou intervalos de cobrança mistos. A cifra pode disparar nos meses de renovação para clientes anuais e mostrar MRR menor nos meses sem renovação. Para um MRR correto, normalize todos os valores de assinatura para seu equivalente mensal: planos anuais ÷ 12, planos mensais × 1.

Como calculo o MRR a partir do Stripe?

Liste todas as assinaturas ativas via API Stripe ou Sigma. Para cada assinatura, pegue valor do plano × quantidade e divida pelo intervalo de cobrança em meses (anual = 12, trimestral = 3, mensal = 1). Some todos os equivalentes mensais. Exclua trials, assinaturas canceladas, assinaturas pausadas e cobranças únicas.

Por que o MRR do Stripe está errado?

O cálculo de MRR do Stripe trata planos anuais de forma inconsistente conforme sua configuração de cobrança. Pode também incluir trials, contar valores anuais completos em meses de renovação, ou perder upgrades no meio do ciclo. A abordagem mais segura é calcular o MRR por conta própria a partir da lista de assinaturas usando conversão de intervalos normalizada.

Como vejo o MRR no Stripe sem Sigma?

Stripe Billing → Revenue mostra um gráfico de receita e métricas de assinatura. Para MRR normalizado, a abordagem manual mais confiável: exporte suas assinaturas ativas em CSV, adicione uma coluna para o equivalente mensal (valor anual ÷ 12) e some. Para tracking contínuo, conecte o Stripe a uma ferramenta que calcule a normalização automaticamente.

Qual é a fórmula do MRR Stripe?

MRR normalizado = soma de (valor equivalente mensal × quantidade) para todas as assinaturas ativas. Equivalente mensal = valor do plano ÷ meses de cobrança (1 mensal, 12 anual, 3 trimestral). Exclua assinaturas pausadas, canceladas, incompletas e em trial.

Como devo lidar com planos anuais no MRR Stripe?

Sempre divida os valores dos planos anuais por 12. Um plano de 480 €/ano contribui 40 €/mês ao MRR. Nunca adicione os 480 € inteiros ao MRR no mês da renovação — isso cria picos falsos que obscurecem sua tendência real de crescimento. Os 40 € constantes são o valor correto para cada mês em que o cliente está ativo.

O Stripe mostra o MRR nativamente?

Não. O Stripe mostra volume bruto (todas as cobranças), não MRR normalizado. O Stripe não anualiza planos mensais, não exclui cobranças únicas dos totais recorrentes e não trata o rateio corretamente para fins de MRR. Você precisa calcular o MRR por conta própria a partir dos dados de assinatura, ou usar uma ferramenta de analytics conectada ao Stripe que normalize automaticamente.

Como lido com MRR multi-moeda no Stripe?

Converta todos os valores de assinatura para uma moeda base usando a taxa de câmbio no momento da fatura. O Stripe fornece o campo currency em cada assinatura. Aplique taxas de conversão consistentes — ou médias mensais ou taxas spot diárias — mas seja consistente. A maioria das ferramentas de analytics lida com isso automaticamente quando conectada ao Stripe.

Calcule seu MRR a partir do Stripe → MRR corretamente normalizado com tratamento de planos anuais, waterfall MRR e decomposição por coorte, gratuito até 10 000 € de MRR.

Ferramenta gratuita
Experimente o template Dashboard MRR →
Template de tracking de MRR pronto para uso, sem cadastro.