Software desenvolvido internamente: pesquisa, desenvolvimento e controle dos gastos

Delimitar o projeto e seu referencial

Este caderno trata de software desenvolvido internamente no alcance do CPC 04. Aquisição de licença, assinatura de acesso a plataforma, desenvolvimento para cliente e outros contratos podem exigir enquadramentos diferentes. A titularidade do código, os direitos contratuais e a capacidade de controlar benefícios devem ser examinados antes dos lançamentos.

O CPC 04, itens 54 e 57, distingue pesquisa de desenvolvimento e exige demonstração de viabilidade técnica, intenção e capacidade de concluir e utilizar ou vender, benefícios futuros, recursos disponíveis e mensuração confiável. Os itens 65 e 71 limitam a capitalização aos gastos a partir do atendimento dos requisitos, sem reintegrar despesas anteriores. O treinamento é tratado no item 67. Fonte: CPC 04.

Um marco comprovado, não uma data escolhida para melhorar o resultado

O procedimento proposto registra quando os critérios passaram a ser demonstráveis. Documentos técnicos, orçamento de recursos, plano de utilização e mensuração dos gastos devem conversar entre si. Uma validação realizada no final do projeto não permite presumir que todas as condições existiam desde seu início.

A área técnica deve sustentar viabilidade, entregas e disponibilidade para uso. A contabilidade verifica o enquadramento e a ligação dos custos. Apontamentos de horas ajudam a mensurar trabalho, mas não comprovam sozinhos que a atividade atendia aos critérios de reconhecimento do ativo.

Exemplo de custos por fase

Hipótese didática: a empresa identificou R$ 240.000,00 de gastos totais. O exame confirmou que apenas R$ 150.000,00 correspondem a custos diretamente atribuíveis após o atendimento dos requisitos. Não há financiamento, reavaliação ou outros componentes na simulação.

O ativo inicial é R$ 150.000,00 e as despesas somam R$ 90.000,00. A posterior conclusão bem-sucedida não permite simplesmente transferir os R$ 70.000,00 de pesquisa e trabalho anterior para o ativo. A memória deve preservar a fase e a evidência de cada parcela.

Disponibilidade para uso e amortização

Na continuidade do exemplo, o ativo fica disponível para a finalidade prevista, com vida útil validada de trinta meses, valor residual zero e consumo uniforme. A amortização mensal é R$ 150.000,00 ÷ 30 = R$ 5.000,00. Após três meses completos, o custo amortizado é R$ 15.000,00 e o valor contábil remanescente, R$ 135.000,00, sem outras alterações.

Os trinta meses não são vida útil padrão de software. A avaliação precisa considerar a utilização e o referencial, incluindo o marco de disponibilidade previsto no item 97 do CPC 04. A data da primeira venda ou do pagamento ao fornecedor não deve ser usada automaticamente como início da amortização.

Manutenção, melhoria e nova funcionalidade

Depois da entrada em uso, incidentes, suporte e desenvolvimento adicional devem ser classificados conforme sua natureza. A equipe não deve capitalizar toda atividade apenas porque usa o mesmo repositório do projeto original. A atualização precisa de objeto, evidência e análise próprios.

Uma despesa compartilhada entre sistemas exige critério de alocação e controle contra duplicidade. Horas já atribuídas a um contrato de cliente não devem compor integralmente outro ativo sem verificar o trabalho efetivo. Pagamentos a terceiros precisam ser ligados às entregas correspondentes.

Dossiê e fechamento

A composição pode reunir fases, aprovações, custos, documentos técnicos, disponibilidade, amortização e revisões. A recuperação do valor contábil exige acompanhamento próprio; terminar o desenvolvimento não garante benefício futuro permanente. A classificação fiscal também não se confunde automaticamente com o reconhecimento contábil.

A Growth Office pode integrar o controle à contabilidade de tecnologia e à gestão patrimonial. Solicite a organização dos gastos, fases e evidências dos projetos de software.