Resumo executivo

Sua software house já passou por esta situação?
O sistema foi entregue, o cliente testou, pediu ajustes, a equipe corrigiu — e o software já está sendo usado no dia a dia da empresa.

Mas, na hora de assinar o Termo de Aceite Final, o cliente desaparece.
Sem assinatura, o faturamento da última parcela (frequentemente entre 20% e 30% do contrato) fica travado.

Esse tipo de situação cria o que muitas empresas chamam de “projeto zumbi”:
o sistema está vivo em produção, mas o projeto nunca é formalmente encerrado.

A boa notícia é que direito empresarial e boas práticas de engenharia de software oferecem mecanismos para reduzir esse risco.

Neste artigo, explicamos como combinar:

• Código Civil
• boas práticas de homologação técnica (UAT)
• cláusulas contratuais bem estruturadas

para estruturar um processo de aceite formal ou tácito juridicamente defensável.

A dor silenciosa do “projeto zumbi”

Em muitas software houses, o fluxo é previsível:

1. O sistema é desenvolvido e entregue.
2. O cliente executa testes e solicita ajustes.
3. A equipe realiza correções.
4. O sistema entra em produção.

Até aqui, tudo funciona.
O problema surge quando chega o momento de formalizar o aceite final.
Alguns clientes:

• atrasam deliberadamente a assinatura
• pedem ajustes fora de escopo
• alegam que “a diretoria ainda vai avaliar”
• simplesmente deixam de responder

Enquanto isso:

• o software está em uso
• o projeto permanece aberto
• o faturamento fica bloqueado

Essa situação não é apenas operacional.
Ela representa um risco direto de fluxo de caixa e governança contratual.

O que diz a legislação brasileira

Muitos profissionais de tecnologia acreditam que dependem exclusivamente da assinatura formal do cliente.
Na prática, o direito contratual brasileiro oferece mecanismos que podem ajudar a estruturar o aceite da entrega, especialmente em relações empresariais (B2B).

O silêncio pode ter valor jurídico

O artigo 111 do Código Civil estabelece:
“O silêncio importa anuência quando as circunstâncias ou os usos o autorizarem e não for necessária a declaração de vontade expressa.”

Isso significa que, em determinadas situações, a ausência de manifestação pode ser interpretada como concordância.
No contexto de contratos de tecnologia, essa interpretação pode ser considerada quando existem elementos como:

• prazo contratual de homologação
• notificação formal de entrega
• possibilidade real de contestação
• ausência de manifestação dentro do prazo

Nesses casos, o silêncio pode ser interpretado como aceitação da entrega, dependendo das circunstâncias e do conjunto de provas.
Por isso, muitos contratos de tecnologia estabelecem prazos objetivos de homologação, após os quais o aceite pode ocorrer automaticamente se não houver contestação formal.

A autonomia dos contratos empresariais

Outro ponto importante vem do artigo 421-A do Código Civil, que reforça a autonomia da vontade nas relações empresariais.
Esse dispositivo estabelece que:

• contratos entre empresas presumem paridade entre as partes
• há intervenção mínima do Judiciário
• as regras negociadas tendem a ser respeitadas

Na prática, isso significa que cláusulas de homologação e aceite podem ser estruturadas livremente, desde que:

• sejam claras
• concedam prazo razoável de análise
• respeitem a boa-fé objetiva (art. 422 do Código Civil)

Quando bem redigidas, essas cláusulas ajudam a tornar o processo de encerramento do projeto mais previsível e menos dependente de formalidades tardias.

A teoria do adimplemento substancial

Outro conceito frequentemente aplicado pelos tribunais é a chamada Teoria do Adimplemento Substancial.
Segundo essa interpretação, adotada em diversos precedentes do Superior Tribunal de Justiça, quando a maior parte da obrigação foi cumprida, pequenas falhas residuais não justificam:

1. a rescisão do contrato
2. a retenção integral do pagamento

Em contratos de software, isso pode ocorrer quando:

• o sistema funciona
• atende à finalidade econômica do projeto
• eventuais ajustes são pontuais ou cosméticos

Nesses casos, a tendência é que o Judiciário considere que o núcleo do contrato foi cumprido, embora ainda possam existir correções ou ajustes posteriores.
Isso não significa pagamento automático, mas dificulta a retenção desproporcional de valores por questões secundárias.

Como os tribunais analisam casos de software

Quando disputas desse tipo chegam ao Judiciário, os tribunais geralmente analisam o conjunto de evidências da execução do contrato.
Entre os elementos frequentemente considerados estão:

• contrato assinado
• notas fiscais emitidas
• troca de e-mails entre as equipes
• chamados de suporte
• registros de implantação
• evidências de uso do sistema

Em muitos casos, o uso efetivo do software em ambiente produtivo é interpretado como indício relevante de aceitação da solução.
Isso não substitui automaticamente um termo de aceite formal, mas pode reforçar a prova de que o serviço foi entregue e utilizado.

Exemplos de decisões judiciais relevantes 

1 — STJ: teoria do adimplemento substancial limita a rescisão contratual

STJ – REsp 1.051.270
O Superior Tribunal de Justiça consolidou o entendimento de que o adimplemento substancial busca evitar a resolução de contratos quando a maior parte da obrigação já foi cumprida.

Em julgamento citado frequentemente pela doutrina, o STJ afirmou que o instituto: “visa impedir o uso desequilibrado do direito de resolução por parte do credor, privilegiando a preservação do contrato com base nos princípios da boa-fé objetiva e da função social.”

Na prática, isso significa que, quando a obrigação foi substancialmente cumprida, pequenas falhas ou pendências não costumam justificar a rescisão do contrato ou a retenção integral da contraprestação.
Esse entendimento é frequentemente utilizado em disputas contratuais envolvendo entregas técnicas complexas, como projetos de tecnologia.

2 — STJ: prestação sem utilidade pode configurar inadimplemento

STJ – REsp 1.731.193
Em caso envolvendo contrato para desenvolvimento de sistema de gestão empresarial, o STJ analisou se a entrega de software incompleto configuraria cumprimento parcial ou inadimplemento total.
A corte entendeu que: se a prestação realizada não atende à finalidade econômica do contrato, pode ser considerada inadimplemento, ainda que parte do serviço tenha sido executada.

Ou seja, o Judiciário avalia se o produto entregue realmente cumpre a função para a qual foi contratado.
Essa decisão reforça a importância de critérios claros de aceite e homologação técnica nos contratos de desenvolvimento de software.

3 — STJ: cumprimento substancial pode impedir rescisão do contrato

STJ – REsp 1.636.692
Em outro precedente relevante, o tribunal analisou situação em que grande parte de um contrato havia sido cumprida.

O STJ concluiu que: quando há adimplemento substancial da obrigação, a resolução do contrato pode ser considerada medida excessiva, devendo o credor buscar apenas o recebimento do saldo eventualmente devido.
Esse entendimento reforça o princípio da preservação dos contratos, especialmente quando o objetivo econômico do negócio já foi alcançado.

A importância do processo técnico de homologação

Para que essas interpretações jurídicas tenham força, o processo técnico de entrega precisa ser estruturado.
Uma prática comum é separar claramente três fases do projeto.

1. Entrega técnica

O fornecedor disponibiliza a versão final do software em ambiente de homologação (UAT).
Nessa etapa:

• o cliente é formalmente notificado
• inicia-se o prazo de testes

2. Homologação (UAT)

O cliente executa os testes previstos no escopo.
Boas práticas incluem:

• roteiros de teste definidos
• critérios objetivos de aceite
• registro de bugs ou falhas

Muitas empresas estabelecem prazo de homologação, por exemplo:
10 a 15 dias úteis.

3. Aceite formal ou por decurso de prazo

Ao final do período de homologação, podem ocorrer três situações:

1. Aceite formal — cliente aprova a entrega
2. Rejeição fundamentada — cliente aponta falhas impeditivas
3. Ausência de manifestação dentro do prazo

Nesse terceiro cenário, alguns contratos estabelecem o chamado aceite por decurso de prazo, desde que o cliente tenha sido devidamente notificado.

Como estruturar uma cláusula de aceite por decurso de prazo

Contratos de desenvolvimento de software podem incluir dispositivos específicos para evitar projetos indefinidamente abertos.
Uma cláusula bem estruturada normalmente inclui:

1. Prazo objetivo de homologação

• Exemplo: A Contratante terá prazo de 15 dias para realizar os testes após a notificação de entrega.

2. Canal oficial de comunicação

Para evitar conflitos, o contrato pode definir que eventuais rejeições devem ser registradas por meios formais, como:

• e-mail corporativo
• sistema de chamados
• plataforma de gestão de projeto

3. Classificação de falhas

É recomendável distinguir:
Bugs impeditivos

• impedem o funcionamento do sistema

Bugs não impeditivos

• ajustes visuais
• melhorias
• pequenas inconsistências

Normalmente apenas falhas impeditivas suspendem o prazo de aceite.

4. Gatilho de aceite por decurso de prazo

Uma cláusula típica pode prever que:
A ausência de manifestação formal da Contratante dentro do prazo de homologação, ou o uso do sistema em ambiente de produção, poderá ser interpretada como aceite da entrega, autorizando a emissão da nota fiscal correspondente, sem prejuízo de correções posteriores previstas em garantia ou SLA.

Como gerar provas de entrega

Mesmo com cláusulas contratuais bem redigidas, documentação é essencial.
Alguns registros importantes incluem:

• e-mail de entrega da versão
• logs de implantação
• registros de deploy
• chamados de suporte
• acessos de usuários
• relatórios de uso do sistema

Essas evidências ajudam a demonstrar:

• que a entrega ocorreu
• que o cliente teve oportunidade de testar
• que o sistema foi efetivamente utilizado.

Conclusão: retome o controle do encerramento dos projetos

Projetos de software que permanecem abertos indefinidamente representam um problema de governança.
Não se trata apenas de relacionamento com o cliente — trata-se de gestão saudável do fluxo de caixa e dos contratos.
Ao estruturar:

• processos claros de homologação
• prazos objetivos de aceite
• cláusulas contratuais bem redigidas
• documentação adequada da entrega

é possível reduzir significativamente o risco de “projetos zumbis”.

O aceite deixa de depender exclusivamente de uma assinatura tardia e passa a fazer parte de um processo técnico e contratual previsível.

Perguntas frequentes

O que fazer se o cliente apontar falhas no último dia do prazo de homologação?
Avalie se a falha é impeditiva ou não impeditiva.
Falhas impeditivas podem justificar a suspensão do prazo até correção.
Falhas secundárias geralmente podem ser tratadas dentro da fase de suporte ou garantia.

Posso faturar a última parcela sem assinatura formal?
Depende das circunstâncias.
Se o contrato prevê prazo de homologação e aceite por decurso de prazo, e se houver evidência de entrega e notificação ao cliente, o faturamento pode ser juridicamente defensável.
Cada caso, contudo, deve ser analisado conforme suas provas e cláusulas contratuais.

O cliente colocou o sistema em produção sem assinar o aceite. O que fazer?
Nesse caso, é recomendável:

• documentar evidências de uso
• registrar logs ou chamados
• formalizar comunicação ao cliente

Esses elementos podem reforçar a prova de que o software foi entregue e está sendo utilizado para sua finalidade econômica.

Aviso:
Este artigo possui caráter informativo e não substitui aconselhamento jurídico específico para cada contrato ou situação.