Seus relatórios de reembolso nunca batem entre Apple, Google e seu servidor, veja como reconciliá-los

Puxe a contagem de reembolsos do App Store Connect, depois puxe-a do seu servidor, e os dois números não vão bater. Puxe um terceiro do seu financial report e ele também não vai bater com nenhum dos dois. Isso não é um bug no sistema de ninguém. A Apple e o Google informam os reembolsos por mais de uma superfície cada um, cada superfície conta um momento diferente na vida do reembolso, e seu servidor vê um quarto. Se você já tentou reconciliar relatórios de reembolso e desistiu porque os totais se distanciam, veja por que eles se distanciam, em qual número confiar para cada tarefa, e como alinhá-los por transação em vez de por mês.

Por que um mesmo reembolso aparece como três números diferentes

Um único reembolso passa por vários sistemas antes de ser liquidado, e cada sistema o anota em um instante diferente. Seu servidor fica sabendo primeiro, como um evento. Um relatório de análise rápida o estima em seguida. O relatório de contabilidade o registra por último, depois que o dinheiro realmente se moveu. O mesmo reembolso, três carimbos de tempo, três totais. O erro é tratar dois quaisquer deles como se devessem ser iguais no mesmo dia.

A Apple te dá duas famílias de relatórios, mais o seu webhook

A Apple informa os reembolsos em dois lugares que não são a mesma ferramenta e não foram feitos para bater em um dia específico. O Sales and Trends é a visão rápida e estimada: os relatórios diários chegam no dia seguinte, os semanais nas segundas-feiras, e os mensais cerca de cinco dias depois do fim do mês, geralmente antes das 8 a.m., horário do Pacific. Ele estima as vendas e os proventos em USD usando uma média móvel das taxas de câmbio do mês anterior, o que o torna bom para identificar uma tendência e errado para bater um pagamento. O Payments and Financial Reports é a visão liquidada: gerado uma vez por mês de acordo com o calendário fiscal da Apple, disponível na primeira sexta-feira do mês fiscal atual para o mês fiscal anterior, e gerado apenas se houve compras ou reembolsos nesse período. Ele usa a taxa de câmbio finalizada aplicada ao seu pagamento. Esse relatório é o registro contábil. Junto dos dois, seu servidor recebe a App Store Server Notification REFUND no momento em que a Apple concede um reembolso, vinculada a um único id de transação.

O Google se divide da mesma forma

O Google Play espelha a divisão. O earnings report é o registro contábil, gerado mensalmente e normalmente disponível até o dia 5 do mês seguinte, e lista os reembolsos como seus próprios tipos de transação: Charge refund para o dinheiro devolvido ao comprador e Google fee refund para a taxa de serviço que o Google devolve, cada um marcado como Full ou Partial. O estimated sales report é a visão de análise de baixa latência que mostra o que os compradores pagaram antes de impostos e taxas, e o Google diz claramente que ele serve para análise e não é recomendado para contabilidade. No lado do servidor você recebe a Real-time Developer Notification em tempo real e pode ler um reembolso pela Voided Purchases API.

Como a Apple mostra um reembolso dentro do relatório, e a armadilha da linha negativa

Abra o Summary Sales Report e um reembolso não se subtrai em silêncio de uma venda. Ele aparece como sua própria linha. As Units e o Customer Price dessa linha são negativos, que é como você identifica um reembolso, e o valor de Developer Proceeds não se comporta como o preço se comporta. O relatório não está intrinsecamente líquido de reembolsos. Ele lista as linhas de reembolso ao lado das linhas de venda, e é sua tarefa agrupá-las. Some a coluna de Units a olho e você vai contar em dobro ou perder os reembolsos por completo, porque uma linha de reembolso de menos um está na mesma coluna que suas vendas positivas.

A regra prática é simples: encontre os reembolsos pelas Units negativas, some essas linhas separadamente, e nunca presuma que o relatório já as descontou para você. Uma contagem dos seus reembolsos para um featured snippet é o número de linhas com Units negativas, não a soma aritmética de uma coluna.

O calendário fiscal é a razão pela qual seus totais mensais nunca batem

Aqui está a maior razão pela qual uma planilha cuidadosa ainda se recusa a fechar. Os relatórios financeiros da Apple não seguem meses de calendário. Eles seguem um calendário fiscal 4-4-5, onde a maioria dos meses fiscais tem quatro semanas e cada terceiro tem cinco semanas. Um desenvolvedor que compara um Financial Report com uma janela comum de janeiro a janeiro está comparando dois intervalos de dias diferentes, então os totais de reembolsos não podem coincidir mesmo que cada número subjacente esteja correto. Desenvolvedores nos próprios fóruns da Apple viram os números de Sales e os do Financial Report divergirem em milhares de dólares por exatamente essa razão, com a diferença aumentando a cada mês que deixavam acumular.

O earnings report do Google é mensal, mas carrega sua própria temporização e seu próprio fuso horário, e nenhum é o relógio UTC do seu servidor. A armadilha mais profunda é compartilhada pelas duas lojas: um reembolso é atribuído à data em que é liquidado, não à data da venda original. Reembolse uma compra de março no início de abril e ela reduz seus números de abril, não os de março. Alinhe dois meses pelos seus rótulos e o reembolso parecerá ter sumido de um e surgido no outro.

Quanto custa um reembolso, e em qual relatório lê-lo

A reconciliação é na verdade uma questão de contabilidade, então siga o dinheiro. Em um reembolso a loja devolve a própria comissão, o que significa que o valor que de fato sai da sua conta é a sua parte da venda, não o preço cheio que o cliente vê devolvido. No Google Play essa devolução é uma linha visível: o tipo de transação Google fee refund no seu earnings report é a taxa de serviço voltando para você, ao lado do Charge refund que foi para o comprador. Na App Store, a Apple deduz os seus proventos após a comissão e devolve a comissão dela no mesmo movimento, então o financial report mostra a dedução líquida da parte da Apple.

A temporização do fluxo de caixa é onde os desenvolvedores se surpreendem. No Google Play, se você reembolsar um pedido antes de o Google ter pago por ele, você simplesmente nunca recebe aquele valor. Se você reembolsar depois do pagamento, o Google o deduz de um pagamento futuro. E se uma onda de reembolsos empurra seu saldo para o negativo e ele fica negativo por pelo menos 48 horas, o Google vai debitar a conta bancária que normalmente recebe seus pagamentos pelo valor faltante. Um chargeback é a versão mais dura do mesmo evento: no Google Play, para pedidos feitos em ou após August 3, 2026, o chargeback transfere o preço de compra mais as taxas do banco para o desenvolvedor, e cai no relatório de um mês posterior ao da venda.

Como reconciliar seus relatórios de reembolso, passo a passo

A tarefa fica simples quando você para de tentar fazer cada número ser igual e, em vez disso, atribui cada número à pergunta que ele responde. Há apenas duas perguntas: quanto dinheiro se moveu, e quem ainda tem acesso.

• Decida a pergunta antes de abrir um relatório. Para o dinheiro, a resposta está no financial report da Apple e no earnings report do Google, ponto final. Para o acesso, a resposta está nas notificações do seu servidor. Nunca reconcilie um contra o outro.
• Escolha o id de transação como sua chave de junção nas quatro superfícies. É o único campo que uma venda, seu reembolso, os relatórios e seu webhook todos compartilham.
• Para a Apple, quando o Summary Sales Report e seu webhook discordam, chame o endpoint Get Refund History do App Store Server API em /inApps/v2/refund/lookup/{transactionId}. Ele retorna as transações reembolsadas assinadas de um cliente, com revocationDate e revocationReason, um id de transação por vez, e pagina pelo histórico dele. Esse endpoint é o critério de desempate.
• Para o Google, confira as linhas Charge refund do earnings report contra o que a Voided Purchases API reporta para os mesmos pedidos, e lembre-se de que um reembolso parcial é marcado como Partial e não vai zerar a cobrança original.
• Ajuste-se ao relógio do relatório, não ao seu. O da Apple é um mês fiscal no horário do Pacific. O earnings report do Google tem seu próprio mês e fuso horário. Seus logs são quase com certeza UTC. Converta para o calendário do relatório antes de comparar, ou os limites de dia sozinhos vão criar divergências fantasma.
• Espere que a estimativa se mova. O Sales and Trends é uma estimativa e vai continuar mudando à medida que as transações são liquidadas. Reconcilie contra o financial report, nunca contra a estimativa, e nunca contra o instantâneo de ontem da estimativa.

Quando seu servidor mostra mais reembolsos do que o relatório

O pânico mais comum é encontrar mais notificações REFUND no seu servidor do que linhas de reembolso no sales report para a mesma janela. Normalmente não é dinheiro perdido. As duas superfícies contam momentos diferentes, uma notificação pode preceder a linha do relatório em dias, e um reembolso parcial ou uma solicitação reenviada pode produzir mais de um evento. Os desenvolvedores relataram exatamente esse formato, milhares de notificações REFUND contra uma contagem menor de linhas com Units negativas para o mesmo mês. Resolva sempre da mesma forma: pegue os ids de transação que seu servidor viu, passe-os pelo Get Refund History, e deixe o próprio registro da Apple determinar quais realmente foram reembolsados e por quanto.

A versão curta

Você não consegue fazer a estimativa da Apple, o financial report da Apple, o earnings report do Google e seu webhook mostrarem todos o mesmo total de reembolsos no mesmo dia, e você deveria parar de tentar. Leia cada um pelo que ele foi feito para te dizer. Confie no financial report e no earnings report para o dinheiro, confie nas notificações do seu servidor para o acesso, e quando duas superfícies brigarem, junte-as pelo id de transação e deixe a consulta do Get Refund History ou do Voided Purchases desempatar. Reembolsos reconciliados não são totais que combinam. São transações que combinam.