Seus repasses de janeiro vieram do Lemon Squeezy e seus repasses de agosto vêm do Paddle, e agora seu contador está fazendo uma pergunta que nenhum dos dois painéis consegue responder sozinho: quanta receita de assinatura você realmente ganhou neste ano? O provedor antigo cobrava sob uma tabela de taxas, uma cadência de repasses e um conjunto de faturas fiscais emitidas por suas próprias entidades. O novo provedor faz o mesmo trabalho com relatórios diferentes, linhas de taxas diferentes e documentação diferente. Entre eles há um saldo de receita diferida, uma pilha de planos anuais vendidos em uma plataforma e atendidos em outra, e um fechamento de ano que precisa costurar dois livros-razão incompatíveis em um conjunto de livros verossímil. Essa costura — não a integração de API, que leva dias — é onde as migrações de merchant of record falham silenciosamente.
Esta é uma decisão ativa para milhares de vendedores agora. A Stripe adquiriu o Lemon Squeezy em julho de 2024, e a atualização de janeiro de 2026 do Lemon Squeezy dizia que seu futuro é um caminho de migração fácil para o Stripe Managed Payments, o produto de merchant of record da própria Stripe. Nenhum prazo foi publicado e o Lemon Squeezy ainda funciona, mas vendedores que não querem ser migrados no calendário de outra pessoa estão avaliando os independentes: Paddle e Polar, ambos verdadeiros merchants of record com a mesma taxa nominal de 5 por cento mais 50 centavos. Se você é um deles, a troca de cobrança é a parte fácil. Manter os livros verossímeis durante ela é o projeto de verdade.
O que um merchant of record realmente é nos seus livros
Um merchant of record é o vendedor legal do seu produto, não apenas seu processador de pagamentos. Quando um cliente compra pelo Paddle, Polar ou Lemon Squeezy, a fatura do cartão nomeia o provedor, a fatura fiscal é emitida por uma das entidades do próprio provedor, e os registros de imposto sobre vendas e IVA na Alemanha, no Japão ou no Texas pertencem ao provedor e não a você. O provedor calcula, coleta, declara e recolhe o imposto, absorve o risco de chargeback e envia a você um repasse pelo restante.
Essa estrutura legal decide como os registros contábeis ficam. A fatura do comprador documenta a venda do provedor ao seu cliente — é a fatura dele, não a sua. O seu lado da transação é documentado por registros do lado do vendedor: uma fatura reversa descrevendo seu fornecimento ao provedor e um aviso de remessa registrando cada valor de repasse. Sua receita é um repasse, líquido da taxa do provedor, chegando no calendário do provedor em vez de continuamente. A versão de cada provedor desses documentos parece diferente, e é exatamente por isso que rodar dois deles em um ano divide seus registros em dois.
A decisão bruto-versus-líquido que você precisa tomar uma única vez
Antes de tocar em qualquer plataforma, resolva a única política contábil que a migração obriga você a defender: você reconhece o valor total que o cliente pagou como receita (bruto) ou apenas o repasse que recebeu (líquido)?
Sob o ASC 606, esta é a questão de principal versus agente, e ela é respondida pelo controle — não por quem emitiu a fatura ou por quem está na fatura do cartão. A orientação está no ASC 606-10-55-36 a 55-40: uma entidade é principal se controla o bem ou serviço especificado antes de transferi-lo ao cliente, e reporta receita pelo bruto; se sua promessa é apenas providenciar que outra parte o forneça, a entidade é agente e reporta apenas sua taxa ou comissão pelo líquido. Para um fornecedor de software vendendo por meio de um merchant of record no estilo revendedor, a mesma análise decide quem é seu cliente. Se seu cliente é o usuário final, a receita é o preço ao usuário final e a parte do provedor é um custo de venda abaixo da linha de receita. Se seu cliente é o próprio provedor, a receita é o preço que o provedor pagou a você — o repasse.
O lucro bruto é idêntico de qualquer jeito. A receita reportada não é, e esse número alimenta sua taxa de crescimento, seus múltiplos de receita em uma captação ou aquisição, e toda comparação período a período que seu conselho lê. A maioria dos fornecedores de software que vende por marketplaces e revendedores chega ao tratamento bruto, mas qualquer das duas respostas é defensável se sua análise a sustentar. O que não é defensável é a deriva: registrar repasses do Lemon Squeezy pelo líquido no primeiro semestre e repasses do Paddle pelo bruto no segundo semestre porque os relatórios do novo provedor tornaram o bruto mais fácil. Escolha uma política, escreva a análise de controle em um memorando que seu auditor possa ler, e aplique-a identicamente aos repasses de ambos os provedores pelo ano inteiro.
As cinco costuras onde o ano se divide em dois
1. Assinaturas não migram; clientes reassinam. Não há migração automática de tokens entre processadores de pagamento. Cartões salvos geralmente não podem ser exportados de um merchant of record em formato utilizável, então planeje que os assinantes insiram os dados de pagamento novamente na nova plataforma — ou confirme por escrito, antes de se comprometer, que o novo provedor consegue mover assinaturas ativas e cartões salvos para você. Até cada cliente reassinar, a plataforma antiga continua cobrando deles, o que significa que os dois sistemas rodam lado a lado por meses e o fechamento de cada mês reconcilia dois fluxos de repasse.
2. Preços mantidos por direito adquirido e âncoras de renovação precisam ser reconstruídos à mão. Toda assinatura ativa carrega um preço, uma data de renovação e, muitas vezes, um plano antigo que não é mais vendido. A nova plataforma não sabe nada disso até você recriar: produtos, preços, planos legados mantidos apenas por clientes existentes, comportamento de testes, cupons, regras de imposto incluído e âncoras de renovação. Perca um preço antigo e um cliente leal é cobrado pela nova tarifa — um desastre de suporte que também registra receita que você depois precisa estornar.
3. Planos anuais criam um cutover de receita diferida. Um cliente que comprou um plano anual de US$ 1.200 em março pagou ao provedor antigo, mas você ganha essa receita mês a mês até o fevereiro seguinte. Na data do cutover, parte desse caixa ainda não foi ganha, e permanece em seu balanço como receita diferida independentemente de qual plataforma atende os meses restantes. Os relatórios da nova plataforma nunca mostrarão esse passivo — ela só sabe das vendas feitas por ela —, então a migração deve carregar o saldo adiante explicitamente, ou sua receita do segundo semestre fica superestimada por dinheiro que você já recebeu.
4. Estornos e chargebacks atravessam o cutover. Um estorno emitido em agosto por uma venda feita em maio fica no sistema do provedor antigo, sob as regras de taxa antigas, enquanto a receita que ele reverte pode já ter sido reconhecida ao longo de dois trimestres. Cada provedor absorve chargebacks como merchant of record, mas os lançamentos contábeis — revertendo receita, registrando qualquer taxa não reembolsável, ajustando o repasse que você já recebeu — caem nos seus livros, e os relatórios de ajuste de cada provedor os formatam de forma diferente.
5. O momento do repasse, a moeda e a documentação fiscal mudam todos de uma vez. Os calendários de repasse diferem por provedor, então as vendas da mesma semana podem cair nos extratos bancários de meses diferentes antes e depois da troca. Vendedores transfronteiriços enfrentam novas linhas de câmbio e novos detalhamentos de taxas. E cada provedor reporta suas próprias declarações fiscais sob seus próprios registros, enquanto vendedores nos EUA podem receber relatórios de repasse separados de cada plataforma para o ano. Nada disso são erros; são dois sistemas corretos discordando em formato, e seu fechamento tem que normalizar todos eles em um único plano de contas.
O manual de migração seguro para o financeiro
Siga estes passos na ordem, e não comprima a execução paralela.
1. Defina a data de cutover em um limite de período. Cutovers no meio do mês dividem períodos de assinatura, pro rata e lotes de repasse pela costura. Um cutover no fim do mês ou do trimestre dá a você populações limpas de antes e depois e um único fechamento que contém toda a transição.
2. Congele e exporte tudo da plataforma antiga. Bloqueie os períodos contábeis que o provedor antigo já cobrou. Exporte o catálogo completo de planos, toda assinatura ativa com seu preço e data de renovação, o histórico completo de faturas e todo relatório de repasse com detalhamentos de taxas. Mantenha a conta antiga somente leitura, não excluída, por pelo menos um ciclo de auditoria completo — auditores e autoridades fiscais perguntam especificamente sobre o ano da migração porque esperam a costura.
3. Recrie o catálogo de planos, incluindo planos que você não vende mais. Planos legados e mantidos por direito adquirido devem existir no novo sistema antes de o primeiro cliente migrado renovar nele. Documente cada mapeamento de um ID de plano antigo para um novo; essa tabela de mapeamento é a trilha de auditoria que explica por que as faturas de julho parecem diferentes das de junho para o mesmo cliente.
4. Coloque novos clientes na nova plataforma primeiro. Rode o novo provedor em paralelo para novas vendas enquanto as assinaturas existentes seguem até a renovação na antiga, depois mova coortes em limites naturais — datas de renovação, fins de mês, nunca no meio do ciclo. Cada coorte recebe sua própria reconciliação antes de a próxima começar. Um cutover de tudo de uma vez concentra toda falha de reassinatura, todo erro de manutenção de preço antigo e toda exceção de pro rata em um único fechamento.
5. Mapeie ambos os relatórios de repasse em um único plano de contas. Antes do primeiro fechamento que inclui os dois provedores, construa a tradução: cada linha de taxa, linha de imposto, ajuste e código de estorno em cada relatório mapeia para uma de suas contas do razão. Os dois provedores nunca usarão os mesmos rótulos. Sem o mapeamento, seu escriturário o inventa de forma diferente a cada mês.
6. Ajuste a receita diferida explicitamente. Reconcilie o saldo não ganho plano a plano na data do cutover, e lance qualquer diferença entre os registros da plataforma antiga e seu razão como um ajuste explícito com causa documentada — não um plug. A partir do cutover, reconheça o saldo restante conforme o cronograma, independentemente de qual plataforma atende o cliente.
Como o mês do cutover aparece em seu razão
A conexão contábil é direta depois que você separa os dois provedores com rastreamento de taxas distintos, em vez de deixar ambos lançarem direto na receita. Reconheça cada repasse pelo bruto — o pagamento completo do cliente como receita, a parte do provedor como despesa de venda — e continue reconhecendo os saldos diferidos anteriores ao cutover conforme o cronograma original. A documentação do Beancount cobre a sintaxe do razão usada abaixo, caso algo seja desconhecido.
Suponha que um cliente comprou um plano anual de US$ 1.200 pelo Lemon Squeezy em meados de março. O repasse de março chegou líquido da taxa de 5 por cento mais 50 centavos (US$ 60,50), e até 30 de junho você reconheceu quatro meses de receita (US$ 400), deixando US$ 800 não ganhos. 1º de julho é sua data de cutover, e uma nova assinatura mensal de US$ 49 é vendida pelo Paddle em julho. Em um razão em texto puro, fica assim:
2026-01-01 open Income:SaaS:Subscriptions
2026-01-01 open Liabilities:Deferred-Revenue
2026-01-01 open Expenses:MoR-Fees:LemonSqueezy
2026-01-01 open Expenses:MoR-Fees:Paddle
2026-01-01 open Assets:Checking
2026-03-15 * "Annual plan sale via Lemon Squeezy, buyer paid 1200.00"
Assets:Checking 1139.50 USD
Expenses:MoR-Fees:LemonSqueezy 60.50 USD
Liabilities:Deferred-Revenue -1200.00 USD
2026-06-30 * "Recognize June portion of annual plan"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USD
2026-07-15 * "Monthly plan sale via Paddle, buyer paid 49.00"
Assets:Checking 46.05 USD
Expenses:MoR-Fees:Paddle 2.95 USD
Income:SaaS:Subscriptions -49.00 USD
2026-07-31 * "Recognize July portion of pre-cutover annual plan"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USDTrês detalhes carregam a migração inteira. Primeiro, as taxas de cada provedor vão para sua própria subconta, de modo que os totais de fim de ano mostram exatamente quanto cada plataforma custou a você e as duas tabelas de taxas nunca se misturam. Segundo, o lançamento de reconhecimento de julho da venda de março não muda com o cutover — a receita diferida é seu passivo, ganha no seu cronograma, e não importa qual plataforma coletou o caixa. Terceiro, cada lançamento amarra-se a um relatório de repasse específico: o aviso de remessa do Lemon Squeezy de março para o primeiro, o repasse do Paddle de julho para o terceiro. Quando seu contador perguntar como a receita do ano foi ganha, cada número aponta para a documentação de exatamente um provedor.
Feche a costura deliberadamente
Uma migração de merchant of record são dois projetos com um nome só: mover a cobrança, que seus engenheiros terminam em semanas, e mover os livros, com os quais seu contador convive por um ano. O projeto de cobrança termina quando o último cliente reassina. O projeto dos livros termina quando todo repasse dos dois provedores amarra ao banco, toda linha de taxa mapeia para um único plano de contas, o saldo de receita diferida caminha limpo pela data de cutover, e o memorando de bruto-versus-líquido em seu arquivo de auditoria cobre as duas metades do ano sob uma única política. Agende o cutover em um limite de período, rode novas vendas na nova plataforma enquanto as assinaturas antigas seguem até a renovação, e mantenha o sistema antigo legível até os auditores terem visto o ano da migração. Faça isso, e a troca é uma nota de rodapé nas demonstrações do ano seguinte em vez da variação que ninguém consegue explicar.
