A nota autorizada pela Sefaz não prova que o campo de IBS e CBS está certo

A Sefaz autoriza o XML. Ela não audita a classificação tributária que o SAP aplicou para chegar àquele valor de IBS e CBS. Desde 3 de agosto de 2026, o Ato Conjunto RFB/CGIBS nº 4 tornou obrigatório emitir NF-e modelo 55, CT-e e MDF-e com os campos da Reforma preenchidos. A obrigatoriedade virou rotina rápido: o emissor passou a exigir o campo, o sistema passou a mandar algum valor, e a nota saiu autorizada. O problema é que autorização de leiaute e correção de conteúdo são coisas diferentes, e a diferença entre elas é exatamente onde mora o risco que ninguém está medindo ainda.

O que mudou em agosto, e o que ainda não muda

O Ato Conjunto nº 4, de 30 de julho de 2026, fixou datas específicas por documento: NF-e modelo 55 a partir de 3 de agosto de 2026, com CT-e e MDF-e na sequência. A regra vale para os fatos geradores ocorridos a partir dessas datas, não para um prazo de adequação futuro. Antes disso, o Ato Conjunto RFB/CGIBS nº 1, de 22 de dezembro de 2025, havia estabelecido que não haveria aplicação de penalidades pela falta de registro dos campos do IBS e da CBS nos documentos fiscais. Essa tolerância tinha prazo e finalidade claros: dar tempo para o emissor se ajustar, não para discutir se o conteúdo estava certo.

A leitura de calendário mais direta é que o fim da tolerância do Ato nº 1 coincide com o início da obrigatoriedade do Ato nº 4 em agosto. Essa conexão de datas é inferência, não texto literal de nenhum dos dois atos, e vale registrar isso antes de qualquer decisão. O que é fato, e está no texto: a partir de 3 de agosto o campo é exigido. Monofásico, importação e NFS-e seguem cronogramas próprios, fora do escopo que entrou em agosto, e tratar os dois calendários como um só é o primeiro erro de leitura que vejo repetir.

Três documentos entraram na mesma obrigação, com três pontos de falha diferentes. Isso muda o escopo do projeto de três formas distintas, não de uma só vez.

A NF-e nasce no ERP, no módulo de vendas ou faturamento, e a regra de IBS e CBS depende da determinação de imposto configurada ali. O CT-e nasce num processo de transporte que, em operações com frota própria ou terceirizada em múltiplas praças, pode rodar em sistema diferente do ERP principal, integrado por interface, não por módulo nativo. O MDF-e consolida o manifesto de carga e herda o que já veio preenchido nos documentos de origem, então um erro de classificação no CT-e se propaga para o MDF-e sem nova chance de correção. Quem trata os três documentos como uma obrigação única, resolvida de uma vez no ERP, deixa sem teste exatamente o ponto onde a integração entre sistemas é mais frágil.

Por que a versão da nota técnica pesa mais que a data

Em 5 de outubro de 2026 o Portal da NF-e adiou a próxima versão da NT 2025.002, empurrando homologação para 26 de outubro e produção para 16 de novembro. Isso significa que, entre agosto e novembro, o SAP está rodando sob uma versão de nota técnica que vai mudar de novo antes do fim do ano. Cada nova versão redefine regra de validação, tamanho de campo, domínio de valor aceito. O emissor que não sabe qual versão está rodando em cada ambiente corre o risco de aprovar hoje um comportamento que a próxima NT vai rejeitar.

A pergunta que normalmente ninguém no comitê de fiscal e TI consegue responder de cabeça é simples: qual versão da NT 2025.002 cada ambiente de emissão está usando agora. Produção, homologação, contingência, cada planta pode estar em versão diferente se a atualização não foi coordenada. O padrão que costuma aparecer em operações com múltiplos emissores e múltiplas unidades de negócio é a atualização da NT chegar em ondas, não de uma vez, o que cria uma janela em que parte da operação já está na regra nova e parte ainda está na antiga, emitindo com critério diferente para a mesma obrigação.

Duas plantas. Duas versões de NT rodando ao mesmo tempo. Nenhuma nota rejeitada.

É esse o detalhe que engana: o Sedex schema aceita as duas versões durante o período de convivência entre NTs, então a divergência nunca aparece como erro de transmissão. Ela só aparece quando alguém compara, campo a campo, o que a planta A preencheu contra o que a planta B preencheu para o mesmo tipo de operação, na mesma data. Sem esse comparativo, a empresa inteira opera sob a ilusão de uma regra única, quando na prática roda duas, e nenhuma auditoria interna nasce para procurar esse tipo de divergência porque ela parte do pressuposto de que o ambiente é uniforme.

Onde o SAP erra sem dar erro

O SAP valida estrutura: campo obrigatório preenchido, formato correto, schema aceito pela Sefaz. O que o SAP não valida sozinho é se a classificação tributária escolhida para aquele CFOP, aquele CST, aquela operação específica está certa para o regime de IBS e CBS que incide ali. A determinação de imposto roda a regra que foi parametrizada. Se a regra foi parametrizada de forma genérica, cobrindo a operação mais comum e empurrando o resto para um valor padrão, a nota sai, é autorizada, e o erro fica invisível até alguém cruzar dado.

Isso é especialmente sensível quando a mesma empresa opera verticais diferentes sob o mesmo mandante SAP: cada vertical tem regra de CFOP, CST e classificação de CBS e IBS própria, e um motor fiscal pensado para a operação principal tende a tratar as demais como exceção manual. O padrão que tende a se repetir em cadeias com múltiplas verticais operando no mesmo ambiente SAP é a classificação de IBS e CBS ficar correta na vertical que originou a parametrização e genérica nas demais, porque ninguém testou, item por item, se a regra configurada para a operação principal se aplica sem ajuste às outras.

A causa raiz raramente está na tabela fiscal em si. Está em quem validou a parametrização e em que momento do projeto essa validação aconteceu. Quando a determinação de imposto é configurada sob pressão de cronograma de go-live, o time tende a testar os cenários de maior volume e assumir que os cenários residuais, por serem minoritários, vão se ajustar sozinhos depois. Eles não se ajustam. Ficam como estão até alguém precisar explicar por que uma vertical inteira emitiu meses de notas com o mesmo critério genérico, e essa explicação custa muito mais perto da fiscalização do que custaria perto do go-live.

A autorização da Sefaz não é prova de conformidade

Vale separar dois eventos que o time operacional costuma tratar como um só. A autorização da Sefaz confirma que o XML chegou, está bem formado e passou nas validações de schema daquela versão de NT. Isso não confirma que o CST aplicado está correto para aquela operação, nem que a classificação de IBS e CBS reflete o enquadramento tributário real do item. São camadas diferentes de verificação, e só a primeira acontece em tempo real, no momento da emissão.

A segunda camada, a que realmente importa, só aparece depois: no cruzamento de dados que a Receita e o Comitê Gestor de IBS fazem entre o que foi declarado e o padrão esperado para aquele tipo de operação e aquele contribuinte. É nesse cruzamento que o campo preenchido de forma genérica, mas tecnicamente válido, se transforma em inconsistência fiscal. O tempo entre a emissão autorizada e a detecção do erro pode ser de meses, e nesse intervalo o volume de notas emitidas com o mesmo defeito só cresce.

Quanto mais tempo passa entre a emissão e a correção, maior o lote de notas que precisa ser retificado ou justificado depois, e retificação em massa custa mais do que ajuste pontual feito a tempo.

"A obrigatoriedade de emissão dos documentos fiscais eletrônicos de que trata o art. 112 dos regulamentos do IBS e da CBS iniciar-se-á em relação aos fatos geradores que vierem a ocorrer a partir das seguintes datas: NF-e, modelo 55: 3 de agosto de 2026." Ato Conjunto RFB/CGIBS nº 4, de 30 de julho de 2026.

Como provar por amostra que o preenchimento está certo

A forma prática de reduzir essa incerteza não é revisar nota a nota, é desenhar uma amostra que cubra o que varia: cada CFOP relevante, cada CST em uso, cada vertical de operação, e confrontar o campo de IBS e CBS emitido com o que a NT vigente exige para aquele cenário. Uma amostra bem desenhada por operação expõe em horas o que uma auditoria completa levaria semanas para encontrar, porque o objetivo não é ver tudo, é ver o suficiente de cada combinação de regra para provar se o padrão se mantém.

O critério de prioridade nessa amostragem deveria ser o risco por vertical, não o volume de notas. Uma vertical de menor volume, mas com regra de classificação mais específica, pode concentrar mais risco por nota do que a vertical principal, que já recebeu atenção quando o motor fiscal foi parametrizado. Separar a amostra por esse critério, em vez de por quantidade de documentos emitidos, é o que transforma o teste em evidência defensável diante do comitê, em vez de em uma lista de notas revisadas sem critério declarado.

Na prática, a amostra tem três camadas de corte. A primeira separa por documento (NF-e, CT-e, MDF-e), porque cada um tem ponto de origem e ponto de falha diferentes, como já descrito. A segunda separa por vertical de operação dentro de cada documento, porque é ali que a parametrização genérica se esconde. A terceira separa por período, contrastando notas emitidas logo após 3 de agosto com notas emitidas mais recentes, porque isso revela se algum ajuste de parametrização ocorreu no meio do caminho e, se ocorreu, se foi aplicado retroativamente ou só dali para frente. Sem essa terceira camada, é comum concluir que o problema foi corrigido quando, na verdade, só parou de acontecer nas notas novas, deixando as antigas sem retificação.

O que levar ao comitê de fiscal e TI antes de novembro

A janela entre agora e 16 de novembro, quando a versão seguinte da NT 2025.002 entra em produção, é o espaço real de manobra. Depois dessa data, qualquer ajuste de parametrização concorre com a adaptação à nova versão, e os dois trabalhos competem pela mesma equipe fiscal e de TI. O comitê que trata isso como duas pautas separadas, em vez de uma só, perde a janela de testar a regra atual com calma antes de precisar reabrir o mesmo código para a próxima mudança.

Três perguntas sustentam essa pauta: qual versão da NT 2025.002 cada ambiente de emissão está rodando hoje, quantas notas desde agosto foram emitidas com classificação de IBS e CBS derivada de regra genérica em vez de regra específica por operação, e quem no time fiscal consegue hoje provar a resposta às duas primeiras sem levantar manualmente cada nota. A terceira pergunta costuma ser a mais reveladora, porque mostra se a resposta depende de uma pessoa específica ou de um processo que sobrevive à ausência dela.

Um comitê que chega a novembro sem essas três respostas prontas vai decidir sob pressão dupla: a nova NT e o passivo acumulado desde agosto, ao mesmo tempo.

O erro mais comum nesse tipo de pauta é tratá-la como item de TI, delegado ao time de desenvolvimento ABAP, sem presença do fiscal na mesa de decisão. TI resolve o que é mapeável tecnicamente, campo por campo, mas não decide qual CST corresponde a qual enquadramento tributário, isso é critério fiscal, não parametrização de sistema. Quando o fiscal só entra depois que TI já implementou uma regra, o que se corrige é o sintoma técnico, não o critério de origem, e o erro de classificação volta na próxima atualização de cadastro de material ou cliente.

Na DFSpro, o Diagnóstico Fiscal Estruturado nasceu exatamente para essa situação: uma amostra de documentos emitidos desde agosto confrontada com a NT vigente, com priorização de risco por vertical de operação, sem tocar na decisão tributária, que continua sendo do cliente. O trabalho é provar como o SAP se comportou, não decidir como ele deveria se comportar. Quando a próxima versão da NT chegar em novembro, o AMS Fiscal absorve a mudança de leiaute sem reabrir a parametrização do zero. A pergunta que fica para quem lê isso é direta: hoje, sem levantar nenhuma nota manualmente, alguém no seu comitê sabe responder às três perguntas acima?