Quando o software entra no valuation: por que software proprietário é patrimônio, não despesa

A cena se repete em toda due diligence de empresa média no Brasil. O comprador pede a lista de ativos. O vendedor apresenta galpão, frota, estoque, carteira de clientes. Aí alguém pergunta: "e esse sistema que roda a operação inteira, quem é o dono dele?" Silêncio na sala. O sistema existe há oito anos, processa todos os pedidos, ninguém sabe onde está o contrato com quem o desenvolveu.

Nesse momento, o software proprietário da empresa — que deveria puxar o valuation para cima — vira um item de risco na planilha do comprador. E risco, em negociação, tem um preço: desconto.

A tese deste artigo é direta: software desenvolvido sob medida para a sua operação é patrimônio, com o mesmo status econômico de uma máquina ou de um imóvel. Mas ele só se comporta como patrimônio se for tratado como tal — juridicamente, contabilmente e tecnicamente. Na maioria das PMEs brasileiras, ele é tratado como despesa que se paga e se esquece. A diferença entre os dois tratamentos aparece exatamente no dia em que alguém precisa colocar um número na empresa: venda, captação de investimento, entrada de sócio ou sucessão.

O que a due diligence enxerga quando olha seu software proprietário

Quem compra uma empresa não compra o passado dela; compra a capacidade de gerar caixa no futuro. O software entra nessa conta por três portas.

Primeira porta: vantagem operacional replicável. Uma distribuidora de alimentos no interior do Ceará desenvolveu um sistema próprio de roteirização que corta 12% do custo logístico em relação aos concorrentes que usam planilha. Esses 12% caem direto na margem, todo mês, e continuarão caindo depois da venda — desde que o sistema venha junto, funcionando, com quem saiba mantê-lo. O comprador paga por isso porque está comprando margem futura, não código.

Segunda porta: barreira de saída de clientes. Quando o seu sistema está entranhado no processo do cliente — o portal onde ele consulta pedidos, o app que a equipe dele usa — trocar de fornecedor custa caro para ele. Churn baixo e receita previsível valem múltiplo maior. Isso é mensurável: basta comparar a retenção dos clientes que usam o portal com a dos que não usam.

Terceira porta: opcionalidade de produto. O sistema que você construiu para uso interno pode virar produto vendável para empresas do mesmo setor. Uma transportadora que licencia seu sistema de gestão de frota para outras transportadoras deixou de ser avaliada só pelo frete que fatura: ganhou uma linha de receita recorrente de software, que o mercado avalia com régua muito mais generosa do que serviço. Mesmo que você nunca licencie, a opcionalidade existir já é argumento na mesa.

Repare no que as três portas têm em comum: nenhuma delas depende de o software ser tecnicamente sofisticado. Dependem de ele ser seu, transferível e demonstrável.

A escritura do código: por que "todo mundo sabe que é meu" não basta

Pense num imóvel sem escritura. A casa está lá, você mora nela há vinte anos, a vizinhança inteira sabe que é sua. Na hora de vender, quanto o comprador paga? Bem menos que o preço de mercado — porque ele está comprando a casa e o problema jurídico junto. Software sem titularidade documentada é a mesma coisa: o valor de uso é integral, o valor de troca despenca.

No Brasil, a Lei do Software (9.609/98) até ajuda: programa desenvolvido por empregado ou prestador de serviço contratado para isso pertence, em regra, ao contratante. O problema é provar. Três situações reais que derrubam essa presunção na prática:

• O freelancer sem contrato. O sistema foi feito ao longo de anos por um desenvolvedor autônomo, pago por Pix, sem contrato escrito, sem nota fiscal. O repositório do código está na conta pessoal dele no GitHub. Juridicamente a empresa pode até ter razão; na due diligence, o advogado do comprador marca isso como risco e o desconto vem.
• O sócio técnico que saiu brigado. O código nasceu no notebook do ex-sócio, nunca houve cessão formal na saída dele. Cinco anos depois, na venda da empresa, ele reaparece com uma pretensão. Mesmo que não prospere, o litígio em potencial já contamina o preço.
• A dependência de uma cabeça só. O sistema é da empresa, mas só uma pessoa no mundo entende como ele funciona — e ela pode pedir demissão amanhã. Isso tem nome em due diligence: key person risk. O comprador precifica o custo de reconstruir o conhecimento, não o de manter o sistema.

A escritura do software, portanto, tem três folhas: contrato de desenvolvimento com cessão de direitos expressa, repositório de código em conta da empresa (não de pessoas) e documentação que permita a outro time competente assumir a manutenção. Sem as três, você tem uma casa sem escritura.

Do lado do balanço: quando o desenvolvimento vira ativo intangível

Aqui entra a parte que quase nenhuma PME faz. Pela norma contábil brasileira (CPC 04, que trata de ativos intangíveis), gastos com desenvolvimento de software podem ser ativados — ou seja, registrados como ativo no balanço e amortizados ao longo da vida útil — quando a empresa consegue demonstrar viabilidade técnica, intenção de uso e capacidade de gerar benefício econômico futuro. Gastos de pesquisa e manutenção corriqueira continuam como despesa.

O que a maioria faz? Lança tudo como despesa, todo mês, no automático. O efeito colateral é perverso: a empresa investe R$ 400 mil ao longo de três anos construindo um sistema que sustenta a operação, e o balanço não mostra nada disso. Para quem lê as demonstrações — banco, investidor, comprador — é como se o ativo não existisse. O lucro dos anos de construção ficou artificialmente menor, e o patrimônio, artificialmente magro.

Não é mágica contábil nem serve para inflar número: ativar desenvolvimento exige critério, documentação de horas e escopo, e conversa com o seu contador (que provavelmente vai torcer o nariz, porque dá trabalho). Mas é a diferença entre o software aparecer na fotografia oficial da empresa ou viver como fantasma que só o dono conhece.

O software que destrói valor no valuation

Nem todo sistema próprio soma. Alguns subtraem, e vale reconhecer os padrões antes que o comprador reconheça por você:

O legado que ninguém consegue tocar. Sistema em tecnologia morta, sem testes, sem documentação, que trava qualquer mudança na operação. O comprador não vê ativo; vê um passivo de migração de seis ou sete dígitos e desconta do preço.

O Frankenstein de planilhas com macro. Processos críticos rodando em Excel com VBA que só o analista que saiu sabia mexer. Tecnicamente é "software proprietário"; na prática é risco operacional documentado em vermelho no relatório de diligência.

O sistema clandestino. Licenças piratas embutidas, bibliotecas com licenças open source incompatíveis com uso comercial, dados de clientes tratados fora do que a LGPD permite. Cada item desses é uma cláusula de indenização que o comprador vai exigir no contrato.

A régua é a mesma nos três casos: o que define se o software soma ou subtrai não é ele existir, é ele ser auditável e transferível sem sustos.

Como transformar o sistema da sua empresa em patrimônio auditável

Se a sua empresa depende de um software próprio, este é o inventário mínimo — dá para começar esta semana:

1. Titularidade. Levante todo contrato de quem já desenvolveu o sistema (funcionário, agência, freelancer). Onde não houver cessão de direitos expressa, regularize agora, com termo retroativo. É barato hoje e caríssimo na véspera de uma venda.
2. Custódia. Código-fonte em repositório da empresa, com acesso administrado pela empresa. Domínios, servidores e contas de nuvem no CNPJ, nunca no CPF de alguém.
3. Documentação de transferência. Não precisa de tratado: um documento que permita a um time técnico competente subir o ambiente, entender a arquitetura e fazer o primeiro deploy sem depender de ninguém da casa. Se só uma pessoa sabe operar o sistema, esse é o item mais urgente da lista.
4. Higiene de licenças e dados. Inventário das bibliotecas de terceiros e suas licenças, e um mapa básico de quais dados pessoais o sistema trata e com que base legal.
5. Registro do valor. Converse com o contador sobre ativar os gastos de desenvolvimento daqui para frente e, em paralelo, monte um dossiê simples do que o sistema economiza ou gera: horas poupadas, erro reduzido, margem ganha. É esse número, não a elegância do código, que o comprador quer ver.

Feito isso, o mesmo sistema que era uma linha difusa de "serviços de TI" no DRE vira um item nomeável na negociação: um ativo com dono, com escritura, com valor demonstrado.

O sistema que você paga todo mês pode ser o ativo que você vende um dia

A pergunta que abre este artigo — "quem é o dono desse sistema?" — vai ser feita na sua empresa mais cedo ou mais tarde: por um comprador, um investidor, um banco ou um herdeiro. A resposta se constrói anos antes, nas decisões pequenas: assinar ou não o contrato de cessão, criar ou não a conta da empresa no repositório, documentar ou deixar para depois.

Software sob medida bem governado é o tipo de ativo que trabalha duas vezes: reduz custo enquanto você opera e aumenta o preço quando você negocia. Mal governado, trabalha duas vezes contra: custa caro para manter e ainda desconta o valuation.

Se você quer saber em qual dos dois cenários a sua empresa está, a Syntel faz um diagnóstico do seu software proprietário como ativo: titularidade, transferibilidade, riscos de diligência e o valor operacional que ele gera. Você sai com um relatório do que já é patrimônio, do que ainda é só despesa — e do caminho entre um e outro. Fale com a gente e agende o diagnóstico.