A nota fiscal que a Receita vai rejeitar em novembro não é a que tem erro no item

A partir de 3 de novembro de 2026, a nota pode ser recusada não pelo que está no item, mas pelo que está no cadastro de quem compra e de quem vende. A Nota Técnica 2026.007 v1.00 divulga novas regras de validação e atualiza regras existentes da NF-e e da NFC-e para verificação dos cadastros na Lista Centralizada de Contribuintes da RFB, a LCC-RFB, e no Cadastro Centralizado de Contribuintes, o CCC. O ambiente de teste abriu em 1º de setembro de 2026. A produção começa em 3 de novembro de 2026. A maioria dos times fiscais e de TI ainda trata isso como ajuste de leiaute. Não é. É validação de identidade de parceiro de negócio.

A reforma chegou ao cadastro mestre antes de chegar à alíquota.

O que a NT 2026.007 valida

Até aqui, a validação de uma NF-e concentrava a atenção no item: CFOP, NCM, CST, alíquota, valor. A NT 2026.007 desloca parte dessa atenção para antes do item, para a identidade das partes envolvidas na operação. A nota passa a ser cruzada contra a LCC-RFB e o CCC para confirmar se o CNPJ, a inscrição estadual e o regime declarado de emitente e destinatário realmente existem e estão coerentes naquelas bases centralizadas.

Isso significa que um cadastro de fornecedor ou de cliente desatualizado no SAP, um CNPJ correto mas com inscrição estadual errada, um regime tributário que mudou e não foi refletido no cadastro, passa a ter potencial de travar a nota antes mesmo de qualquer discussão sobre o conteúdo fiscal da operação em si.

Um dos trechos da própria nota técnica é direto quanto ao cronograma: a criação e a atualização de campos e de regras de validação dessa NT têm vigência estabelecida para 1º de setembro de 2026 em homologação e 3 de novembro de 2026 em produção. Não é um prazo flexível de adaptação gradual. É uma data de corte.

A nota não vai mais ser validada só pelo que ela diz. Vai ser validada por quem ela diz que são as partes.

Esse deslocamento de foco, do item para o cadastro, é consistente com o momento da Reforma Tributária: antes de operar o novo sistema de IBS e CBS em regime pleno, a Receita Federal está padronizando a camada de identificação de quem participa de cada operação.

Há ainda uma implicação pouco discutida: a regra não valida só o cadastro do parceiro em si, valida a coerência entre o que está no cadastro e o que está declarado como regime de tributação daquele parceiro nas bases da Receita. Duas empresas com CNPJ e inscrição estadual corretos, mas com o regime tributário desatualizado em uma das pontas, pela mudança recente de enquadramento de uma delas, podem gerar rejeição mesmo com os dados cadastrais aparentemente certos. A validação cruzada é mais fina do que uma simples conferência de existência de CNPJ.

Contribuinte exclusivo do IBS/CBS

Um dos pontos mais específicos da NT 2026.007 trata da figura do contribuinte exclusivo do IBS/CBS, um perfil de contribuinte que, pela lógica do novo sistema, deixa de depender de inscrição estadual da forma como o modelo de ICMS historicamente exigia. A nota técnica estabelece que, para a NFC-e, modelo 65, a ausência da inscrição estadual do emitente passa a ser rejeitada pela regra C17-42, mas a inscrição estadual informada e preenchida apenas com zeros permanece tratada de forma distinta.

Essa distinção é sutil e é exatamente o tipo de detalhe que separa um cadastro corretamente adaptado à transição de um cadastro que carrega um resquício do modelo antigo. Uma inscrição estadual zerada por convenção interna do SAP, usada historicamente como preenchimento padrão para contribuintes isentos, pode não ser interpretada pela nova regra da mesma forma que um campo deliberadamente vazio.

A inscrição estadual deixa de ser a regra única e universal de identificação fiscal do emitente. Ela passa a conviver com uma lógica de contribuinte exclusivo do regime novo, em que a ausência de IE pode ser esperada e válida, e não mais um sinal automático de cadastro incompleto.

Isso exige uma revisão de critério, não apenas de dado. O time que apenas verifica se o campo está preenchido, sem verificar se o preenchimento corresponde ao perfil correto do parceiro, segue vulnerável à rejeição mesmo depois de ter revisado o cadastro. Na prática, isso significa que a simples checagem de campo obrigatório preenchido, rotina comum de qualquer auditoria cadastral, deixa de ser suficiente: é preciso verificar também se o tipo de preenchimento condiz com o regime declarado daquele parceiro específico, o que exige cruzar o cadastro de parceiro de negócio com a tabela de regime tributário mantida no SAP, não apenas olhar o campo isoladamente.

Impacto na emissão e no recebimento

O efeito mais imediato e mais discutido dessa mudança é na emissão: uma nota de saída pode ser rejeitada pela SEFAZ se o cadastro do destinatário não bater com a LCC-RFB ou com o CCC. Isso já é suficientemente grave para travar uma operação de venda. Mas o efeito que menos aparece nas conversas sobre a NT 2026.007 é o do lado do recebimento.

Uma rede com centenas de fornecedores de mercadoria depende de um fluxo constante de notas de entrada, de fornecedor para centro de distribuição e de centro de distribuição para loja. Se a nota de um fornecedor é rejeitada porque o cadastro desse fornecedor no ambiente centralizado da Receita não confere com o que está parametrizado, o problema não é mais do emissor. É de quem recebe, porque a mercadoria física pode chegar e o documento fiscal correspondente não entrar no sistema.

Esse tipo de travamento tende a aparecer primeiro na doca do centro de distribuição, muito antes de virar alerta para o time fiscal. Quando a operação descobre o problema antes do fiscal, o tempo de resposta já está comprometido: alguém precisa identificar se é erro do fornecedor, do SAP, ou da própria base centralizada, e cada uma dessas três hipóteses tem um dono e um processo de correção diferente. Em uma rede que abastece múltiplas lojas a partir de um volume concentrado de centros de distribuição, uma falha recorrente de validação de cadastro de fornecedor tem potencial de se propagar rapidamente para a ponta, porque o estoque de reposição depende do fluxo contínuo de entrada.

Há também um efeito indireto sobre o Bloco K e sobre o controle de produção e estoque: se uma nota de entrada fica pendente de regularização por rejeição cadastral, o lançamento de movimentação de estoque correspondente pode ficar defasado em relação à mercadoria já fisicamente recebida, criando uma divergência entre o saldo físico e o saldo escriturado que só aparece quando alguém reconcilia os dois depois do fato.

Limpeza do cadastro mestre

A resposta a esse risco não é tecnológica, é de disciplina de dado. Primeiro, é preciso identificar, dentro do cadastro de parceiro de negócio do SAP, quais fornecedores e quais clientes têm CNPJ e inscrição estadual desatualizados ou divergentes do que está registrado nas bases oficiais mais recentes.

Segundo, separar os parceiros que são contribuintes exclusivos do regime de IBS/CBS dos que ainda operam sob a lógica tradicional de inscrição estadual, porque o critério de validação de cada grupo muda, e tratar os dois grupos com a mesma regra de preenchimento tende a gerar rejeição num dos lados.

Terceiro, revisar especificamente os cadastros com inscrição estadual preenchida com zeros, um padrão comum de parametrização legada, para confirmar se esse preenchimento ainda é interpretado corretamente pela nova regra de validação ou se precisa ser ajustado antes da virada.

Quarto, simular a emissão e o recebimento de notas com uma amostra representativa de parceiros, ainda em ambiente de homologação, para capturar rejeições reais antes que elas aconteçam em produção. Essa amostra precisa cobrir todos os perfis de cadastro em uso, contribuinte tradicional com inscrição estadual preenchida, contribuinte com inscrição zerada por convenção legada, e contribuinte exclusivo do IBS/CBS sem IE, porque testar só o perfil mais comum deixa justamente os casos de borda, que são os que mais rejeitam, de fora da validação.

Cadastro que nunca foi validado contra a base oficial não é cadastro correto. É cadastro que ainda não foi testado.

Quinto, estabelecer um processo recorrente de validação cadastral, não apenas uma correção pontual antes de 3 de novembro, porque fornecedores e clientes mudam de regime, de inscrição e até de razão social ao longo do tempo, e o cadastro no SAP tende a ficar desatualizado em relação a essas mudanças se não houver rotina de checagem. Sexto, documentar o critério usado em cada correção aplicada ao cadastro, porque uma auditoria futura, seja da própria empresa, seja de uma eventual fiscalização, vai precisar entender por que determinado parceiro foi classificado de uma forma e não de outra, e essa justificativa é mais difícil de reconstituir depois que a correção já foi feita sem registro.

O calendário que ninguém está olhando

A maior parte da atenção do mercado sobre a Reforma Tributária em 2026 está voltada para o calendário de alíquotas de teste de IBS e CBS, para a parametrização de tributação no SAP e para os projetos de Clean Core ligados à migração para S/4HANA. É um foco justificável, porque envolve volume financeiro direto.

Só que o calendário de validação cadastral da NT 2026.007 corre em paralelo, com uma data de produção que antecede qualquer prazo relevante de alíquota de teste de 2027. Isso significa que um time fiscal e de TI pode estar plenamente mobilizado para a parametrização de IBS/CBS e ser surpreendido por uma rejeição em massa de notas por cadastro, numa frente que não estava no radar do projeto principal.

Discordo de quem trata a limpeza de cadastro mestre como tarefa de baixa prioridade dentro de um projeto de reforma tributária.

É exatamente o tipo de ajuste estrutural, silencioso e sem visibilidade executiva imediata, que costuma ficar para o fim do cronograma, e que vira emergência quando a data de produção chega e ninguém testou a amostra real de parceiros contra a base centralizada. O risco de tratar esse ajuste como secundário cresce justamente porque ele não aparece em nenhum indicador de projeto de parametrização tributária: não há Tax Code novo para configurar, não há tabela de alíquota para revisar, é apenas cadastro, e cadastro raramente ganha prioridade de sprint quando compete com entregas de maior visibilidade.

A pergunta do cadastro validado

A pergunta executiva que resume essa mudança é objetiva: quantos cadastros de fornecedor e de cliente do SAP já foram validados contra o cadastro centralizado da Receita Federal? Se a resposta é um número concreto, com evidência de teste em homologação, a empresa está numa posição de controle sobre o risco de rejeição em produção. Se a resposta é incerta, a empresa está apostando que o cadastro atual vai se comportar bem numa validação que nunca foi de fato simulada.

A decisão sobre como priorizar a correção de cada cadastro, por volume de operação, por criticidade de fornecedor ou por proximidade da data de produção, é do cliente e do time responsável pelo cadastro mestre. O papel de quem trabalha a parametrização fiscal no SAP é outro: extrair a base completa de parceiros de negócio, cruzar contra as regras da NT 2026.007 e produzir uma lista objetiva e priorizada de divergências antes que o prazo de 3 de novembro chegue.

Na DFSpro, trabalhamos o cadastro mestre de parceiros de negócio, as validações de NF-e e NFC-e, e a parametrização fiscal no SAP como parte central da nossa atuação. O Diagnóstico Fiscal SAP avalia uma amostra do cadastro de fornecedores e clientes contra as regras da Lista Centralizada de Contribuintes e do Cadastro Centralizado de Contribuintes, e entrega uma lista de correções priorizadas antes que a validação em produção comece a rejeitar notas na emissão e no recebimento.