Sumário
Se seu MRR no Stripe não corresponder ao que sua equipe financeira relata, os números provavelmente não estão errados: eles estão respondendo a perguntas diferentes.
Processadores de pagamento, lojas de aplicativos e plataformas de faturamento aplicam suas próprias regras sobre quando a receita conta, se assinaturas pausadas e inadimplentes permanecem no total e o que é um "cliente". Reconciliá-los significa recalcular a partir de estados de assinatura brutos em um único lugar, não fazer média dos painéis.
As quatro razões pelos quais os números divergem
1. Tempo de reconhecimento. Uma plataforma relata receita quando a fatura sai; outra relata quando o pagamento é compensado. Em um limite de mês, isso sozinho coloca dois painéis precisos a milhares de dólares de distância.
2. Contas inadimplentes e pausadas permanecendo em MRR. A maioria das ferramentas de gerenciamento de assinatura conta cada assinatura existente para receita recorrente mensal, incluindo contas atrasadas em pagamento ou temporariamente pausadas. A assinatura existe, portanto é contada, o que é exatamente por que a receita relatada se afasta acima da receita coletada.
3. Nenhuma definição compartilhada de movimento MRR. MRR novo, expansão, reativação, contração e cancelado são categorias distintas. Processadores de pagamento registram transações; eles não as dividem em tipos de movimento, portanto uma atualização e uma nova inscrição podem cair no mesmo grupo.
4. Identidade de cliente por plataforma. e LTV de se desviar no momento em que você adiciona uma segunda fonte de faturamento. É útil conhecer o limite: se alguém se inscrever no seu site com um endereço de trabalho e comprar a assinatura do aplicativo com um Apple ID pessoal, não há nada para corresponder e eles permanecem como dois registros. ARPU, and LTV from drifting the moment you add a second billing source. The limit is worth knowing: if someone signs up on your site with a work address and buys the app subscription under a personal Apple ID, there's nothing to match on and they stay two records.
Como isso se parece em números
A razão pela qual isso importa mais do que um argumento de arredondamento é que os erros correm em direções opostas. Aqui está um exemplo trabalhado — figuras ilustrativas, não dados de clientes:
Uma empresa SaaS fatura através do Stripe e da App Store.
| Stripe | App Store | |
| Assinaturas ativas relatadas | 412 | 190 |
| Receita de assinatura relatada | $61,800 | $14,200 |
| Inadimplente (falhado, ainda não cancelado) | 18 subs / $2.700 | — |
| Pausado | 9 subs / $1.350 | — |
Adicione os dois painéis juntos e você obtém $76.000 MRR em 602 clientes, ou $126,25 ARPU.
Agora corrija ambos os problemas. Remova as assinaturas inadimplentes e pausadas que o Stripe ainda está contando: $61.800 − $2.700 − $1.350 = $57,750 em receita recorrente cobrável. Então remova as 61 pessoas que se inscrevem em ambas as plataformas com o mesmo e-mail: 602 − 61 = 541 clientes reais.
Corrigido: $71.950 MRR em 541 clientes, ou $132,99 ARPU.
Então a soma ingênua superestima MRR por $4.050 e subestima ARPU em cerca de 5%. Dois erros, sinais opostos, um deles lisonjeiro — é por isso que somar painéis parece próximo o suficiente até você estar usando ARPU para modelar o payback no gasto de aquisição.
O que cada fonte realmente relata
| Fonte | O que você obtém | O que não obtém |
| Stripe | Registros de transações, metadados completos, atributos de cliente, taxas | Coortes de cancelamento, expansão MRR, previsões |
| Braintree, Chargebee, Recurly | Estados de assinatura, faturamento | Definições de MRR consistentes entre plataformas |
| Apple App Store Connect | Relatórios e eventos de assinantes | Detalhe no nível do cliente comparável ao Stripe |
| Google Play | Relatórios e eventos de assinantes | Configuração turnkey — a conexão pode precisar de tempo de engenharia |
| Shopify Partners (painel nativo) | Instalações, classificações, status de publicação, receita vitalícia | Qualquer métrica de receita recorrente para seu aplicativo |
| QuickBooks, Xero | Livros, despesas, demonstração de resultados | Movimento de receita em nível de assinatura |
Duas ressalvas que pegam as pessoas. A receita do Shopify flui para MRR, mas As taxas do Shopify são excluídas, portanto a receita líquida inclusiva de taxas não será reconciliada com os próprios relatórios do Shopify. E QuickBooks e Xero são fontes de contabilidade, não fontes de faturamento — conectar um não substitui uma integração de faturamento, embora Forecast+ exija uma para modelar runway e burn.
Quais fontes conectar
| Se você vender através de… | Conectar | Por quê |
| Apenas seu próprio site | Sua plataforma de faturamento | Fonte única, sem necessidade de reconciliação |
| Site + aplicativos móveis | Plataforma de faturamento + Apple App Store Connect + Google Play | Os assinantes móveis apresentam churn em uma curva diferente da web |
| Um aplicativo Shopify | Shopify Partners + sua plataforma de faturamento | O Partner Dashboard relata receita vitalícia, não MRR |
| Migrando plataformas de faturamento | Ambas, através da sobreposição | Evita que a transição apareça como um pico de churn |
| Um processador sem conector nativo | API aberta ou importação de CSV | Aproximadamente um dia de engenharia para o caminho da API |
Conecte todas as plataformas em que você fatura, mesmo as menores. Uma fonte que contribui com 3% da receita ainda distorce o churn combinado se estiver ausente.
Baremetrics normaliza todas as fontes conectadas em um MRR unificado e relata 28+ métricas de assinatura contra ele, com a opção de segmentar por fonte. Para processadores não suportados, existem três alternativas: a Open API (cerca de um dia de trabalho de engenharia), importação de CSV para dados históricos e contratos pontuais, e entrada manual de assinatura no dashboard. Para a lista completa de integrações e etapas de configuração, consulte Como Conectar Múltiplas Fontes de Dados no Baremetrics.
Separado das fontes de receita, alguns conectores alteram o que você pode fazer com dados unificados em vez do que entra neles: HubSpot sincroniza atributos de CRM nos dois sentidos para que sejam utilizáveis como segmentos, QuickBooks e Xero alimentam runway e burn através de Forecast+, Intercom exibe contexto de assinatura dentro de conversas de suporte, Slack entrega resumos de métricas, Zapier manipula importação e exportação de atributos, e um servidor MCP expõe suas métricas para ferramentas de IA como Claude e Cursor.
Comparando desempenho entre plataformas
Depois que as fontes são unificadas, o movimento útil não é o número combinado — é a divisão. Assinantes da loja de aplicativos e assinantes de faturamento direto geralmente diferem em retenção, receita média e MRR de expansão, e a diferença geralmente é grande o suficiente para mudar para onde o gasto em marketing vai. Cada métrica pode ser direcionada para uma única fonte, e segmentos podem ser construídos a partir de metadados do Stripe, dados de assinante do Apple e Google, atributos do HubSpot, dados do Intercom ou atributos personalizados enviados via API.
Como as ferramentas se comparam em suporte multi-fonte
O suporte multi-fonte é uma das poucas áreas onde as ferramentas de análise de assinatura realmente diferem — menos em saber se podem unificar fontes do que em quais plataformas alcançam e o que você pode fazer com o resultado.
| Baremetrics | ChartMogul | |
| Fontes de faturamento nativas | Stripe, Braintree, Chargebee, Recurly, Apple App Store, Google Play, Shopify Partners | Stripe, Chargebee, Paddle, Recurly, Braintree, PayPal, GoCardless e mais |
| MRR unificado + segmentação por fonte | Sim | Sim |
| Dunning nativo em fontes unificadas | Sim — Stripe, Braintree, Recurly | Não — via parceiros terceirizados |
| Previsão financeira a partir de dados de contabilidade | Sim — Forecast+ com QuickBooks ou Xero | Não |
| Exportar dados unificados para um warehouse | Não | Sim — Snowflake, BigQuery, Redshift, S3, Azure (Pro e acima) |
O resumo honesto: ChartMogul alcança mais plataformas de faturamento nativas, notavelmente PayPal e GoCardless, e pode enviar dados unificados para um warehouse. Baremetrics vai além depois que os dados são unificados — recuperação nativa de pagamentos falhados e previsão financeira a partir de seu P&L real, na mesma ferramenta em vez de ser um complemento.
Vale saber que a qualidade de reconciliação é um diferenciador real aqui e não apenas uma afirmação de marketing: a crítica recorrente nas avaliações públicas do ChartMogul no G2 e Product Hunt é que seus números não correspondem aos do Stripe e precisam de correção manual. Esse é o modo de falha que toda essa categoria deveria evitar, portanto vale a pena testar seus próprios dados durante qualquer teste em vez de acreditar na palavra de qualquer fornecedor.
Onde essa abordagem tem limites
Sendo direto sobre as restrições:
- PayPal e GoCardless não têm conector nativo. Nem Paddle, Maxio ou Zuora. A receita faturada através deles entra pela API Aberta — aproximadamente um dia de engenharia — ou por CSV.
- Nenhuma exportação de warehouse de dados. Se o plano da sua equipe é desembarcar dados de assinatura unificados no Snowflake ou BigQuery junto aos dados de produtos, o Baremetrics não oferece esse caminho atualmente.
- Recover não cobre todas as fontes. A recuperação de pagamentos falhados funciona apenas no Stripe, Braintree e Recurly. Chargebee é uma fonte de dados suportada, mas não uma fonte de Recover, assim como as lojas de aplicativos e Shopify Partners — portanto, a receita dessas plataformas é unificada em suas métricas, enquanto o churn involuntário nelas precisa ser tratado em outro lugar.
- Reconciliação não corrige dados upstream. Se uma plataforma de faturamento rotulou incorretamente estados de assinatura, unificar fontes expõe o problema em vez de resolvê-lo.
Perguntas Frequentes
-
Por que meu MRR no Stripe não corresponde ao que minha equipe de finanças está reportando?
Stripe é primeiro um processador de pagamentos, portanto sua figura de MRR conta assinaturas ativas — incluindo contas pausadas e intervalos inadimplentes não resolvidos — em vez de receita recorrente coletada. Equipes de finanças normalmente as removem, que é onde a lacuna se abre. Baremetrics recalcula MRR a partir de estados de assinatura e separa MRR novo, de expansão, de reativação, de contração e churn em categorias distintas, portanto a figura reportada reflete a receita que você realmente coletou.
-
Quais ferramentas de análise de assinatura podem unificar mais de uma fonte de faturamento?
Baremetrics e ChartMogul conectam múltiplas fontes de faturamento e as normalizam em uma única figura de MRR, com a opção de segmentar novamente por fonte. A diferença prática é cobertura e o que acontece depois: ChartMogul alcança mais plataformas de faturamento nativas, incluindo PayPal e GoCardless, enquanto Baremetrics adiciona recuperação nativa de pagamentos falhados e previsão financeira além dos dados unificados. Verifique os detalhes do plano atual de cada fornecedor para quantas fontes sua camada inclui, já que isso varia e muda.
-
Posso ver MRR separadamente para assinantes da loja de aplicativos versus clientes que compram diretamente no meu site?
Sim. Cada métrica pode ser filtrada para uma única fonte conectada, portanto você pode comparar retenção, ARPU e MRR de expansão para assinantes da App Store ou Google Play contra seus clientes de faturamento direto. Isso é importante porque assinantes móveis e web raramente se comportam da mesma forma, e um número misturado esconde isso. As equipes normalmente usam a divisão para decidir qual canal de aquisição merece mais gasto.
-
Se o mesmo cliente se inscrever por meio de duas plataformas, sou contado em dobro?
Não. Baremetrics corresponde aos registros de clientes em fontes conectadas por endereço de email, portanto alguém com uma assinatura de site faturada por meio do Stripe e uma segunda assinatura por meio da App Store é mesclado em um cliente pagando você duas vezes, em vez de dois clientes pagando uma vez cada. A contagem de clientes é o denominador de ARPU, LTVe taxa de churn, portanto contar uma pessoa duas vezes reduz ARPU e subestima o valor vitalício em toda sua base. Também significa que um cliente que cancela uma de duas assinaturas é lido como contração em vez de um evento de churn, que é o que realmente aconteceu. A exceção é um cliente que usou endereços de email diferentes em cada plataforma — sem identificador compartilhado, esses registros permanecem separados.
-
Conectar uma segunda plataforma de faturamento no meio do ano quebra minhas linhas de tendência histórica?
Não. Baremetrics extrai todo o histórico de transações de um processador de pagamentos quando você o conecta, não apenas atividades desde a data de conexão. Portanto, adicionar uma fonte em julho preenche o histórico completo dessa plataforma em vez de começar uma nova linha do zero, e seus gráficos de retenção de coorte e movimento de MRR ficam mais profundos em vez de serem redefinidos. Isso também é por que conectar uma plataforma em que você faturou por anos vale a pena fazer, mesmo que você esteja saindo dela.
-
Posso exportar dados de assinatura unificados para um data warehouse?
Não com Baremetrics. Não há push nativo para Snowflake, BigQuery, Redshift, S3 ou Azure, portanto equipes que precisam de dados de assinatura unificados ao lado de dados de produtos em um warehouse precisarão construir esse caminho pela API. ChartMogul oferece exportações de warehouse nativas em seus planos Pro e Enterprise, que é uma vantagem genuína para equipes maduras em dados com ferramentas BI existentes.
-
O que acontece com meu relatório de receita quando migro de uma plataforma de faturamento para outra?
Conecte ambas as plataformas e mantenha-as conectadas durante o período de sobreposição. Se você desconectar a fonte antiga no cutover, cada assinatura nela é lida como churn e sua taxa de churn dispara por um mês que não teve cancelamentos reais. Executar ambas as fontes através da transição mantém os históricos de assinatura intactos para que a migração não apareça como um evento de receita.
