Capitalização de Software sob a ASC 350-40: Um Guia Prático para a Decisão entre Capitalizar ou Lançar como Despesa

Uma pesquisa da Gartner de 2024 revelou que 63% dos fundadores de SaaS em estágio inicial classificam incorretamente os custos de desenvolvimento de software. Esse erro custa caro em duas frentes: os investidores desvalorizam as finanças quando as classificações parecem desleixadas, e os auditores sinalizam o problema durante a diligência, o que pode atrasar rodadas de financiamento ou processos de venda por meses.

A capitalização de software não é apenas uma tecnicalidade contábil. Ela afeta diretamente o EBITDA, o balanço patrimonial e a forma como o seu negócio é visto por credores, investidores e compradores. As regras sob o ASC 350-40 — e uma atualização importante de 2025 — determinam quais custos atingem a demonstração de resultados imediatamente e quais são distribuídos ao longo dos anos.

Este guia percorre o que a norma exige, a recente reformulação da ASU 2025-06, os custos que você pode capitalizar, os que não pode e as consequências para as demonstrações financeiras de fazer tudo corretamente.

O que o ASC 350-40 Abrange

O ASC 350-40 é a norma 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 para 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 um serviço, não como um software licenciado que ele instala)
• Pipelines de dados internos, dashboards e ferramentas de análise
• Automação de fluxo de trabalho personalizado ou de back-office

Se você estiver vendendo software licenciado que os clientes instalam em suas próprias máquinas, isso se enquadra no ASC 985-20 (software para venda externa), que possui 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 a norma responde: quando você gasta dinheiro construindo software, esse custo deve ser lançado como despesa imediatamente ou capitalizado como um 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 utilizou uma estrutura baseada em estágios. Sob a orientação herdada 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 Preliminar do Projeto

Esta é a fase exploratória — definição de requisitos, avaliação de tecnologias, demonstrações de fornecedores e decisão sobre construir, comprar ou desistir. Todos os custos nesta fase são lançados como despesa conforme incorridos, de forma semelhante às despesas de pesquisa. O raciocínio: até que a gerência se comprometa, você ainda não tem um ativo provável.

As 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 gerência autoriza o projeto, compromete o financiamento e a conclusão é provável. Este estágio abrange a construção real — codificação, teste, configuração, integração e instalação.

Os custos capitalizáveis neste estágio normalmente incluem:

• Salários e benefícios para desenvolvedores, engenheiros de QA e gerentes de projeto (apenas o tempo diretamente atribuível à codificação, teste e configuração do software)
• Taxas 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 para quando o software está substancialmente concluído e pronto para o 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 a entrada em operação, os custos contínuos voltam para o tratamento de despesa. Treinamento, manutenção, correções de bugs e suporte rotineiro são todos lançados como despesa. A exceção: melhorias que adicionam novas funcionalidades (não apenas corrigem ou mantêm funcionalidades existentes) 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 iniciados 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 aos estágios do projeto porque a estrutura herdada não se ajustava à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 a norma revisada, você capitaliza custos de software apenas quando ambas as seguintes condições são atendidas:

1. Autorização da gerência: A gerência autorizou e se comprometeu a financiar o projeto.
2. Limite de probabilidade de conclusão: É provável que o projeto seja concluído e o software desempenhe sua função pretendida.

Este segundo teste é fundamental. 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 meio de codificação ou teste
• Se os requisitos de desempenho ainda estão indeterminados ou sujeitos a revisão substancial

Se houver incerteza significativa, a capitalização deve ser diferida até que a incerteza seja resolvida. O FASB sinalizou que espera que a nova regra resulte em mais custos de software sendo lançados como despesa, particularmente em empresas SaaS onde os requisitos iteram continuamente.

O Que Isso Significa na Prática

Para uma startup que está construindo algo genuinamente novo — uma plataforma de agentes de IA, um motor de automação inovador — a nova regra pode empurrar mais gastos para as despesas operacionais mais cedo. Para empresas maduras que aprimoram sistemas bem definidos, o impacto prático será menor. De qualquer forma, a mudança de uma verificação de estágio mecânica para um limite baseado em julgamento significa que as empresas precisam de uma 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: Um Checklist Prático

Quer você esteja aplicando o modelo de estágios legado ou o novo teste baseado em princípios, a linha entre gastos capitalizáveis e passíveis de despesa é semelhante em essência. Aqui está um checklist de trabalho.

Geralmente Capitalizável

• Custos diretos de mão de obra para desenvolvedores, designers e QA durante a fase de construção
• Encargos sociais e benefícios alocados para esses funcionários
• Honorários de consultoria externa e contratados para trabalho de desenvolvimento
• Custos de software, ferramentas e infraestrutura em nuvem consumidos diretamente no desenvolvimento
• Custos para desenvolver novas funcionalidades 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 Lançado como Despesa

• Pesquisa preliminar, seleção de fornecedores e análise de viabilidade
• Treinamento de funcionários no novo sistema
• Limpeza, conciliação e migração de registros de dados
• Manutenção rotineira, correções de bugs e pequenas refatorações
• Custos de software incorridos durante períodos de incerteza significativa de desenvolvimento
• Custos administrativos gerais não vinculados diretamente ao desenvolvimento
• Atividades de marketing, suporte e sucesso do cliente (customer success) pós-lançamento

O Problema do Controle de Tempo (Time-Tracking)

O maior desafio prático é a alocação do tempo de engenharia. É improvável que um engenheiro sênior que trabalha 40 horas por semana esteja realizando 100% de trabalho capitalizável — ele também está depurando a produção, mentorando colegas de equipe, participando de standups e revisando pull requests para sistemas legados. Sem um método defensável de controle de tempo (tickets de engenharia marcados por projeto, software de time-tracking ou pesquisas formais de alocação), as estimativas de capitalização não resistirão ao escrutínio da auditoria.

O Impacto nas Demonstrações Financeiras

Capitalizar versus lançar como despesa o mesmo dólar produz demonstrações financeiras drasticamente diferentes.

Efeito na Demonstração de Resultados

Um custo capitalizado não atinge a demonstração de resultados no período em que foi gasto. Em vez disso, ele é amortizado — normalmente de forma linear ao longo de três a cinco anos para software de uso interno. Assim, US$1 milhão de gastos de engenharia capitalizados no Ano 1 pode gerar apenas US$ 200 mil a US$ 333 mil de despesa de amortização a cada ano, deixando o lucro operacional do Ano 1 materialmente mais alto.

É por isso que o EBITDA recebe um impulso da capitalização. A amortização é, por definição, excluída do EBITDA — portanto, capitalizar mais custos de desenvolvimento desloca valores da despesa operacional (que reduz o EBITDA) para a amortização (que não reduz). Investidores que analisam métricas de SaaS frequentemente olham para o "EBITDA antes de P&D capitalizado" ou cálculos da "regra dos 40" usando P&D em caixa para enxergar através dessa dinâmica.

Efeito no Balanço Patrimonial

O software capitalizado aparece como um ativo intangível de longo prazo, frequentemente rotulado como "Custos de Desenvolvimento de Software Capitalizados" ou algo semelhante. Isso:

• Aumenta os ativos totais e o patrimônio líquido
• Melhora o retorno sobre ativos (ROA) apenas se os ganhos crescerem mais rápido do que a base de ativos
• Cria um ativo que deve ser testado para redução ao valor recuperável (impairment) se o projeto for abandonado ou se seu valor declinar

Se um projeto for abandonado no meio do desenvolvimento, os custos previamente capitalizados devem ser baixados — o que produz uma perda súbita e, muitas vezes, material. Esta é uma das razões pelas quais o novo ASU 2025-06 enfatiza tão fortemente o limite de "probabilidade de conclusão".

Efeito na Demonstração do Fluxo de Caixa

Os custos de desenvolvimento capitalizados são normalmente classificados como atividades de investimento (não operacionais), o que faz com que o fluxo de caixa operacional pareça mais forte. Investidores sofisticados ajustam isso ao comparar empresas — mas o número principal ainda é beneficiado.

Erros Comuns Que Colocam as Empresas em Dificuldades

Auditores e adquirentes veem os mesmos erros repetidamente.

Capitalizar Custos de Pré-Autorização

O erro clássico é capitalizar o tempo de engenharia gasto antes que a administração aprovasse formalmente o projeto. Sem uma autorização documentada e um compromisso de financiamento, esses custos deveriam ter sido lançados como despesa. Certifique-se de ter atas de reunião, aprovações do conselho ou autorizações por escrito que estabeleçam quando a gestão se comprometeu.

Ausência de Documentação por Projeto

Se um regulador ou auditor perguntar "mostre-me os projetos que você capitalizou" e você puder apenas apontar para gastos gerais de engenharia, você perderá a questão. 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 algum percentual raramente sobrevivem a uma auditoria.

Continuação da Capitalização Após o Lançamento

No momento em que o software está pronto para o uso pretendido, a capitalização para. Correções de bugs, ajustes de desempenho e melhorias menores após esse ponto são despesas operacionais. Novas funcionalidades com escopo definido separadamente podem iniciar um novo período de capitalização — mas o trabalho rotineiro pós-lançamento não pode.

Esquecimento do Teste de Recuperabilidade (Impairment)

O software capitalizado é um ativo, e os ativos devem passar por teste de recuperabilidade (impairment) se o seu valor cair. Se você desativar um produto, encerrar uma funcionalidade ou reescrever fundamentalmente o sistema, deverá reavaliar e, provavelmente, dar baixa no saldo anterior.

Como Estabelecer um Processo Defensável

Se você decidir que a capitalização é adequada para sua empresa, o processo importa tanto quanto a política.

1. 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á o tempo. Obtenha a aprovação do seu CFO ou comitê de auditoria.

2. Acompanhe o tempo de engenharia ao nível do projeto. Esta é a base fundamental. Quer você use etiquetas no Jira, tags personalizadas em um rastreador de projetos ou folhas de horas (timesheets) formais, você precisa defender que "o engenheiro X gastou Y% de seu tempo em trabalho capitalizável no projeto Z".

3. Documente a aprovação da gestão. Cada projeto capitalizável precisa de evidência de autorização — aprovação por escrito datada, atas de reuniões de diretoria ou um termo de abertura de projeto assinado pela liderança.

4. Reavalie incertezas significativas regularmente. Sob a nova regra, você precisa monitorar se as funcionalidades ainda são inéditas ou não comprovadas e se os requisitos estão se estabilizando. Revisões trimestrais com a liderança de engenharia são razoáveis.

5. Crie cronogramas de amortização por projeto. Cada projeto capitalizado começa a ser amortizado quando estiver pronto para uso, e você precisa rastrear o custo base desse ativo, a amortização acumulada e a vida útil restante.

6. Teste a recuperabilidade quando os projetos mudarem. Sempre que você abandonar, reescrever materialmente ou encerrar um 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 na escrituração contábil desde o primeiro dia compensa anos depois. Investidores durante uma rodada de captação Série B analisarão seu balancete de verificação; adquirentes em um processo de venda rastrearão as transações até os lançamentos de diário; o IRS pode comparar seu tratamento GAAP com o tratamento fiscal de P&D da Seção 174, que possui suas próprias regras. Se seus livros não separarem projetos capitalizados de despesas operacionais, não puderem vincular os custos de tempo de engenharia a projetos específicos ou não mantiverem cronogramas de amortização limpos, cada ciclo de auditoria e due diligence se tornará doloroso.

A solução é simples em conceito: mantenha uma estrutura de contas limpa, rastreie o tempo ao nível do projeto e documente as decisões por trás de cada lançamento de capitalização. Fazer isso desde o início evita limpezas dispendiosas mais tarde.

Mantenha a Contabilidade do Seu Software Pronta para Auditoria

Esteja você capitalizando sua primeira plataforma interna ou gerenciando cronogramas de amortização em dezenas de projetos, registros financeiros limpos são a base. O Beancount.io oferece contabilidade em texto simples que fornece 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 que rastreiam o desenvolvimento capitalizado em vários projetos, ter livros que podem ser lidos como código é uma vantagem séria. Comece gratuitamente e veja por que desenvolvedores e profissionais de finanças estão mudando para a contabilidade em texto simples.