ASC 350-40 — o tópico de codificação que pesquisadores frequentemente digitam como 350/40 — é a regra do FASB para software de uso interno: quando o custo de desenvolvimento é despesado agora versus capitalizado como um ativo intangível e amortizado depois. Sob o modelo legado de três estágios (ainda aplicado pela maioria dos declarantes até a data obrigatória da ASU 2025-06), a resposta cabe em uma tabela:
| Estágio | O que acontece | Capitalizar ou despesar? |
|---|---|---|
| Projeto preliminar | Requisitos, demonstrações de fornecedores, viabilidade, decisão de construir vs. comprar | Despesa conforme incorrido |
| Desenvolvimento da aplicação | Codificação, configuração, testes, integração após o compromisso da gestão | Capitalize custos diretos de construção |
| Pós-implementação | Treinamento, manutenção, correções de bugs após o go-live | Despesa (nova funcionalidade pode reiniciar a capitalização) |
ASU 2025-06 (emitida em 18 de setembro de 2025; obrigatória para períodos anuais com início após 15 de dezembro de 2027) aposenta esses rótulos de estágio em favor de um limite de provável conclusão e sinaliza que mais custos serão despesados. As seções abaixo cobrem o que o ASC 350-40 inclui, o detalhe dos estágios, a atualização de 2025, a lista de verificação de capitalizar/despesar, e como a escolha impacta o EBITDA e o balanço patrimonial.
O que o ASC 350-40 Abrange
O ASC 350-40 é o padrão do FASB para software de uso interno — software que sua empresa constrói ou compra para suas próprias operações, em vez de vender a clientes como produto principal. Exemplos incluem:
- Sistemas internos de CRM, ERP, RH ou contabilidade
- Ferramentas de infraestrutura em nuvem e plataformas de DevOps
- Uma plataforma SaaS que você opera para clientes (o cliente a acessa como serviço, não como software licenciado que instala)
- Pipelines de dados internos, dashboards e ferramentas de análise
- Automação personalizada de fluxos de trabalho ou back-office
Se você vende software licenciado que os clientes instalam em suas próprias máquinas, isso se enquadra no ASC 985-20 (software para venda externa), que tem regras diferentes. A maioria das empresas SaaS modernas se enquadra no ASC 350-40 porque os clientes consomem o software como um serviço hospedado.
A questão central que o padrão responde: quando você gasta dinheiro construindo software, esse custo deve ser despesado imediatamente ou capitalizado como ativo intangível e amortizado em períodos futuros?
O Antigo Modelo de Três Estágios (Pré-ASU 2025-06)
Por décadas, o ASC 350-40 usou uma estrutura baseada em estágios. Sob a orientação legada ainda em vigor para a maioria dos declarantes até 2027, o desenvolvimento de software se divide em três fases distintas.
Estágio 1: Estágio do Projeto Preliminar
Esta é a fase exploratória — definir requisitos, avaliar tecnologias, obter demonstrações de fornecedores e decidir se deve construir, comprar ou passar. Todos os custos neste estágio são despesados conforme incorridos, semelhante a despesas de pesquisa. A justificativa: até que a gestão se comprometa, você ainda não tem um ativo provável.
Atividades aqui incluem:
- Formulação conceitual e alternativas de design
- Demonstrações de fornecedores e avaliações de tecnologia
- Análises de custo-benefício e estudos de viabilidade
- Seleção final de uma abordagem ou fornecedor
Estágio 2: Estágio de Desenvolvimento da Aplicação
A capitalização começa quando a gestão autoriza o projeto, compromete financiamento e a conclusão é provável. Este estágio cobre a construção real — codificação, testes, configuração, integração e instalação.
Custos capitalizáveis neste estágio tipicamente incluem:
- Salários e benefícios de desenvolvedores, engenheiros de QA e gerentes de projeto (apenas o tempo diretamente atribuível à codificação, testes e configuração do software)
- Honorários de consultoria externa para trabalho de desenvolvimento
- Licenças de software e ferramentas usadas para construir a aplicação
- Custos diretos de materiais e serviços consumidos no desenvolvimento
- Custos de juros (em casos limitados)
A capitalização cessa quando o software está substancialmente completo e pronto para seu uso pretendido — geralmente quando os testes terminam e o sistema é implantado em produção, mesmo que a implementação seja gradual.
Estágio 3: Estágio de Pós-Implementação
Após o go-live, os custos contínuos voltam ao tratamento de despesa. Treinamento, manutenção, correções de bugs e suporte rotineiro são todos despesados. A exceção: melhorias que adicionam nova funcionalidade (não apenas corrigem ou mantêm funcionalidade existente) podem ser capitalizadas usando os mesmos critérios do Estágio 2.
A Grande Atualização de 2025: ASU 2025-06
Em 18 de setembro de 2025, o FASB emitiu a ASU 2025-06, que moderniza significativamente o ASC 350-40. A atualização é obrigatória para períodos anuais com início após 15 de dezembro de 2027, com adoção antecipada permitida.
A mudança é estrutural: o modelo de três estágios desapareceu. O FASB removeu explicitamente todas as referências a estágios de projeto porque a estrutura legada não se adequava às práticas modernas de desenvolvimento ágil e iterativo, onde os requisitos evoluem e os "estágios" se sobrepõem ou ocorrem em paralelo.
O Novo Limite Baseado em Princípios
Sob o padrão revisado, você capitaliza custos de software somente quando ambas estas condições forem atendidas:
- Autorização da gestão: A gestão autorizou e comprometeu financiamento para o projeto.
- Limite de provável conclusão: É provável que o projeto será concluído e o software desempenhará sua função pretendida.
Esse segundo teste está fazendo trabalho real. O FASB introduziu um conceito chamado incerteza significativa de desenvolvimento para avaliar se a conclusão é provável. Você deve avaliar:
- Se o software inclui recursos novos ou não comprovados que não foram validados por codificação ou testes
- Se os requisitos de desempenho ainda estão indeterminados ou sujeitos a revisão substancial
Se existir incerteza significativa, a capitalização deve ser adiada até que a incerteza seja resolvida. O FASB sinalizou que espera que a nova regra resulte em mais custos de software sendo despesados, particularmente em empresas SaaS onde os requisitos iteram continuamente.
O Que Isso Significa na Prática
Para uma startup construindo algo genuinamente novo — uma plataforma de agentes de IA, um motor de automação inovador — a nova regra pode empurrar mais gastos para despesas operacionais mais cedo. Para empresas maduras aprimorando sistemas bem definidos, o impacto prático será menor. De qualquer forma, a mudança de uma verificação mecânica de estágios para um limite baseado em julgamento significa que as empresas precisam de documentação mais clara das decisões de gestão, viabilidade técnica e status do projeto.
O Que Você Pode e Não Pode Capitalizar: Uma Lista de Verificação Prática
Seja aplicando o modelo de estágios legado ou o novo teste baseado em princípios, a linha entre gastos capitalizáveis e despesáveis é semelhante em espírito. Aqui está uma lista de verificação prática.
Geralmente Capitalizável
- Custos diretos de mão de obra para desenvolvedores, designers e QA durante a fase de construção
- Impostos sobre folha de pagamento e benefícios alocados para esses funcionários
- Honorários de consultoria externa e contratados para trabalho de desenvolvimento
- Software, ferramentas e custos de infraestrutura em nuvem diretamente consumidos no desenvolvimento
- Custos para desenvolver nova funcionalidade pós-lançamento (melhorias que expandem materialmente as capacidades)
- Custos para desenvolver software de conversão (o software que migra dados antigos para novos), em oposição à atividade de conversão de dados em si
Geralmente Despesado
- Pesquisa preliminar, seleção de fornecedores e análise de viabilidade
- Treinamento de funcionários no novo sistema
- Limpeza de dados, reconciliação e migração de registros
- Manutenção rotineira, correções de bugs e refatoração menor
- Custos de software incorridos durante períodos de incerteza significativa de desenvolvimento
- Despesas gerais administrativas não diretamente ligadas ao desenvolvimento
- Marketing, suporte e atividades de sucesso do cliente pós-lançamento
O Problema do Controle de Tempo
O maior desafio prático é alocar o tempo de engenharia. Um engenheiro sênior gastando 40 horas por semana provavelmente não está fazendo 100% de trabalho capitalizável — ele também está depurando produção, orientando colegas, participando de reuniões diárias e revisando pull requests de sistemas legados. Sem um método defensável de controle de tempo (tíquetes de engenharia etiquetados por projeto, software de controle de tempo ou pesquisas formais de alocação), as estimativas de capitalização falharão no escrutínio de auditoria.
O Impacto nas Demonstrações Financeiras
Capitalizar versus despesar o mesmo dólar produz demonstrações financeiras dramaticamente diferentes.
Efeito na Demonstração de Resultados
Um custo capitalizado não afeta a demonstração de resultados no período em que foi gasto. Em vez disso, é amortizado — tipicamente em linha reta ao longo de três a cinco anos para software de uso interno. Assim, $1M de gasto de engenharia capitalizado no Ano 1 pode criar apenas $200K a $333K de despesa de amortização a cada ano, deixando o lucro operacional do Ano 1 materialmente maior.
É por isso que o EBITDA ganha um impulso com a capitalização. A amortização é, por definição, excluída do EBITDA — então capitalizar mais custo de desenvolvimento transfere dólares de despesa operacional (que reduz o EBITDA) para amortização (que não reduz). Investidores que examinam métricas de SaaS frequentemente olham para "EBITDA antes de P&D capitalizado" ou cálculos de regra dos 40 usando P&D em caixa para enxergar através dessa dinâmica.
Efeito no Balanço Patrimonial
Software capitalizado aparece como um ativo intangível de longo prazo, frequentemente rotulado como "Custos de Desenvolvimento de Software Capitalizados" ou similar. Isso:
- Aumenta o total de ativos e patrimônio líquido
- Melhora o retorno sobre ativos (ROA) apenas se os lucros crescerem mais rápido que a base de ativos
- Cria um ativo que deve ser testado para impairment se o projeto for abandonado ou seu valor diminuir
Se um projeto for abandonado no meio do desenvolvimento, os custos previamente capitalizados devem ser baixados — o que produz uma perda súbita, frequentemente material. Esta é uma razão pela qual a nova ASU 2025-06 enfatiza tão fortemente o limite de provável conclusão.
Efeito na Demonstração de Fluxo de Caixa
Custos de desenvolvimento capitalizados são tipicamente classificados como atividades de investimento (não operacionais), o que faz o fluxo de caixa operacional parecer mais forte. Investidores sofisticados ajustam isso ao comparar empresas — mas o número principal ainda se beneficia.
Erros Comuns que Colocam Empresas em Problemas
Auditores e adquirentes veem os mesmos erros repetidamente.
Capitalizar Custos Pré-Autorização
O erro clássico é capitalizar tempo de engenharia gasto antes de a gestão aprovar formalmente o projeto. Sem uma autorização documentada e compromisso de financiamento, esses custos deveriam ter sido despesados. Certifique-se de ter atas de reuniões, aprovações do conselho ou assinaturas por escrito que estabeleçam quando a gestão se comprometeu.
Sem Documentação no Nível do Projeto
Se um regulador ou auditor perguntar "mostre-me os projetos que você capitalizou", e você só puder apontar para gastos gerais de engenharia, você perderá. Você precisa de registros projeto por projeto: escopo, data de autorização, orçamento, status e tempo cobrado.
Tratar Todo o Tempo de Engenharia como Capitalizável
Engenheiros seniores corrigem bugs, revisam código, participam de reuniões e respondem a incidentes. Nada disso é capitalizável. Empresas que simplesmente multiplicam a folha de pagamento da equipe de engenharia por uma porcentagem raramente sobrevivem à auditoria.
Continuar a Capitalizar Após o Lançamento
No momento em que o software está pronto para seu uso pretendido, a capitalização cessa. Correções de bugs, ajuste de desempenho e melhorias menores após esse ponto são despesas operacionais. Novos recursos com escopo separado podem iniciar um novo período de capitalização — mas trabalho rotineiro pós-lançamento não pode.
Esquecer o Teste de Impairment
Software capitalizado é um ativo, e ativos devem ser reduzidos se seu valor cair. Se você descontinuar um produto, encerrar um recurso ou reescrever fundamentalmente o sistema, você deve reavaliar e provavelmente baixar o saldo anterior.
Como Configurar um Processo Defensável
Se você decidir que a capitalização é certa para sua empresa, o processo importa tanto quanto a política.
-
Escreva uma política de capitalização de software. Defina quais projetos se qualificam, seu processo de autorização, sua estimativa de vida útil e como você alocará tempo. Obtenha aprovação do seu CFO ou comitê de auditoria.
-
Controle o tempo de engenharia no nível do projeto. Esta é a entrada fundamental. Seja usando etiquetas Jira, tags personalizadas em um rastreador de projetos ou folhas de ponto formais, você precisa defender "o engenheiro X gastou Y% do seu tempo em trabalho capitalizável no projeto Z."
-
Documente a aprovação da gestão. Cada projeto capitalizável precisa de evidência de autorização — aprovação escrita datada, atas do conselho ou um estatuto de projeto assinado pela liderança.
-
Reavalie a incerteza significativa regularmente. Sob a nova regra, você precisa monitorar se os recursos ainda são novos ou não comprovados e se os requisitos estão se estabilizando. Revisões trimestrais com a liderança de engenharia são razoáveis.
-
Construa cronogramas de amortização por projeto. Cada projeto capitalizado começa a amortizar quando pronto para uso, e você precisa rastrear a base de custo desse ativo, amortização acumulada e vida restante.
-
Teste para impairment quando os projetos mudarem. Sempre que você abandonar, reescrever materialmente ou encerrar trabalho capitalizado, execute uma análise de impairment e registre as baixas conforme necessário.
Por Que Isso Importa para a Contabilidade
A capitalização de software é uma daquelas áreas onde a disciplina contábil desde o primeiro dia compensa anos depois. Investidores durante uma rodada Série B puxarão seu balancete; adquirentes em um processo de venda rastrearão transações até lançamentos contábeis; o IRS pode comparar seu tratamento GAAP ao seu tratamento fiscal de P&D da Seção 174, que tem suas próprias regras. Se seus livros não separam projetos capitalizados de despesas operacionais, não conseguem vincular cobranças de tempo de engenharia a projetos específicos ou não mantêm cronogramas de amortização limpos, cada ciclo de auditoria e due diligence se torna doloroso.
A solução é simples em conceito: manter estrutura de contas limpa, controlar o tempo no nível do projeto e documentar as decisões por trás de cada lançamento de capitalização. Fazer isso desde o início evita limpezas caras depois.
Mantenha Sua Contabilidade de Software Pronta para Auditoria
Seja capitalizando sua primeira plataforma interna ou executando cronogramas de amortização em dezenas de projetos, registros financeiros limpos são a fundação. Beancount.io fornece contabilidade em texto puro que lhe dá livros transparentes e com controle de versão — cada lançamento rastreável, cada conta auditável, cada relatório reproduzível. Para empresas de software rastreando desenvolvimento capitalizado em vários projetos, ter livros que leem como código é uma vantagem séria. Comece gratuitamente e veja por que desenvolvedores e profissionais de finanças estão migrando para a contabilidade em texto puro.
