Pergunte a um gerente de engenharia de software quando um projeto "começou" e você vai ouvir um número de sprint. Pergunte a mesma coisa ao controller da empresa e, segundo as regras contábeis que regem software de uso interno desde 1998, a resposta deveria vir de uma lista rígida de três estágios que presume que ninguém escreve código antes de os requisitos estarem travados. Qualquer pessoa que tenha lançado software na última década sabe que não é mais assim que funciona — e, em setembro de 2025, o FASB finalmente reconheceu isso também.
A Accounting Standards Update (ASU) 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software, descarta por completo o antigo teste baseado em estágios e o substitui por uma única pergunta baseada em julgamento: é provável que este software realmente seja concluído e faça o que deveria fazer? Para qualquer empresa que desenvolve software internamente — e especialmente para as equipes ágeis para as quais a regra antiga nunca foi pensada — isso muda quando os custos de desenvolvimento migram da demonstração de resultados para o balanço patrimonial, e em que medida.
O Problema: Um Manual de 1998 para o Desenvolvimento em Cascata
A orientação que a ASU 2025-06 substitui, a ASC 350-40 (originalmente SOP 98-1), foi escrita quando "desenvolvimento de software" significava um processo linear em cascata. Ela dividia todo projeto de software de uso interno em três estágios sequenciais:
- Estágio preliminar do projeto — formulação conceitual, avaliação de alternativas, seleção de fornecedores. Tudo aqui é despesado conforme incorrido.
- Estágio de desenvolvimento da aplicação — codificação, configuração e testes propriamente ditos. Os custos aqui são capitalizados.
- Estágio pós-implementação — treinamento e manutenção. Despesado novamente.
Essa estrutura funciona bem se uma equipe passa três meses escrevendo um documento de requisitos, obtém a aprovação e só então começa a construir. Ela desmorona no momento em que uma equipe está rodando sprints de duas semanas, lançando versões incrementais e revisando o escopo a cada retrospectiva. Em um ambiente ágil, "preliminar" e "desenvolvimento da aplicação" não são fases sequenciais — elas se entrelaçam, às vezes dentro do mesmo sprint. Empresas e seus auditores passaram anos discutindo a qual estágio um determinado sprint de duas semanas realmente pertencia, e a resposta honesta muitas vezes era "um pouco dos dois, estamos no chute". A própria consulta pública do FASB constatou que as partes interessadas apontavam consistentemente esse ponto como um dos mais dolorosos de aplicar de forma consistente dentro do GAAP.
A Solução: Um Teste, Não Três Estágios
A ASU 2025-06 remove toda referência aos antigos estágios do projeto. Em seu lugar, estabelece um único limite de reconhecimento de "probabilidade de conclusão". Sob a nova orientação, uma empresa capitaliza os custos de software de uso interno assim que ambas as condições a seguir forem verdadeiras ao mesmo tempo:
- A administração autorizou e se comprometeu a financiar o projeto. Isso não é um conceito novo — ele já existia na orientação anterior —, mas agora exerce um papel maior por ser uma de apenas duas condições de corte, em vez de estar enterrado dentro da análise de estágios.
- É provável que o projeto seja concluído e que o software seja usado para desempenhar sua função pretendida. Este é o elemento genuinamente novo, e é onde reside o julgamento.
Esse segundo critério exige avaliar se ainda existe incerteza significativa de desenvolvimento. O FASB aponta duas fontes principais dessa incerteza:
- Tecnologia não comprovada ou funcionalidade inédita, cuja viabilidade ainda não foi demonstrada por meio de codificação e testes reais — não um documento de design, não uma especificação, mas prova funcional.
- Requisitos de desempenho indefinidos ou ainda em mudança — o padrão os define como "o que uma entidade precisa que o software faça, por exemplo, funções ou recursos". Se a equipe ainda está debatendo de forma relevante o que o produto precisa fazer, essa incerteza não foi resolvida.
Na prática, isso significa que o momento da capitalização agora acompanha evidências de viabilidade, não uma fase de calendário. Uma equipe que dedica dois sprints a um "spike" para testar um recurso tecnicamente inédito antes de se comprometer a construí-lo de fato despesaria esses sprints de exploração — a incerteza sobre se o recurso sequer pode ser construído ainda não foi resolvida. Uma vez que o spike comprova a viabilidade e a administração compromete orçamento para a construção completa, o limite de "probabilidade de conclusão" é atingido e os custos de desenvolvimento subsequentes passam a ser capitalizados, independentemente das cerimônias ágeis envolvidas.
Por Que o FASB Diz Que a Capitalização Não Vai Mudar Muito — Exceto para SaaS
A própria expectativa do FASB é que, para a maioria dos softwares de uso interno on-premises ou baseados em licença, as alterações não devem mudar drasticamente os resultados de capitalização — as empresas já capitalizavam a partir do momento em que a codificação real começava, e o novo teste chega mais ou menos ao mesmo resultado, só que sem o exercício de rotulagem por estágios.
Software desenvolvido para entrega por meio de um arranjo de SaaS ou nuvem é uma história diferente. O FASB espera explicitamente que a capitalização diminua para esses projetos. O raciocínio: produtos SaaS são, por natureza, construídos e reconstruídos continuamente, com incerteza técnica e de produto significativa persistindo até bem avançado o cronograma de desenvolvimento — às vezes até pouco antes de um recurso estar perto do lançamento. Sob o teste de probabilidade de conclusão, essa incerteza persistente significa que muitos custos de desenvolvimento de SaaS não vão superar a barra de capitalização até um ponto bem mais tardio da construção do que o antigo modelo de estágios sugeriria. O efeito líquido: mais da folha de pagamento de engenharia de um produto SaaS acaba como despesa corrente de P&D, em vez de um ativo amortizado ao longo de vários anos. Essa é uma mudança relevante para o EBITDA reportado e a base de ativos de qualquer empresa de SaaS, mesmo antes de uma única linha do código real ser alterada.
Um Exemplo Concreto: Duas Equipes, Dois Resultados
Digamos que uma empresa de SaaS com 40 pessoas decida construir um módulo de previsão com IA para seu produto. Veja como as regras antiga e nova tratariam a mesma construção de oito meses de forma diferente.
Sob o antigo modelo de estágios, a equipe financeira tentaria traçar uma linha: as primeiras seis semanas de levantamento de requisitos e avaliação de fornecedores foram "preliminares" (despesadas), e tudo depois da reunião de kickoff foi "desenvolvimento da aplicação" (capitalizado) — mesmo que a equipe de engenharia tenha passado os dois meses seguintes rodando spikes exploratórios para descobrir se a abordagem de previsão escolhida conseguiria atingir a precisão aceitável nos volumes de dados de produção. Ao pé da letra da regra antiga, uma vez que o "estágio" mudava, esses sprints de spike costumavam ser capitalizados também, pois tecnicamente aconteciam depois da reunião de kickoff.
Sob a ASU 2025-06, a equipe financeira pergunta, em vez disso: quando se tornou provável que esse recurso seria concluído e funcionaria como pretendido? Se a abordagem de precisão ainda não estava comprovada nos primeiros dois meses — a equipe estava testando três abordagens de modelagem diferentes e não sabia se alguma delas superaria a barra —, todo esse período de exploração é despesado, independentemente de qual "estágio" ele ocupasse no calendário. A capitalização começa somente depois que a equipe escolhe uma abordagem validada e a administração compromete orçamento para construí-la, o que, neste exemplo, pode acontecer no terceiro mês, não no segundo. O resultado: um ativo capitalizado menor, uma despesa de P&D do período corrente maior e — de forma importante — um número que o CFO consegue de fato defender em uma auditoria, porque está atrelado a um ponto de decisão específico e documentado, em vez de um rótulo de estágio aplicado depois do fato.
É exatamente essa a mudança que o FASB espera em todo o setor de SaaS: menos "chamamos isso de desenvolvimento da aplicação porque foi o que veio depois da chamada de kickoff" e mais "podemos apontar o sprint em que o risco técnico foi eliminado".
Datas de Vigência e Transição
A ASU 2025-06 é vigente para todas as entidades — públicas e privadas — para períodos de relatório anual iniciados após 15 de dezembro de 2027, e para os períodos interinos dentro desses anos. A adoção antecipada é permitida para qualquer entidade, em qualquer período interino ou anual, a partir da emissão da norma.
As entidades podem aplicar as alterações usando uma de três abordagens de transição: prospectivamente, apenas para novos custos de software incorridos após a data de vigência; prospectivamente, para custos incorridos a partir do início do ano de adoção; ou retrospectivamente, a todos os períodos apresentados. Essa flexibilidade importa — uma empresa no meio da construção de uma grande reformulação de plataforma quando a regra entra em vigor não precisa desfazer anos de histórico de custos capitalizados, a menos que opte pela abordagem retrospectiva.
O Que Empresas de Software Pequenas e Médias Devem Fazer Agora
Dezembro de 2027 soa distante, mas o trabalho prático de preparação não é uma tarefa de último trimestre, principalmente para empresas que operam equipes financeiras enxutas, sem uma função dedicada de contabilidade técnica.
Comece a documentar o julgamento de "probabilidade de conclusão" em tempo real, não em retrospecto. O antigo modelo de estágios era mecânico — era possível reconstruir em qual estágio um projeto estava meses depois, a partir das datas dos sprints. O novo teste pergunta quando deixamos de ter incerteza técnica, o que é um julgamento muito mais difícil de reconstruir depois do fato. Crie agora um hábito leve: quando a liderança de engenharia e a área financeira concordarem que um recurso superou seu spike técnico e está comprometido para construção, registre essa data. Esse registro se torna sua data de início de capitalização e seu suporte de auditoria.
Separe o trabalho de "exploração" do trabalho de "construção comprometida" no seu controle de tempo ou nos códigos de projeto, caso ainda não faça isso. Seja por meio de uma flag de épico no Jira, um código de centro de custo separado, ou apenas uma etiqueta marcada na sua ferramenta de controle de tempo, ter uma trilha de dados limpa sobre quando um recurso passou de spike/protótipo para desenvolvimento comprometido tornará a aplicação do novo padrão drasticamente menos dolorosa do que tentar reconstruí-la de memória durante uma auditoria.
Modele as duas opções de transição antes de escolher uma. Se sua empresa vinha capitalizando agressivamente os custos de desenvolvimento de SaaS sob o antigo modelo de estágios, a aplicação retrospectiva pode gerar uma baixa contábil pontual de ativos previamente capitalizados, à medida que esses custos são reclassificados como se tivessem sido despesados desde o início. Uma abordagem prospectiva evita essa reapresentação, mas significa que sua demonstração de resultados não refletirá a nova metodologia até que novos projetos comecem após a adoção. Calcule os números sob as duas opções antes que seu comitê de auditoria precise decidir.
Converse com seu auditor com antecedência, especialmente se você é uma empresa de SaaS. Dada a própria expectativa do FASB de uma redução na capitalização para desenvolvimento de SaaS, é provável que os auditores escrutinem os julgamentos de probabilidade de conclusão com mais rigor do que escrutinavam as classificações de estágio sob a regra antiga — precisamente porque é mais subjetivo. Uma empresa que chega à sua auditoria de 2028 com um framework documentado e contemporâneo para tomar essa decisão terá uma conversa muito mais tranquila do que uma que precisa reconstruí-lo depois do fato.
Livros Contábeis Limpos Tornam os Julgamentos Mais Fáceis de Defender
Todo julgamento contábil — e "probabilidade de conclusão" é, sem dúvida, um julgamento — só é tão defensável quanto os registros por trás dele. Se seu plano de contas já separa os gastos de P&D por projeto, e seus lançamentos contábeis são versionados e auditáveis, em vez de viverem em planilhas desconectadas, aplicar um padrão como a ASU 2025-06 se torna uma questão de rotular dados existentes, em vez de reconstruir o histórico a partir de conversas no Slack. A contabilidade em texto simples do Beancount.io oferece, por padrão, esse tipo de livro-razão transparente e versionado em git — cada lançamento rastreável, cada mudança revisável, sem aprisionamento a fornecedor. Comece gratuitamente e construa livros contábeis que se sustentam, seja a pergunta feita por um auditor, um adquirente ou a próxima atualização do FASB.