Exceção fiscal antiga sem erro no SAP: por que isso não prova que está certa

Um CIO que defende uma regra fiscal antiga com a frase "o sistema nunca deu erro" está usando o argumento mais frágil que existe para não revisar nada. Ausência de erro não é o mesmo que ausência de problema, é apenas ausência de teste. Um SAP pode rodar de forma estável, sem travamento, sem log de exceção, processando exatamente a mesma regra fiscal configurada anos atrás, mesmo que essa regra já não reflita mais o cenário tributário atual. O sistema não sabe se a regra está certa. Ele sabe se está sendo executada sem falha técnica. São coisas diferentes, e a confusão entre elas é onde nasce boa parte do risco fiscal silencioso em ambientes SAP.

Vale localizar onde essa regra antiga fisicamente mora, porque isso muda o que "revisar" significa. No SAP brasileiro ela está espalhada por camadas com donos diferentes: o esquema de cálculo TAXBRA, as estruturas mantidas pela J1BTAX, os Tax Codes de FTXP, a classificação por CFOP no cadastro, e o que foi escrito por cima disso em BAdI ou código Z. Nenhuma dessas camadas tem data de validade. Uma exceção parametrizada em 2019 continua ativa em 2026 pelo mesmo motivo pelo qual entrou: alguém a gravou, e gravação não expira.

O problema real: estabilidade técnica virou argumento contra a revisão

Em operações que acompanhamos, um padrão se repete: uma regra fiscal configurada há anos, sem qualquer erro técnico registrado, é tratada como validada permanentemente pelo simples fato de nunca ter travado o sistema. A lógica implícita é sedutora e errada: "está funcionando, por que mexer?" O problema é que "funcionando" aqui significa apenas "processando sem exceção técnica", não "calculando o valor correto para a legislação e a operação de hoje".

Duas situações concretas ilustram o padrão. A primeira: uma regra de tributação de ICMS configurada para um cenário operacional que existia quando a empresa vendia só para um estado, mantida sem revisão depois que a operação passou a ser multiestado. O sistema nunca acusou erro, porque tecnicamente a regra sempre foi executável, apenas deixou de refletir a operação real. A segunda: uma exceção fiscal criada para contornar um problema pontual, sem data de expiração nem responsável formal de revisão, que segue ativa anos depois, silenciosamente aplicada a cada transação, porque ninguém a desligou e o sistema não tem como saber que ela deveria ter sido temporária.

Em nenhum dos dois casos existe log de erro, alerta de sistema ou travamento. O SAP continua processando, porque processar não é validar mérito fiscal. O sistema audita sintaxe e execução, não audita se a premissa tributária por trás da regra ainda é verdadeira.

Por que isso acontece: o sistema audita execução, não audita mérito

A causa raiz não é tecnológica, é de arquitetura de decisão. Um ERP como o SAP é desenhado para garantir que uma regra configurada seja executada de forma consistente, repetível e sem erro de processamento. Ele não foi desenhado, e não tem como ser desenhado de forma genérica, para julgar se aquela regra continua fiscalmente correta à luz de uma legislação que muda, de uma operação que cresce ou muda de estado, ou de uma interpretação tributária que evolui. Essa validação de mérito é, por definição, humana: exige alguém que conheça a legislação atual, a operação atual, e compare as duas contra a configuração vigente.

A confusão se instala porque estabilidade técnica é visível e barata de observar (basta olhar o painel de erros), enquanto correção fiscal exige um esforço deliberado de revisão que tem custo, prazo e responsável. Sem um rito formal, o caminho de menor resistência é presumir que a ausência do primeiro sinal (erro técnico) implica o segundo (correção fiscal). Essa presunção nunca foi verdadeira, mas raramente é testada, porque testá-la exige alguém decidir, de forma ativa, gastar tempo revisando algo que "está funcionando".

O que o próprio SAP mostra sobre manter um sistema atualizado, mesmo estável

Existe um paralelo direto e verificável dentro do próprio ecossistema SAP: as SAP Notes de segurança. A SAP mantém um calendário mensal de publicação de notas de segurança (o chamado Security Patch Day), independente de qualquer cliente ter reportado um incidente. Duas fontes especializadas em segurança SAP, verificadas em 31 de agosto de 2026, acompanharam o mesmo Patch Day e chegaram a números diferentes: a Onapsis, que também contribuiu tecnicamente para esse ciclo, registra 33 notas de segurança novas e atualizadas, sendo 29 novas (11 delas em parceria com a Onapsis Research Labs), classificadas por ela como 5 notas HotNews e 9 de Alta Prioridade. Já a SAP Security Expert registra 31 notas no mesmo Patch Day (28 novas, mais um aviso de segurança no GitHub e duas atualizações de notas anteriores), classificadas como 4 críticas, 8 altas, 17 médias e 2 baixas. As duas fontes não usam a mesma metodologia de contagem nem a mesma taxonomia de severidade, e por isso os números não batem entre si, nem no total, nem na gravidade.

As duas divergem no número e concordam no que decide a questão: a SAP não espera um cliente relatar erro para publicar uma correção de segurança. A publicação é proativa e recorrente, mês a mês, dezenas de notas por vez, porque a ausência de incidente reportado nunca foi tratada, dentro do próprio ecossistema SAP, como prova de que nada precisa de atenção.

Esse é exatamente o raciocínio que falta na governança de regra fiscal customizada. A diferença central: as SAP Notes cobrem código e configuração padrão do próprio SAP, mantidos e monitorados centralmente pelo fornecedor. Regra fiscal customizada, parametrização manual e exceção criada internamente não recebem alerta de ninguém. Não existe uma "nota" que avise a um CIO que a exceção de ICMS criada em 2019 talvez já não reflita a operação de 2026. O ponto de atenção proativa que existe para o núcleo padrão não existe, por desenho, para o que foi customizado ou parametrizado por dentro da empresa: o fornecedor não tem como saber que uma condição de ICMS foi gravada para uma operação que mudou de escopo.

O que o mercado costuma fazer, e por que não resolve

A resposta mais comum a esse risco é reativa: revisar a regra fiscal quando ela gera um problema visível, uma autuação, uma divergência de fechamento, uma reclamação de auditoria externa. O raciocínio implícito é "se tivesse algo errado, o sistema já teria dado erro", e ele confunde falha técnica de execução com erro de mérito fiscal. Esperar o erro aparecer significa, na prática, esperar a autuação, o fechamento que não bate, ou a auditoria externa apontar o problema, porque nenhum desses eventos depende de o SAP travar antes.

Outra resposta comum é revisar regra fiscal apenas durante projetos formais, como uma migração para S/4HANA ou uma implementação de novo módulo. Isso resolve parte do problema, mas deixa uma lacuna estrutural: regras que não foram tocadas por nenhum projeto recente continuam fora de qualquer rito de revisão, indefinidamente, até que outro projeto as alcance ou até que um evento externo force a revisão. Anos podem se passar nesse intervalo, e a regra de ICMS de operação estadual segue calculando para uma empresa que hoje vende para doze estados.

Existe um jeito barato de achar as candidatas antes de qualquer auditoria formal, e ele não depende de ferramenta nova. Toda parametrização fiscal no SAP carrega quem gravou e quando: ordenar as entradas de Tax Code de FTXP e as condições mantidas pela J1BTAX pela data de última alteração devolve, em minutos, a lista do que não é tocado há mais tempo. Cruzar essa lista com os CFOP que mais aparecem no SPED Fiscal do último exercício separa o que está velho e parado do que está velho e rodando em volume. Velho e em volume é a interseção que interessa.

As quatro perguntas que testam se uma regra fiscal antiga já foi de fato revisada

Quatro perguntas separam "regra estável" de "regra revisada", e qualquer CIO consegue levá-las a um comitê sem auditoria completa antes.

1. Data da última revisão de mérito: quando foi a última vez que alguém comparou, formalmente, esta regra fiscal específica contra a legislação e a operação atuais, e não apenas confirmou que ela continua rodando sem erro técnico?

2. Dono nomeado: existe uma pessoa ou área formalmente responsável por revisar esta regra periodicamente, ou ela está ativa apenas porque nunca foi desligada?

3. Origem da regra: esta regra é configuração padrão do SAP, coberta pelo ciclo normal de manutenção do fornecedor, ou é customização/parametrização manual, que não recebe nenhum alerta automático de revisão?

4. Gatilho de mudança: existe algum mecanismo que force a revisão desta regra quando a operação muda (novo estado, novo produto, nova filial) ou a revisão só acontece se alguém, por acaso, lembrar de revisar?

CIO que responde as quatro perguntas com data, nome e mecanismo tem, com alta probabilidade, uma regra fiscal de fato revisada. CIO que responde "nunca deu erro" em qualquer uma delas está descrevendo estabilidade técnica, não correção fiscal, e as duas coisas continuam sendo diferentes.

O caminho quando o diagnóstico revela regra sem revisão de mérito

Quando esse padrão aparece num diagnóstico, o caminho não é presumir que a regra está errada, nem tratá-la como incidente de segurança. É trazer ao comitê, com dado concreto, quais regras fiscais críticas nunca passaram por uma revisão de mérito documentada, separando o que é configuração padrão do SAP (com ciclo de manutenção do fornecedor) do que é customização interna (sem esse ciclo automático). Um Diagnóstico Fiscal Estruturado, aplicado a esse cenário, tem como primeiro entregável exatamente esse mapa: quais regras nunca foram testadas contra o cenário atual, não apenas quais regras nunca deram erro.

Qual regra manter, ajustar ou substituir continua sendo decisão do cliente. O que vem antes dela é comportamento medido: reprocessar um período fechado com a regra atual e comparar o resultado por item, por Tax Code e por CFOP contra o que foi entregue no SPED Fiscal daquele mês. Onde bater, a regra está provada para aquele cenário. Onde não bater, existe uma diferença com data, valor e documento, que é material de decisão e não suspeita.

A pergunta que vale levar ao próximo comitê

O SAP audita execução, não audita mérito fiscal. A SAP publica, todo mês, dezenas de notas de segurança para o próprio núcleo do sistema, sem esperar ninguém reportar erro, porque ausência de incidente nunca foi tratada, ali dentro, como prova de que nada precisa de atenção. Regra fiscal customizada não tem esse alerta automático. A pergunta que vale levar ao próximo comitê é direta: quando foi a última vez que uma regra fiscal crítica da sua operação foi testada de propósito, e não apenas observada rodando sem falha? Se fizer sentido mapear isso com dado concreto antes da próxima decisão sobre o ambiente fiscal, estou disponível.