Por que sua receita no analytics difere do Stripe

Primeiro veja se os números significam a mesma coisa

O painel de analytics mostra 840 USD e o Stripe apresenta outro total. Isso ainda não prova defeito em nenhum sistema. Um pode contar pagamentos de clientes concluídos; o outro pode exibir saldo, repasse, estimativa recorrente ou período diferente. A conciliação começa por uma definição, não pela edição do menor número.

Anote métrica, conta, modo real ou de teste, moeda, escopo do produto, fuso, limites de data e regra de reembolso em cada relatório. Registre a atualização de ambos. Enquanto esses campos não estiverem alinhados, duas capturas lado a lado comparam rótulos, não conciliam dados.

Separe quatro visões financeiras

Em um relatório de aquisição, uma definição inicial útil é recebimento bruto: valor de pagamentos concluídos em um escopo declarado. Recebimentos líquidos podem descontar reembolsos concluídos segundo uma regra explícita. Nenhuma das medidas representa automaticamente lucro ou receita reconhecida contabilmente.

Um relatório de saldo do Stripe inclui movimentos na moeda de liquidação. Um repasse representa dinheiro transferido segundo agrupamento e prazos próprios. MRR descreve o ritmo recorrente das assinaturas, não simplesmente o dinheiro recebido no mês. Use a visão que responde à pergunta em vez de forçar todas a coincidir.

O Stripe documenta Balance summary como relatório de conciliação de saldo e indica outro relatório para repasses automáticos. Isso importa quando o painel de marketing usa datas de pagamento em vez de datas de liquidação.

Uma conciliação fictícia que pode ser auditada

O exemplo fictício em USD usa uma visão por período de pagamento, atribuindo reembolsos concluídos à coorte do pagamento original. Exclui tarifas, ajustes tributários, disputas, conversão cambial e repasses; esses elementos precisam de campos próprios quando fazem parte da pergunta. A escolha é explícita para tornar o resultado reproduzível.

O pagamento A contribui com 100 USD, não 200, mesmo que sua notificação seja entregue duas vezes. B contribui com 40 USD após o reembolso parcial concluído. O reembolso solicitado para C continua pendente, então não é subtraído do total concluído. Exiba o valor pendente separadamente, sem escondê-lo.

COORTE FICTÍCIA DE PAGAMENTOS EM USD
Pagamento  Recebimento concluído  Reembolso concluído  Reembolso pendente
A          100,00                0,00                 0,00
B           60,00               20,00                 0,00
C           40,00                0,00                10,00

Recebimentos brutos = 100 + 60 + 40 = 200 USD
Reembolsos concluídos = 20 USD
Recebimentos líquidos nesta regra = 200 - 20 = 180 USD
Reembolsos pendentes, separados = 10 USD

Compare objetos canônicos, não quantidades de notificações

O Stripe pode entregar eventos webhook duplicados, sem garantia de ordem. Uma integração robusta verifica assinaturas, registra IDs processados e atualiza registros canônicos de pagamentos ou reembolsos, em vez de acrescentar receita a cada notificação. Eventos distintos também podem se referir ao mesmo objeto subjacente; deduplicar apenas eventos não constitui um modelo financeiro completo.

Para investigar, exporte o menor conjunto de divergências: conta do provedor, modo, ID do pagamento, moeda, valor e horários relevantes. Compare as linhas com o provedor. Um pagamento sem correspondência, um escopo errado ou um registro duplicado orienta melhor a ação do que uma diferença percentual em um gráfico.

Trate a página de agradecimento como um evento de interface, não como autoridade contábil. Ela pode ser atualizada, bloqueada ou nunca acessada. O estado do pagamento no servidor deve estabelecer se o dinheiro foi recebido.

Dê regras explícitas a reembolsos e datas

Uma solicitação de reembolso nem sempre é um reembolso concluído. O Stripe documenta estados pendentes e falhos, e um pagamento pode receber reembolsos parciais. Acompanhe IDs e estados atuais em vez de presumir que toda solicitação reduz imediatamente os recebimentos concluídos.

Escolha entre duas perguntas: “O que aconteceu hoje?” desconta reembolsos processados hoje dos pagamentos processados hoje. “Quanto essa coorte de aquisição preservou?” associa os reembolsos à coorte original. Ambas são úteis, mas geram totais diários diferentes, sobretudo ao reembolsar compras antigas.

Use um intervalo semiaberto: inclua o início e exclua o próximo limite para não contar um pagamento da meia-noite duas vezes em relatórios consecutivos. Separe horário do evento do provedor e horário de ingestão. Uma entrega atrasada segue a regra temporal declarada, não automaticamente o momento em que o processo a recebeu.

Preserve moedas e escopo do produto

Valores da API do Stripe usam unidades específicas por moeda, incluindo moedas sem casas decimais e casos especiais. Não divida universalmente os valores por 100. Mantenha a moeda junto a cada valor e formate conforme sua convenção.

Não some USD e EUR em um total sem rótulo. Para uma moeda única de relatório, declare fonte de câmbio, data e arredondamento, preservando os valores originais. Confira também se a conta conectada contém outros produtos. Receita de toda a conta não equivale automaticamente à receita do seu SaaS.

Termine com exceções explicadas, não uma igualdade forçada

Classifique as divergências restantes: entrega atrasada, reembolso não resolvido, teste excluído, produto errado, limite de fuso ou histórico importado incompleto. Atribua identificador e responsável a cada exceção. Repita a mesma comparação após os reparos e preserve a evidência original.

A conciliação termina quando os registros comparados concordam sob as mesmas definições e as exceções restantes estão explicadas. Um pagamento legítimo ainda pode não ter atribuição de marketing. Separe os problemas: um total financeiro confiável não exige inventar uma origem de visitante.

Referências

Exemplo para fins educativos. Os dados e cálculos de exemplo não representam resultados empresariais verificados.