Padrões de Reconhecimento de Receita: Guia Prático de Implementação ASC 606 e IFRS 15

Implemente os padrões de reconhecimento de receita ASC 606 e IFRS 15 com exemplos práticos para empresas de SaaS, serviços, manufatura e construção.

E
ECOSIRE Research and Development Team
|16 de março de 20269 min de leitura1.9k Palavras|

Parte da nossa série Compliance & Regulation

Leia o guia completo

Padrões de reconhecimento de receita: Guia prático de implementação ASC 606 e IFRS 15

Os erros de reconhecimento de receitas são a causa número um das reformulações financeiras, representando 37% de todas as reformulações exigidas pela SEC desde que a ASC 606 entrou em vigor. A abordagem baseada em princípios da norma dá flexibilidade às empresas, mas essa flexibilidade cria decisões que atrapalham até mesmo equipes de contabilidade experientes.

Este guia elimina a complexidade teórica para fornecer orientações práticas de implementação para ASC 606 (US GAAP) e IFRS 15 (normas internacionais). Ambos os padrões compartilham a mesma estrutura de cinco etapas, com pequenas diferenças na aplicação que abordamos ao longo do texto.


O modelo de reconhecimento de receita em cinco etapas

Etapa 1: Identifique o contrato

Um contrato existe quando todos os cinco critérios são atendidos:

  1. Aprovação e compromisso --- Ambas as partes aprovaram o contrato (escrito, oral ou implícito)
  2. Direitos identificados --- Os direitos de cada parte em relação aos bens/serviços são identificáveis
  3. Condições de pagamento identificadas --- As condições de pagamento de bens/serviços podem ser identificadas
  4. Substância comercial --- A transação tem substância comercial (o risco, o momento ou o valor dos fluxos de caixa mudarão)
  5. Cobrabilidade provável --- É provável que a entidade receba a contraprestação

Problemas comuns:

  • Acordos verbais com clientes antigos --- contratos ainda válidos se todos os critérios forem atendidos
  • Contratos com contraprestação variável --- incluir se os critérios forem atendidos no início
  • Contratos que exigem aprovação de crédito do cliente --- podem precisar ser adiados até que a aprovação seja obtida

Etapa 2: Identificar obrigações de desempenho

Uma obrigação de desempenho é uma promessa de transferir um bem ou serviço distinto.

Teste distinto (ambos devem ser cumpridos):

  1. Capaz de ser distinto --- O cliente pode se beneficiar do bem/serviço por conta própria ou com recursos prontamente disponíveis
  2. Distinto dentro do contrato --- A promessa é identificável separadamente de outras promessas (não altamente inter-relacionadas ou altamente dependentes)
Tipo de negócioObrigações de desempenho típicasConsiderações sobre agrupamento
SaaSAcesso, implementação, treinamento, suporte de softwareA implementação pode ou não ser distinta
FabricaçãoProduto, garantia, instalação, manutençãoA garantia estendida é distinta; garantia padrão não é
ConstruçãoProjetar, construir, comissionarFrequentemente combinada como obrigação única
Serviços profissionaisFases de consultoria, resultados, relatóriosCada fase pode ser distinta se for valiosa separadamente
VarejoProduto, pontos de fidelidade, embalagens para presentesOs pontos de fidelidade são uma obrigação separada

Etapa 3: Determine o preço da transação

O preço da transação é o valor da contraprestação que a entidade espera receber em troca da transferência de bens ou serviços.

Componentes a serem considerados:

  • Contraprestação fixa --- Preço do contrato, preço de tabela
  • Contraprestação variável --- Descontos, abatimentos, reembolsos, bônus de desempenho, penalidades
  • Contraprestação variável restritiva --- Inclui apenas valores altamente prováveis (IFRS 15) ou prováveis (ASC 606) de não reversão
  • Componente de financiamento significativo --- Ajustar se o prazo de pagamento diferir significativamente da entrega (>12 meses)
  • Contraprestação não monetária --- Mensuração pelo valor justo
  • Contraprestação a pagar ao cliente --- Reduzir o preço da transação, a menos que o pagamento seja para bens/serviços distintos

Métodos de estimativa de consideração variável:

  1. Valor esperado --- Soma ponderada pela probabilidade dos resultados possíveis (melhor para grandes populações)
  2. Valor mais provável --- Resultado único mais provável (melhor para resultados binários)

Etapa 4: Alocar o preço da transação

Quando um contrato tem múltiplas obrigações de desempenho, aloque o preço da transação com base nos preços de venda independentes relativos (SSP).

Hierarquia de determinação do SSP:

  1. Preço observável --- Preço cobrado quando vendido separadamente
  2. Avaliação de mercado ajustada --- Preço cobrado pelos concorrentes por bens/serviços semelhantes
  3. Custo esperado mais margem --- Custos esperados mais margem apropriada
  4. Abordagem residual --- Permitido somente quando o SSP é altamente variável ou incerto

Exemplo de alocação:

Uma empresa de software vende um pacote por US$ 120.000 contendo:

ComponentePES% relativaPreço Atribuído
Licença de software (3 anos)US$ 80.00053,3%US$ 64.000
Serviços de implementaçãoUS$ 40.00026,7%US$ 32.000
Apoio anual (3 anos)US$ 30.00020,0%US$ 24.000
TotalUS$ 150.000100%US$ 120.000

Etapa 5: Reconhecer a receita

Reconhecer a receita quando (ou à medida que) uma obrigação de desempenho é satisfeita através da transferência de controle.

Reconhecimento pontual (controle de transferências em um momento específico):

  • O cliente tem posse física
  • O cliente tem título legal
  • O cliente aceitou o ativo
  • O cliente tem riscos e recompensas significativos
  • A entidade tem direito presente ao pagamento

Reconhecimento ao longo do tempo (controle as transferências continuamente):

  • O cliente recebe e consome simultaneamente benefícios (serviços)
  • O desempenho da entidade cria ou melhora um ativo que o cliente controla (construção)
  • O desempenho da entidade cria um ativo sem uso alternativo E a entidade tem um direito executável ao pagamento pelo desempenho concluído até a data

Implementação específica do setor

SaaS e negócios de assinatura

O reconhecimento da receita de SaaS é reconhecido ao longo do tempo porque os clientes recebem e consomem simultaneamente os benefícios do serviço de software.

Principais considerações:

  • Taxas de instalação --- Geralmente não distintas; alocar à obrigação de acesso ao software e reconhecer durante o prazo do contrato
  • Serviços de implementação --- Distinto caso o cliente possa contratar terceiros; reconhecer como entregue. Não distinto se for altamente personalizado; combinar com acesso de software
  • Preços baseados em uso --- Reconhecer à medida que o uso ocorre (exceção de royalties com base em vendas para licenças IP)
  • Renovações de contrato --- Avalie se a opção de renovação é um direito material (se houver desconto significativo)

Padrão de entrada no diário (SaaS mensal):

Contract value: $12,000/year
Monthly recognition: $1,000

Dr. Accounts Receivable  $1,000
  Cr. SaaS Revenue        $1,000

Fabricação e vendas de produtos

A receita do produto é normalmente reconhecida em um momento em que o controle é transferido.

Os termos de envio são importantes:

IncotermControle de transferências emPonto de reconhecimento de receita
EXW (Ex-Works)Doca do vendedorQuando as mercadorias saem das instalações
Envio FOBRecolha de transportadoraQuando o transportador toma posse
Destino FOBDoca do compradorQuando o comprador recebe as mercadorias
CIFPorto de destinoQuando as mercadorias chegam ao porto

Acordos bill-and-hold --- Receita reconhecida antes da entrega somente quando:

  • O acordo tem uma razão comercial substantiva
  • Produto identificado separadamente como pertencente ao cliente
  • Produto atualmente pronto para transferência
  • A entidade não pode utilizar o produto ou direcioná-lo a outro cliente

Construção e Contratos de Longo Prazo

Os contratos de construção normalmente satisfazem as obrigações de desempenho ao longo do tempo usando métodos de entrada ou saída.

Método de entrada (custo sobre custo):

Revenue recognized = (Costs incurred to date / Total estimated costs) x Total contract price

Método de saída (marcos, unidades entregues):

Revenue recognized = (Output delivered to date / Total expected output) x Total contract price

Contratos de perda: Se os custos totais estimados excederem o preço do contrato, reconheça imediatamente toda a perda esperada.

Serviços Profissionais

Compromissos com taxa fixa:

  • Reconhecer ao longo do tempo usando horas incorridas / total de horas estimadas
  • Reavaliar o total de horas estimadas em cada data de relatório
  • Se a estimativa mudar, contabilizar como uma mudança na estimativa (atualização cumulativa)

Compromissos de tempo e materiais:

  • Reconhecer a receita à medida que as horas são faturadas (expediente prático disponível se o direito à fatura for igual ao valor entregue)

Principais diferenças: ASC 606 vs. IFRS 15

TópicoASC 606 (US GAAP)IFRS 15 (Internacional)
Restrição de consideração variável“Provável” sem reversão significativa“Altamente provável” de não haver reversão significativa
LicenciamentoDistingue direito de acesso versus direito de utilizaçãoMesma estrutura, resultados semelhantes
Divulgação provisóriaCondensado em períodos intermédiosMesmos requisitos do anual
Alívio de entidade não públicaOpções de divulgação reduzidasNenhuma medida equivalente
ColecionabilidadeReconheça quando provávelMesmo limite, mas "provável" significa >50% em IFRS vs. ~75% em GAAP
Custos do contratoCapitalizar comissões de vendas (ASC 340-40)Capitalizar custos incrementais (IFRS 15.91-98)

Configuração ERP para Reconhecimento de Receita

Configuração de reconhecimento de receita Odoo

  1. Ative o módulo de reconhecimento de receita nas configurações de contabilidade
  2. Configure regras de reconhecimento por categoria de produto:
  • Na entrega (ponto no tempo)
  • Durante o período do contrato (com base no tempo)
  • Com base em marcos (método de saída)
  • Com base na porcentagem de conclusão (método de entrada)
  1. Configure contas de receita diferida no plano de contas
  2. Crie cronogramas de reconhecimento para assinaturas e contratos de longo prazo
  3. Automatize lançamentos contábeis manuais para reconhecimento mensal/trimestral
  4. Configurar relatórios para mostrar receitas reconhecidas versus receitas diferidas por período

Checklist para reconhecimento de receitas de ERP

  • [] Produtos categorizados por método de reconhecimento (ponto no tempo vs. ao longo do tempo)
  • [] Preços de venda independentes documentados para produtos agrupados
  • [] Contas de receita diferida criadas para cada fluxo de receita
  • [] Cronogramas de reconhecimento testados com exemplos de contratos
  • [] Procedimentos de corte de final de período documentados
  • Relatórios de divulgação configurados (desagregação, saldos contratuais, obrigações restantes)
  • Integração com sistema de faturamento validado

Erros comuns de reconhecimento de receita

  1. Reconhecendo a receita antes das transferências de controle --- Destino FOB do envio, mas reconhecendo no embarque
  2. Ignorando contraprestação variável --- Não estimando abatimentos e descontos por volume no início
  3. Agregação inadequada --- Combinação de obrigações de desempenho que deveriam ser reconhecidas separadamente
  4. Direitos materiais ausentes --- Falha ao identificar descontos de renovação como obrigações separadas
  5. Determinação SSP inconsistente --- Uso de métodos diferentes para os mesmos produtos sem justificativa

Recursos relacionados


O reconhecimento de receitas de acordo com a ASC 606 e a IFRS 15 requer uma análise cuidadosa de cada tipo de contrato, mas o modelo de cinco etapas fornece uma estrutura consistente. Com a configuração adequada do ERP e políticas documentadas, sua organização pode obter um reconhecimento de receita preciso e compatível sem a confusão do final do mês. Entre em contato com a ECOSIRE para obter orientação especializada sobre a implementação do reconhecimento de receita.

E

Escrito por

ECOSIRE Research and Development Team

Construindo produtos digitais de nível empresarial na ECOSIRE. Compartilhando insights sobre integrações Odoo, automação de e-commerce e soluções de negócios com IA.

Mais de Compliance & Regulation

Lista de verificação de preparação para auditoria: como seu ERP torna as auditorias 60% mais rápidas

Lista de verificação completa de preparação de auditoria usando sistemas ERP. Reduza o tempo de auditoria em 60% com documentação, controles e coleta automatizada de evidências adequados.

Guia de implementação de consentimento de cookies: gerenciamento de consentimento em conformidade legal

Implemente o consentimento de cookies que esteja em conformidade com GDPR, ePrivacy, CCPA e regulamentações globais. Abrange banners de consentimento, categorização de cookies e integração CMP.

Regulamentações de transferência de dados transfronteiriças: navegando em fluxos de dados internacionais

Navegue pelas regulamentações de transferência de dados transfronteiriças com SCCs, decisões de adequação, BCRs e avaliações de impacto de transferência para conformidade com GDPR, Reino Unido e APAC.

Requisitos regulatórios de segurança cibernética por região: um mapa de conformidade para empresas globais

Navegue pelas regulamentações de segurança cibernética nos EUA, UE, Reino Unido, APAC e Oriente Médio. Abrange regras NIS2, DORA, SEC, requisitos de infraestrutura crítica e cronogramas de conformidade.

Governança e conformidade de dados: o guia completo para empresas de tecnologia

Guia completo de governança de dados que abrange estruturas de conformidade, classificação de dados, políticas de retenção, regulamentos de privacidade e roteiros de implementação para empresas de tecnologia.

Políticas de retenção de dados e automação: mantenha o que você precisa, exclua o que você precisa

Crie políticas de retenção de dados com requisitos legais, cronogramas de retenção, aplicação automatizada e verificação de conformidade para GDPR, SOX e HIPAA.

Converse no WhatsApp