Falha no sistema ERP: rescisão e restituição ao cliente

Uma falha no sistema ERP pode comprometer o faturamento, a contabilidade e a rotina fiscal da empresa. Porém, recuperar pagamentos exige demonstrar como o software deixou de cumprir o contrato. Entenda a diferença entre encerrar a contratação, pedir restituição e comprovar prejuízos adicionais.

maos paradas sobre o teclado de um notebook generico com tela apagada, ao lado de uma pasta azul-marinho e uma caneta dourada, em mesa de es
A análise começa pela função que o sistema deveria cumprir na operação da empresa.

Quando a falha no sistema ERP compromete o contrato

O ERP integra atividades de gestão empresarial. Por isso, avaliar seu funcionamento exige comparar as entregas com o escopo do contrato. Um problema pontual não tem necessariamente o mesmo peso de erros persistentes em funções essenciais.

Por exemplo, o sistema pode permitir algumas operações e falhar na integração entre faturamento e contabilidade. Nesse cenário, contar acessos ou notas emitidas não esclarece, sozinho, se o fornecedor cumpriu a obrigação.

A análise deve identificar o erro, sua frequência e o impacto na finalidade da contratação. Além disso, precisa considerar a responsabilidade por implantação, migração de dados e parametrização. Essas tarefas podem envolver obrigações de ambas as partes.

Assim, a discussão sobre inadimplemento contratual depende de fatos concretos. O contrato, os testes e as tentativas de correção ajudam a distinguir uma dificuldade de implantação de uma entrega inadequada.

O que mostra a decisão de Joinville

Uma notícia oficial do TJSC, de 6 de novembro de 2026, relata o processo 0047866-27.2012.8.24.0038. A 2ª Vara Cível de Joinville condenou duas fornecedoras a restituir mais de R$ 1 milhão por falhas de ERP.

Além disso, a decisão reconheceu a inexigibilidade de cobranças após a rescisão. Contudo, rejeitou o pedido relativo a multas por falta de nexo causal. Ou seja, reconhecer o problema no software não bastou para acolher todos os prejuízos alegados.

O caso ilustra a importância de separar os pedidos e suas provas. Por outro lado, não estabelece uma regra de devolução integral para qualquer contrato de software.

Limite da informação: esta síntese se apoia na notícia institucional, sem acesso ao inteiro teor da sentença. Trata-se de decisão de primeiro grau. A pesquisa fornecida não confirma eventual recurso nem trânsito em julgado.

Resolução, restituição e indenização: pedidos diferentes

O art. 475 do Código Civil, Lei 10.406/2002, permite à parte lesada pedir resolução ou cumprimento do contrato. Também admite perdas e danos, conforme os pressupostos aplicáveis.

Na prática, resolução significa encerrar o vínculo por inadimplemento. Já a restituição envolve os valores que devem retornar ao contratante. Por sua vez, a indenização adicional trata de outros prejuízos demonstráveis.

PedidoQuestão centralDocumentação útil
Resolução contratualO descumprimento comprometeu a finalidade do contrato?Escopo, testes, chamados e respostas do suporte
RestituiçãoQuais pagamentos o pedido abrange e por quê?Contrato, comprovantes e descrição das entregas
Danos adicionaisQual prejuízo decorreu diretamente da falha?Documentos de cada perda e demonstração do nexo causal
InexigibilidadeQual cobrança posterior carece de fundamento?Notificação, faturas e registros do encerramento

Portanto, afastar uma cobrança não equivale a receber dinheiro de volta. Esses valores não devem compor uma soma indistinta de restituição. As normas aqui explicadas também não representam uma descrição dos fundamentos específicos da sentença de Joinville.

Uso temporário e aceite do sistema impedem a restituição?

O uso temporário, por si só, não resolve essa discussão. Afinal, operar o sistema pode coexistir com falhas relevantes e tentativas de correção. É preciso examinar a utilidade efetiva da entrega.

Da mesma forma, o aceite exige leitura cuidadosa. O documento abrange todo o projeto ou apenas uma etapa? Há ressalvas, testes pendentes ou chamados contemporâneos?

Por isso, o contratante deve relacionar o aceite aos critérios de homologação e aos erros que identificou. O fornecedor, por sua vez, pode apresentar evidências das funcionalidades entregues e das obrigações do cliente.

Assim, nem o uso temporário elimina automaticamente uma pretensão de restituição, nem a simples reclamação invalida o aceite. A conclusão depende do escopo, da gravidade das falhas e das provas.

Como documentar a falha no sistema ERP

Uma reclamação genérica explica pouco sobre a origem do problema. Por isso, o registro deve indicar data, versão do sistema e operação afetada. Também deve descrever o resultado esperado e o que aconteceu.

Além disso, preserve os chamados e as respostas do suporte. Eles ajudam a reconstruir o histórico de correções e a verificar se o erro persistiu após cada intervenção.

Quatro etapas para organizar a documentação

1

Definir a entrega

Reúna contrato, anexos, escopo e critérios de aceite.

2

Registrar o erro

Guarde logs, versões e resultados dos testes.

3

Documentar o suporte

Organize chamados, respostas, e-mails e atas de reunião.

4

Relacionar os efeitos

Separe pagamentos, notificações e documentos de cada prejuízo.

Dessa forma, a documentação conecta a obrigação contratual ao comportamento do software. Testes comparativos também podem ajudar, desde que registrem condições, dados utilizados e resultados.

O papel da perícia e das testemunhas

A perícia técnica de software pode esclarecer a origem dos erros e sua relação com a implantação. Já as testemunhas podem relatar a rotina operacional e as dificuldades que acompanharam.

Contudo, cada meio de prova tem uma função. O relato de uma dificuldade não substitui necessariamente a análise técnica de sua causa. Por isso, documentos, perícia e depoimentos devem dialogar entre si.

O art. 373, I, II e § 1º, do CPC, Lei 13.105/2015, orienta a distribuição do ônus da prova. O autor demonstra os fatos constitutivos de seu direito. O réu prova fatos impeditivos, modificativos ou extintivos.

Uma distribuição diferente exige fundamentação e oportunidade de cumprir o encargo. Portanto, a negativa da versão do cliente não gera inversão automática do ônus da prova.

maos organizando papeis virados em uma pasta azul-marinho, com notebook generico fechado ao lado sobre mesa de escritorio brasileiro, luz na
Um histórico organizado facilita a relação entre obrigação, falha e prejuízo.

Multas fiscais e lucros cessantes exigem prova própria

O art. 403 do Código Civil delimita a relação entre inexecução e perdas e danos. A análise abrange prejuízos efetivos e lucros cessantes ligados direta e imediatamente ao descumprimento.

Por isso, apresentar uma multa fiscal não demonstra, sozinho, que o software a causou. É necessário explicar qual erro afetou a obrigação fiscal e conectar os acontecimentos.

Da mesma forma, uma queda no faturamento não equivale automaticamente ao lucro que a empresa deixou de obter. O pedido de lucros cessantes precisa de demonstração específica do prejuízo e do nexo causal.

No caso noticiado pelo TJSC, a falta dessa ligação levou à rejeição do pedido relativo às multas. Assim, a restituição por software defeituoso e a indenização adicional devem seguir análises próprias.

Como avaliar cobranças após o encerramento contratual

O primeiro passo é conferir o motivo e a data de cada cobrança. Depois, compare as faturas com o contrato e a comunicação de encerramento. A discussão pode depender do período e do serviço a que o valor se refere.

Além disso, preserve a notificação e a resposta do fornecedor. Esses registros ajudam a delimitar o conflito sobre cobranças após rescisão.

O caso de Joinville reconheceu a inexigibilidade de cobranças posteriores ao encerramento. Contudo, isso não autoriza toda empresa a interromper pagamentos unilateralmente diante de qualquer falha.

Portanto, antes de suspender pagamentos ou abandonar o sistema, avalie as obrigações contratuais e a documentação disponível. Uma comunicação precisa pode delimitar a controvérsia e apoiar uma tentativa de solução extrajudicial.

O CDC vale para contratos empresariais de ERP?

A contratação por uma empresa não afasta nem garante, por si só, a aplicação do CDC. O art. 2º da Lei 8.078/1990 inclui pessoas jurídicas no conceito de consumidor, conforme a destinação final.

Além disso, a análise da vulnerabilidade pode importar no caso concreto. A síntese institucional do STJ sobre consumidor pessoa jurídica explica essa avaliação.

Assim, não basta chamar a contratante de cliente para afirmar uma relação de consumo. É preciso examinar como a empresa utiliza o ERP e quais circunstâncias demonstram sua vulnerabilidade.

Por isso, o artigo não presume a incidência do CDC no caso de Joinville. A análise contratual e a organização das provas continuam essenciais.

Prevenção para empresas de Aracaju e Sergipe

Para empresas de Aracaju e de outros municípios de Sergipe, a prevenção começa antes da implantação. O contrato deve traduzir as necessidades da operação em entregas que as equipes consigam testar.

Por exemplo, convém definir quem responde pela migração de dados e pela parametrização. Além disso, critérios de homologação ajudam a registrar o que cada etapa precisa entregar.

  • Descreva as funções essenciais e os testes de aceite.
  • Defina responsabilidades pela implantação e integração dos dados.
  • Estabeleça canais de suporte e prazos de correção.
  • Preveja registros das alterações de versão.
  • Organize um plano de saída com exportação dos dados.

Assim, gestores, equipe técnica e assessoria jurídica compartilham critérios para avaliar o cumprimento do contrato. Essas medidas são recomendações preventivas, não exigências atribuídas à sentença mencionada.

Por fim, uma falha no sistema ERP não significa necessariamente vazamento ou violação da LGPD. O caso abordado trata de funcionamento contratual; a pesquisa não aponta incidente de segurança.

Perguntas frequentes

Qualquer falha no sistema ERP dá direito à devolução?

Não. É preciso avaliar o descumprimento, sua gravidade e a finalidade contratual. Por isso, contrato, pagamentos e provas das falhas orientam a análise da restituição.

Usar o software por alguns meses impede o pedido?

Não necessariamente. O uso pode coexistir com defeitos relevantes. Assim, a análise considera a utilidade da entrega, os registros de erro e as tentativas de correção.

O aceite do sistema encerra a discussão?

O aceite tem importância, mas seu alcance depende do conteúdo e das circunstâncias. Portanto, examine quais etapas ele abrange e se há ressalvas ou falhas documentadas.

Quais provas devo reunir?

Reúna contrato, anexos, versões, logs, chamados, respostas e testes. Além disso, organize comprovantes de pagamento e documentos que relacionem cada prejuízo à falha alegada.

O fornecedor deve pagar toda multa fiscal?

Não automaticamente. O pedido exige demonstração específica da ligação entre o erro e a multa. No caso citado, a falta de nexo causal levou à rejeição desse pedido.

A empresa contratante sempre tem proteção do CDC?

Não. A destinação do serviço e as circunstâncias de vulnerabilidade exigem exame concreto. Por isso, a condição de pessoa jurídica, isoladamente, não resolve o enquadramento.

Análise jurídica do contrato de software

O Amadeus & Santos atua em Direito Digital. Para orientação sobre um caso concreto, a equipe pode analisar o contrato e a documentação das falhas. Atendimento em Aracaju/SE.

Falar com a equipe
Dr. Andress Amadeus

Dr. Andress Amadeus

Advogado especialista em Direito Digital e sócio do Amadeus & Santos Advogados Associados. Ver perfil completo.

Este conteúdo tem caráter informativo e não substitui a análise individual de um advogado. Cada caso exige avaliação técnica de suas particularidades. Texto elaborado com base na pesquisa de 10 de novembro de 2026. A referência ao caso de Joinville se limita à notícia institucional, sem confirmação da situação recursal.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Rolar para o topo

Sua dúvida merece uma boa orientação.

Deixe seus dados e fale com quem entende do assunto.