As 28 regras estão em produção: as rejeições que aparecem primeiro e como ler cada família
What changed
As 28 regras de validação remanejadas pela versão 1.51 da NT 2025.002-RTC saíram da homologação e entraram em produção em 5 de outubro de 2026. A partir dessa data, a regra que antes avisava passa a barrar a autorização da nota.
Who is affected
Software houses e empresas que emitem NF-e modelo 55 e NFC-e modelo 65 no regime normal, e os times fiscais que dependem desses sistemas para faturar.
When it takes effect
05/10/2026, em produção
Em homologação, regra nova é aviso. Em produção, é nota que não sai. Mudou o que está em jogo, e não o texto da norma.
O que você vai entender:
- O que muda de fato quando uma regra sai da homologação
- As quatro famílias, e qual delas quebra integração que já funcionava
- Como ir do código de rejeição até o campo, sem abrir o manual inteiro
- O que não entrou em 5 de outubro, para desfazer a confusão que circula
- O que testar agora, e o que já não dá para testar
1. O que muda quando a regra sai da homologação
O texto da norma é o mesmo desde julho. O que mudou em 5 de outubro foi o preço de errar.
Em homologação, a regra roda contra notas de teste. Quem acertou, acertou; quem errou, descobriu sem prejuízo. Em produção, a mesma regra roda contra a nota que precisa sair para o cliente receber a mercadoria.
Isso reposiciona o trabalho. Até ontem a pergunta era se a integração estava aderente. A partir de hoje a pergunta é qual rejeição aparece primeiro, e quanto tempo a equipe leva do código até o campo.
A lista completa das 28, com o que cada uma passa a exigir, está em NT 2025.002-RTC: as 28 regras que entram em produção em 5 de outubro. Aqui o assunto é outro: como usar essa lista quando a rejeição chega.
2. O código não é aleatório, e isso encurta a investigação
A primeira coisa útil sobre uma rejeição é que ela tem endereço. O identificador da regra aponta para o grupo do leiaute em que ela mora.
A versão 1.51 mexe em quatro grupos, e cada um tem um assunto:
| Grupo | O que ele guarda |
|---|---|
| UB | IBS, CBS e Imposto Seletivo |
| VC | Referenciamento de item de outro documento |
| B25 | Identificação da nota |
| I08 | CFOP de devolução |
Quem lê o identificador antes de ler a mensagem já sabe onde procurar. Regra que começa por UB é assunto de tributo, e regra que começa por VC é assunto de referência entre documentos. São investigações diferentes, com times diferentes.
É uma economia pequena por ocorrência e grande no mês. A rejeição chega para quem está faturando, e não para quem escreveu a integração.
3. Devoluções: a família que quebra o que já funcionava
Se houver uma só para olhar hoje, é esta. As outras três criam exigência nova em operação específica. Esta muda o lugar de onde a informação sai, e por isso atinge integração que vinha funcionando sem reclamação.
A regra VC02-14 manda informar o documento referenciado no nível do item, na tag DFeReferenciado, e não mais no cabeçalho. A observação da própria regra é explícita: fica proibido usar a tag refNFe na devolução. Quem não referenciar por item recebe a rejeição 321.
A VC02-30 fecha pelo outro lado. Um único documento deve ser referenciado, e informar chaves diferentes gera a rejeição 1130. Há duas exceções, as duas de nota de débito.
Juntas, as duas mudam o desenho. A devolução deixa de ser uma nota que aponta para outra e passa a ser uma nota cujos itens apontam, cada um, para o item de origem. Quem monta a devolução no cabeçalho precisa de reforma, não de ajuste.
As outras duas regras da família tratam do retorno por recusa parcial na entrega, um tipo de nota de crédito criado em versão anterior. Elas estendem a esse caso o tratamento de CFOP de devolução.
4. As outras três famílias, e o que cada uma cobra
As três restantes são mais fáceis de prever, porque cada uma tem gatilho claro.
Compras governamentais
A mudança é silenciosa porque cria obrigação onde antes havia permissão. Informar o grupo de compra governamental passa a obrigar o grupo de redução de alíquota, nas três esferas. São três regras, uma por esfera, com rejeições próprias.
O gatilho é o preenchimento do grupo. Quem nunca informa compra governamental não é atingido. Quem informa e não reduz recebe a rejeição.
Alíquota amarrada ao ano
A validação passa a conferir o percentual contra o ano de emissão da nota. É a família que mais depende de parametrização correta e menos depende de código: quem mantém a tabela de alíquotas atualizada não vê essas regras.
O risco aqui é de fim de ano. Nota emitida em janeiro com tabela de dezembro é exatamente o caso que a regra existe para pegar.
Coerência entre o CST e o grupo
A validação usa a tabela de indicadores para decidir o que pode conviver com o quê. A nota informa um CST, e a tabela diz quais grupos aquele CST admite.
Aqui aparece uma divisão de responsabilidade que costuma doer. Quem escolhe o CST é o parametrizador tributário, normalmente no ERP. Quem recebe a rejeição é o emissor. Deixar a tabela só no emissor produz nota que o ERP considera certa e a SEFAZ recusa.
5. O que não entrou em 5 de outubro
Esta seção existe porque a confusão circula, e ela custa caro nos dois sentidos.
A regra que rejeitaria a nota pela ausência dos campos de IBS e CBS, a UB12-10, não entrou. Ela consta como implementação futura nas duas colunas do quadro da própria nota técnica, homologação e produção, e não tem data.
Disso não decorre que preencher virou opcional. O preenchimento é obrigatório desde 3 de agosto para o regime regular. O que não existe é a barreira técnica que impediria a emissão de quem não preenche. São camadas distintas, e uma nota de rodapé da própria norma as separa.
A outra confusão é de versão. A v1.50 reformulou o leiaute da tributação monofásica de combustíveis, e o cronograma dela é separado: produção em 3 de novembro de 2026. Quem é do setor tem uma data a mais para olhar, e ela não é hoje.
6. O que dá para fazer agora
Homologação segue aberta, e é o melhor lugar para descobrir o que falta. Quatro movimentos, na ordem em que rendem mais.
- Emitir em homologação uma devolução com item referenciado e outra sem, e comparar os retornos. É o teste que separa integração adaptada de integração que só parece.
- Listar as operações da empresa que informam o grupo de compra governamental, e conferir se todas levam o grupo de redução de alíquota.
- Conferir onde mora a tabela de indicadores do CST, e se o ERP e o emissor consultam a mesma. Duas cópias divergentes é o caso que gera rejeição intermitente.
- Separar quem responde por cada família. Devolução é integração, alíquota é parametrização, e CST é tributário. Rejeição que chega sem dono espera na fila.
7. Perguntas frequentes
Emito apenas NFC-e. Quantas dessas regras me atingem?
A maior parte. Das 28, 21 valem para os dois modelos, 55 e 65. As 7 restantes são exclusivas do modelo 55, e a própria nota técnica as marca assim. São elas: as duas de referenciamento em devolução, as duas de CFOP, a de composição do valor em compra governamental, a de crédito presumido de IBS na Zona Franca e a B25-80.
Minha integração está aderente à 1.50. Preciso migrar leiaute?
Não. A 1.51 não cria campo, não altera a estrutura do XML, não modifica schema e não inclui grupo novo. Ela remaneja regras de validação dentro de grupos que já existem. O trabalho é de conferir comportamento, e não de refazer estrutura.
A tabela de indicadores do CST é responsabilidade do ERP ou do emissor?
A norma não divide papéis, ela só diz que a validação usa a tabela. Na prática quem escolhe o CST é o parametrizador tributário, quase sempre no ERP, e quem sofre a rejeição é o emissor. O desenho que funciona é uma fonte só, consultada pelos dois.
Recebi uma rejeição e o código não está na lista das 28. O que houve?
Provavelmente é regra que já existia antes da 1.51. As 28 são as que essa versão remanejou, e não o conjunto inteiro de validações da nota. O ponto de partida nesse caso é a tabela de status do Manual de Orientação ao Contribuinte, que cobre todos os códigos.
Quando sai a próxima versão da nota técnica?
Não há data anunciada, e a frequência recente sugere que virá. A nota técnica passou de dez versões em dezoito meses. O que protege a operação não é adivinhar a próxima: é ter a validação como dado atualizável, e não como código espalhado.
Migrate ao seu lado a cada versão
Nota técnica que muda dez vezes em dezoito meses é a rotina de quem emite documento fiscal eletrônico, e não a exceção. O que separa a operação tranquila da operação em pânico é onde a regra de validação mora: em dado que se atualiza, ou em código que se reescreve.
A Migrate vive de documento fiscal eletrônico há mais de 20 anos, em cinco países, e participa do projeto piloto da apuração assistida do IBS. É do documento fiscal que nasce cada linha da apuração dos novos tributos.
Se a sua equipe está dimensionando o trabalho da próxima versão, vale conversar agora.
Referências
BRASIL. Receita Federal e Comitê Gestor do IBS. Nota Técnica 2025.002-RTC, Reforma Tributária do Consumo, Adequações NF-e e NFC-e, versão 1.51, de julho de 2026. Disponível no Portal Nacional da NF-e, aba Documentos, opção Notas Técnicas.
BRASIL. Receita Federal e Comitê Gestor do IBS. Ato Técnico Conjunto RFB/CGIBS nº 1, de 31 de julho de 2026, que aprova a versão 1.51 da Nota Técnica 2025.002-RTC. Portal do CGIBS. https://www.cgibs.gov.br/upload/arquivos/202608/01153321-am-ato-tecnico-conjunto-rfb-e-cgibs-ratificacao-nts-dfes-revisao-assinado.pdf
BRASIL. Portal Nacional da NF-e. Manual de Orientação ao Contribuinte, versão 7.0, tabela de códigos de status e mensagens de rejeição. https://www.nfe.fazenda.gov.br/portal/principal.aspx
BRASIL. Lei Complementar nº 214, de 16 de janeiro de 2025. Planalto. https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp214.htm
Migrate Newsletter
The right information. At the right time!
Get relevant tax content and updates straight to your inbox.