ASC 606 para Desenvolvedores de Apps Indie: Você Deve Registrar a Receita da App Store como Bruta ou Líquida?

Ao abrir o App Store Connect ou o Google Play Console, você verá um número que parece ser sua receita. No mês passado, ele mostrava US$10.000. Sua conta bancária recebeu US$ 7.000. Nenhum dos números está errado — mas apenas um deles pertence à sua demonstração de resultados como "receita", e errar essa decisão pode distorcer silenciosamente sua margem bruta, deturpar sua taxa de crescimento e apresentar a um credor ou investidor uma imagem do seu negócio que não é verdadeira.

Esta é a questão do principal versus agente e, de acordo com o padrão de reconhecimento de receita ASC 606 dos GAAP dos EUA, não é uma burocracia opcional — é a regra que decide se você reporta US$10.000 em receita e US$ 3.000 em custo das vendas, ou apenas US$ 7.000 em receita sem mais nada a declarar. Para um desenvolvedor indie que vende através da App Store da Apple ou do Google Play Store, a resposta geralmente surpreende as pessoas.

A Pergunta Que Todo Desenvolvedor de App Acaba Fazendo​

O gatilho é quase sempre o mesmo: um fundador está montando um pitch deck, solicitando um empréstimo para pequenas empresas, ou apenas tentando responder "quanto eu realmente ganhei neste trimestre", e percebe que estava registrando tudo que caía na conta bancária como "vendas". Esse número é líquido da comissão da Apple ou do Google — ou seja, já tem o corte da plataforma subtraído.

O problema é que deduzir sua receita de uma taxa de plataforma não é uma escolha estilística. O ASC 606 tem um teste específico para exatamente esta situação, e ele depende de uma pergunta: quem controla a coisa que está sendo vendida antes de ela ser transferida para o cliente?

O Teste de Controle do ASC 606, em Linguagem Simples​

O modelo de receita de cinco etapas do ASC 606 exige que você identifique as obrigações de desempenho em um contrato e determine quem as está cumprindo. Quando um marketplace ou plataforma fica entre você e o cliente final — Apple, Google, Etsy, DoorDash, Uber — as normas contábeis chamam isso de avaliação de principal versus agente, e o guia de receita da PwC observa que as vendas na app store são um exemplo clássico de acordos que exigem esse olhar cuidadoso.

• Principal: você controla o bem ou serviço antes de ele ser transferido ao cliente. Você reconhece o valor total e bruto que o cliente pagou como receita, e a comissão da plataforma torna-se um custo das vendas (uma despesa), não uma redução da receita.
• Agente: a plataforma controla a oferta e você está apenas intermediando a venda em nome de outra parte. Você reconhece apenas o valor líquido que retém como sua taxa.

Três indicadores decidem qual deles você é, de acordo com as estruturas da Deloitte e PwC:

1. Responsabilidade pelo cumprimento — quem é o responsável se o aplicativo não funcionar, a assinatura não for entregue ou um cliente reclamar? Geralmente é você, o desenvolvedor, não a Apple.
2. Risco antes da transferência — quem arca com o risco de que o "estoque" (seu app, seu conteúdo, seu nível de assinatura) não venda ou não satisfaça o cliente? Novamente, tipicamente você.
3. Discricionariedade na definição de preço — quem define o que o cliente realmente paga? Você escolhe o nível de preço do seu aplicativo; a plataforma não negocia isso com você caso a caso.

Como a maioria dos desenvolvedores indie controla a experiência do produto, possui o relacionamento com o cliente para suporte e atualizações e define seus próprios preços, eles se enquadram no lado do principal do teste — o que significa que a contabilização correta é registrar o valor bruto que o cliente pagou como receita e tratar a parte da Apple ou do Google como uma linha de custo da receita, não como um desconto invisível.

Os Números Por Trás do Corte​

Saber que você é o principal só importa se você sabe o que está sendo realmente deduzido. As estruturas de taxas das plataformas mudaram significativamente nos últimos anos, e a maioria dos desenvolvedores ainda está orçando com base em suposições desatualizadas:

Além disso, há custos anuais fixos que a maioria das pessoas esquece de alocar em algum lugar: a taxa anual de US$99 do programa de desenvolvedores da Apple e a taxa única de registro de US$ 25 do Google. Pequenos, mas eles pertencem a algum lugar no seu plano de contas também — geralmente como uma despesa operacional geral, não como custo das vendas.

Registrando Corretamente: Um Exemplo Prático​

Digamos que um cliente compre uma assinatura in-app de US$9,99 através da Apple, e você esteja sob a taxa padrão de 30$ 9,99 do cliente, fica com US$3,00 e, eventualmente, deposita US$ 6,99 na sua conta bancária. Registrar US$ 6,99 como "receita" subestima sua linha superior em 30% — o que importa enormemente se você está comparando sua taxa de crescimento com um concorrente que vende diretamente, ou explicando suas margens a um credor.

Os lançamentos corretos reconhecem a venda total e, em seguida, registram a comissão separadamente como uma despesa:

2026-07-18 * "Apple" "Assinatura iOS — venda bruta"
  Ativos:AReceber:AppStore          9.99 USD
  Receita:VendasApp                  -9.99 USD
 
2026-07-18 * "Apple" "Comissão de 30% da App Store"
  Despesas:CustoReceita:TaxasPlataforma 3.00 USD
  Ativos:AReceber:AppStore             -3.00 USD
 
2026-07-20 * "Apple" "Pagamento recebido"
  Ativos:ContaCorrente                 6.99 USD
  Ativos:AReceber:AppStore             -6.99 USD

Observe que a conta a receber zera assim que o pagamento é compensado, mas sua demonstração de resultados ainda mostra US$9,99 em receita e US$ 3,00 em custo da receita — uma margem bruta de 70% naquela venda, não um misterioso desaparecimento de 30%. Este é exatamente o tipo de transação que os livros-razão em texto simples e controlados por versão lidam bem: a venda bruta, a taxa da plataforma e o pagamento são três eventos distintos e auditáveis, em vez de um único depósito bancário embaçado.

Por Que o Número do Painel Não é Suficiente​

Mesmo depois de saber a regra, aplicá-la manualmente é mais difícil do que parece. Os relatórios padrão do App Store Connect e do Play Console mostram totais agregados, não os detalhes no nível de assinante e transação que o ASC 606 tecnicamente exige — os rendimentos, reembolsos e conversão de moeda geralmente chegam em uma única soma global dias ou semanas após a venda real. Essa lacuna é exatamente por que um número crescente de empresas de aplicativos de assinatura usa APIs de plataforma ou ferramentas como o RevenueCat para reconstruir detalhes por transação, em vez de tentar fazer engenharia reversa a partir de um resumo mensal em PDF.

Pular esta etapa tem um custo real. Um exemplo amplamente citado: um desenvolvedor viu US$3.400 no painel do mês e, após comissões, impostos e outras deduções da plataforma, apenas US$ 1.294 estavam disponíveis para uso — uma diferença de mais de 60% entre a "receita" que eles pensavam ter e o que o negócio realmente reteve. Desenvolvedores que tomam decisões de contratação ou gastos com base no número do painel, em vez do valor reconciliado, estão orçando com base em um número que nunca foi real.

Erros Comuns Que Distorcem Seus Livros​

• Registrar apenas o depósito líquido como receita. Este é o erro mais comum e o assunto deste artigo — ele subestima tanto a receita quanto o custo das vendas, tornando sua imagem de margem bruta algo sem sentido.
• Ignorar reembolsos e estornos. A Apple e o Google processam reembolsos de clientes em seu nome, às vezes semanas após a venda original — se você não está reconciliando por transação, a receita reembolsada pode ficar em seus livros indefinidamente.
• Misturar a taxa de US$99 do desenvolvedor Apple ou a taxa de registro de US$ 25 do Google no custo das vendas. Estes são custos operacionais fixos, não comissões no nível da transação — eles pertencem a um balde de despesas completamente diferente.
• Esquecer a tabela de taxas separada da UE. Se qualquer parte de sua base de usuários estiver na UE e você optou pelos termos alternativos da Apple, essa receita tem uma estrutura de comissão diferente do resto do seu negócio e precisa de sua própria conta.

Mantenha Suas Finanças Organizadas Enquanto Você Escala​

Seja você um desenvolvedor solo com um único aplicativo na loja ou dirigindo um pequeno estúdio com alguns produtos de assinatura, a decisão entre bruto e líquido se acumula a cada mês que você erra — quando chega a hora de levantar uma rodada de investimento ou solicitar financiamento, uma linha de receita subestimada é algo difícil de explicar. O Beancount.io oferece aos desenvolvedores um livro-razão em texto simples e controlado por versão, construído exatamente para este tipo de transação de várias etapas — venda bruta, comissão da plataforma e pagamento como três entradas separadas e auditáveis, em vez de um único depósito bancário confuso. Comece gratuitamente e veja por que desenvolvedores que já pensam em código preferem uma contabilidade que funciona da mesma maneira.