Em 2026 a reforma entra em fase de teste: CBS e IBS aparecem destacados nos documentos fiscais, com alíquotas simbólicas, e não são recolhidos. O ano é informativo.

Isso soa como folga, e é o contrário. O que a empresa declara sem pagar é exatamente o que fica registrado sem o filtro de quem confere um valor a receber. É o material que vai ser lido depois — quando a discussão não for mais sobre teste.

E “depois” aqui não é figura de linguagem. Uma divergência sobre um documento de 2026 pode ser julgada em 2031, com o processo tramitando anos. A pergunta que chega nessa data não é qual é a regra hoje. É: o que o seu sistema aplicou naquele dia, e por quê?

A prova exige três coisas, e ninguém guarda as três juntas

Para demonstrar como um número saiu, é preciso ter, ao mesmo tempo:

O documento. Esse todo mundo guarda. É a parte fácil, e é a que dá falsa sensação de cobertura.

A regra vigente naquela data. Essa mora fora do sistema — em legislação, em nota técnica, em entendimento do time fiscal. Raramente há um vínculo entre “este documento” e “a versão da regra que valia quando ele foi emitido”.

A versão do parâmetro que produziu o número. Essa é a que se perde. Tabela de alíquota, regra de decisão, código próprio, motor fiscal externo — tudo isso muda ao longo dos anos, e boa parte muda por cima, sem deixar o estado anterior.

Guardar o documento sem os outros dois permite mostrar o resultado. Não permite mostrar a derivação — e é a derivação que se discute num contencioso.

A armadilha do parâmetro sobrescrito

Sistemas fiscais costumam ter validade por data nas tabelas de alíquota — e isso cria a impressão de que o histórico está resolvido. Não está, porque o cálculo raramente sai só delas.

Ele passa também por regras de decisão, por código próprio escrito para tratar exceção do negócio, por cadastro — a classificação do produto, o regime do cliente, a natureza da operação — e, em muitas empresas, por um motor fiscal externo com base de conhecimento própria, atualizada pelo fornecedor.

Nenhuma dessas camadas guarda versão por padrão. O resultado prático é conhecido: você consegue reproduzir o cálculo de hoje, e não o de dois anos atrás. Quando alguém pergunta por que aquele item foi tributado daquele jeito em 2026, a resposta honesta costuma ser “porque o sistema estava configurado assim” — e isso não é uma resposta.

Vale lembrar que a origem do número, em volume, quase nunca é o cálculo: é o cadastro. Um erro de classificação se repete em todos os documentos daquele produto, silenciosamente, até a apuração — é o mecanismo descrito em NCM errado no cadastro de produto.

A convivência dobra tudo, e por vários anos

Até a extinção completa do sistema antigo, os dois regimes coexistem. Na prática, para a TI, isso significa três coisas que se acumulam:

Cada documento carrega as duas apurações. O que já era complexo passa a existir em duas versões simultâneas, com regras que evoluem em ritmos diferentes.

Cada mudança precisa ter data. Não basta alterar: é preciso saber a partir de quando aquilo passou a valer, e o que valia antes. Mudança sem data é histórico perdido.

A janela de retenção passa a ser maior que a vida do sistema. O ambiente que fez a conta pode ter sido atualizado, migrado ou substituído antes da discussão chegar. É por isso que arquivamento com regra de retenção deixa de ser assunto de espaço em disco e vira requisito de defesa — tratamos disso em archiving SAP.

O que dá errado, com nome

Apagar o legado cedo demais. É a tentação depois de uma migração bem-sucedida: o ambiente antigo custa caro e ninguém usa. Ele deixa de ser sistema e passa a ser prova — e o prazo dele não é o do projeto.

Migrar sem trazer o histórico calculável. Trazer os documentos é o mínimo. Se a nova plataforma não consegue reconstruir como o número saiu no ambiente anterior, o histórico virou arquivo morto legível, não evidência.

Tratar o print como prova. Uma imagem de tela mostra o resultado e não sustenta pergunta nenhuma sobre derivação.

Achar que o arquivo do documento basta. Ele registra o que foi declarado, não como se chegou lá. É o resultado, não o caminho.

Deixar o código próprio sem versionamento. É a camada mais frequentemente esquecida e a que mais decide o número em empresas com operação específica.

O que isso não é

Vale ser explícito: nada aqui é orientação tributária. A leitura da regra, o enquadramento e a estratégia de defesa são do time fiscal e do jurídico, e é lá que essa conversa começa.

O trabalho de TI é outro, e é complementar: garantir que o sistema consiga demonstrar o que fez. Quando o fiscal precisar sustentar um entendimento, ele vai precisar da evidência — e ela ou existe desde a emissão, ou não é fabricada depois.

O limite honesto

Conseguir provar o cálculo não ganha a discussão. Ganha a possibilidade de ter a discussão com dado em vez de com memória — o que é diferente, e é bem menos do que gostaríamos de prometer.

Também não é de graça. Versionar parâmetro, datar mudança e reter ambiente com regra tem custo de disco, de licença e de disciplina, e esse custo aparece antes do benefício — que pode nunca ser cobrado, se a discussão não vier. É uma apólice, e apólice se avalia pelo tamanho do risco, não pelo prêmio.

E há um limite de alcance: isso trata do que a empresa consegue mostrar. Não corrige o que foi calculado errado. Se o cadastro estava errado, guardar bem a evidência apenas documenta melhor o erro — por isso a ordem é achar primeiro, guardar depois.

Se o ponto de partida é entender o que o ambiente faz hoje antes de mudar qualquer coisa nele, comece pelo diagnóstico de TI. Para o panorama do que a reforma exige da TI, veja Reforma Tributária e SAP. E se a emissão ainda depende da plataforma antiga, o caminho é a migração do SAP NFE para o DRC.

Perguntas frequentes