Novo layout fiscal da NF-e em 2026: IBS, CBS, CNPJ alfanumérico e regras atuais

O novo layout fiscal da NF-e e da NFC-e em 2026 não é uma única mudança isolada. Ele resulta de uma sequência de Notas Técnicas, ajustes de schema, novas tabelas, regras de validação e adequações decorrentes da Reforma Tributária do Consumo, do CNPJ alfanumérico e de alterações operacionais nos documentos fiscais eletrônicos.

Para empresas, desenvolvedores de ERP, faturistas e analistas fiscais, o principal cuidado é não tratar “novo layout” como um pacote fechado e estático. Em 2026, o ambiente da NF-e continua recebendo versões sucessivas de documentos técnicos. A referência correta deve ser sempre a versão vigente publicada no Portal Nacional da NF-e, com atenção especial à Nota Técnica 2025.002, às alterações posteriores de validação e às notas específicas de 2026.

Resumo executivo

O que significa “novo layout fiscal” em 2026

Em termos práticos, “novo layout fiscal” significa a atualização da estrutura dos documentos fiscais eletrônicos e de suas regras de validação. Isso envolve:

• novos campos no XML;
• alterações em grupos já existentes;
• novos códigos e tabelas;
• novas regras de validação;
• mudanças de schema;
• novos eventos;
• adequações no DANFE;
• novas regras para contribuintes e operações específicas.

Essas mudanças não entram todas em vigor no mesmo dia. Cada Nota Técnica pode possuir cronograma próprio de homologação e produção. Por isso, o ERP deve controlar versão do schema, ambiente, data de vigência e regra aplicável.

Nota Técnica 2025.002: eixo das mudanças da Reforma Tributária

A Nota Técnica 2025.002 é o principal documento técnico de adequação dos leiautes da NF-e e da NFC-e para a Reforma Tributária do Consumo. Ela introduz campos e regras de validação relacionados ao IBS e à CBS e vem recebendo revisões sucessivas.

Em 4 de agosto de 2026, o Portal Nacional da NF-e publicou a versão 1.51 da NT 2025.002, com alterações em regras de validação. Isso demonstra por que empresas e fornecedores de sistemas não podem congelar a implementação em uma versão antiga da nota técnica.

Antes de qualquer alteração no ERP, confirme sempre a versão vigente no Portal Nacional da NF-e — Notas Técnicas.

IBS e CBS no XML da NF-e

A Reforma Tributária criou uma nova camada de informações tributárias que precisa coexistir, durante a transição, com os tributos do regime atual. O XML da NF-e passa a suportar grupos e campos específicos relacionados ao IBS e à CBS, conforme a versão vigente da Nota Técnica e as tabelas oficiais.

É essencial separar:

• regime atual: ICMS, ICMS-ST, IPI, PIS e COFINS continuam sujeitos às regras próprias enquanto vigentes;
• transição: IBS, CBS e Imposto Seletivo seguem cronogramas, documentos técnicos e legislação próprios.

Não se deve substituir automaticamente ICMS/PIS/COFINS por IBS/CBS no cadastro fiscal apenas porque o novo leiaute já possui campos para os novos tributos.

Tabelas de classificação tributária

Uma parte importante da implementação depende de tabelas oficiais. O Portal da NF-e publicou em 2026, entre outras, tabela de Classificação Tributária do IBS e CBS (cClassTrib), códigos de crédito presumido e tabela de alíquotas da CBS.

O ERP deve consumir e versionar essas tabelas com controle de vigência. Não é seguro criar códigos internos “equivalentes” sem correspondência com a tabela oficial, porque regras de validação podem depender diretamente desses códigos.

Nota Técnica 2026.007: contribuinte exclusivo do IBS/CBS

Em agosto de 2026 foi publicada a Nota Técnica 2026.007 v.1.00, que trata da criação de campos e regras de validação para emissão de NF-e por contribuinte exclusivo do IBS/CBS.

Esse tipo de mudança reforça que o novo layout fiscal não deve ser entendido apenas como “mais campos no XML”. Também existem regras de enquadramento, validações e cenários específicos por tipo de contribuinte.

CNPJ alfanumérico e Nota Técnica 2026.004

Outra mudança relevante de 2026 é a adequação da NF-e e NFC-e ao CNPJ alfanumérico. A Nota Técnica 2026.004 atualizou o schema dos documentos e regras relacionadas para permitir o novo formato.

O impacto atinge sistemas que:

• validam CNPJ apenas como número;
• armazenam identificadores em campos numéricos;
• aplicam máscaras fixas;
• fazem integrações com bancos de dados legados;
• geram XML ou DANFE;
• validam cadastros por expressão regular antiga.

A adaptação precisa ocorrer em toda a cadeia de dados. Corrigir apenas a tela de cadastro sem ajustar banco, API, XML e validações internas pode gerar falhas posteriores.

Schema XML: o que a empresa precisa controlar

O schema define a estrutura técnica aceita pelo autorizador. Em cada atualização, o fornecedor do ERP deve verificar:

• versão do XSD;
• novos elementos;
• campos obrigatórios, opcionais e condicionais;
• tipos e tamanhos de dados;
• ordem dos elementos;
• domínios e tabelas;
• dependências entre campos;
• regras de validação vinculadas ao preenchimento.

Um XML pode falhar antes mesmo da análise fiscal se não respeitar o schema. Mas o inverso também é verdadeiro: passar no XSD não prova que a tributação está correta.

Regras de validação

As regras de validação são tão importantes quanto o schema. Elas podem rejeitar documentos quando uma combinação de campos não atende às condições oficiais.

Em 2026, diversas versões de Notas Técnicas foram publicadas justamente para ajustar validações. A equipe de implantação precisa controlar:

• código da rejeição;
• condição que dispara a regra;
• modelo do documento;
• tipo de operação;
• UF e ambiente;
• data de ativação;
• eventuais exceções;
• versão da Nota Técnica.

Homologação e produção

Uma mudança de leiaute normalmente passa por ambiente de homologação antes de produção. As datas precisam ser acompanhadas na documentação oficial porque podem ser alteradas.

O fluxo recomendado é:

1. identificar a Nota Técnica aplicável;
2. mapear campos e regras;
3. atualizar banco de dados e integrações;
4. implementar schema e validações;
5. testar em homologação;
6. comparar XML gerado com exemplos e schemas oficiais;
7. simular cenários tributários;
8. liberar produção somente após validação técnica e fiscal.

Como o novo layout afeta o ERP

O ERP precisa ser tratado como sistema fiscal integrado, não apenas emissor de XML. Mudanças podem afetar:

• cadastro de produtos;
• cadastro de clientes e fornecedores;
• motor tributário;
• regras por UF;
• classificação tributária;
• tabelas de IBS e CBS;
• emissão de NF-e e NFC-e;
• cálculo de tributos;
• integrações com e-commerce e marketplaces;
• API fiscal;
• impressão de DANFE;
• armazenamento do XML;
• SPED e demais obrigações acessórias;
• contabilidade e financeiro.

XML da NF-e: o que conferir

No XML da NF-e, a empresa deve conferir não apenas se o arquivo foi autorizado, mas se os grupos e valores refletem corretamente a operação.

Entre os pontos de auditoria estão:

• emitente e destinatário;
• CNPJ e identificadores;
• NCM e dados do produto;
• CFOP;
• CST ou CSOSN;
• ICMS e ICMS-ST;
• IPI;
• PIS e COFINS;
• novos campos de IBS/CBS, quando aplicáveis;
• classificação tributária;
• totais;
• informações adicionais;
• documentos referenciados;
• eventos posteriores.

DANFE e alterações de leiaute

O DANFE é representação auxiliar da NF-e e não substitui o XML autorizado. Mudanças de leiaute ou novas modalidades de impressão devem ser implementadas conforme as Notas Técnicas específicas.

Em 2026, por exemplo, foram publicadas notas técnicas específicas sobre o DANFE Simplificado Tipo 2. Isso não significa que toda empresa deva adotar automaticamente o mesmo formato: é necessário verificar a operação e o escopo técnico da nota aplicável.

Novo layout fiscal e SPED

Alterar a NF-e não significa que todos os novos campos sejam automaticamente reproduzidos na EFD ICMS/IPI. O Portal SPED informou que IBS, CBS e Imposto Seletivo não serão incluídos nessa obrigação durante a sistemática divulgada para 2026.

Assim, o ERP precisa manter duas camadas coerentes, mas distintas:

• documento fiscal eletrônico com os campos previstos para a Reforma Tributária;
• escrituração EFD ICMS/IPI seguindo o Guia Prático vigente.

Não se deve criar campos de IBS/CBS no SPED ICMS/IPI por analogia com o XML da NF-e.

Exemplo prático de atualização do sistema

Imagine uma empresa que utiliza ERP próprio para emitir NF-e e possui integrações com e-commerce, estoque e contabilidade.

A atualização não deve começar pela tela da nota. Primeiro, a equipe identifica quais Notas Técnicas estão vigentes, atualiza os schemas, importa tabelas oficiais e mapeia os novos campos. Depois, revisa o motor tributário, APIs e banco de dados.

Na homologação, são testadas operações internas, interestaduais, devoluções, notas complementares e outros cenários relevantes. O fiscal confere o XML gerado, enquanto a equipe técnica valida rejeições e regras. Somente depois o pacote segue para produção.

Erros comuns na adaptação

• usar versão antiga da Nota Técnica;
• tratar “novo layout” como mudança única e definitiva;
• atualizar XML sem atualizar motor tributário;
• ignorar novas tabelas oficiais;
• criar códigos internos que não existem nas tabelas oficiais;
• validar apenas schema e ignorar regras de negócio;
• confundir IBS/CBS com ICMS/PIS/COFINS durante a transição;
• incluir novos tributos em obrigações onde eles não foram previstos;
• não testar integrações antigas;
• não revisar banco de dados para CNPJ alfanumérico;
• não acompanhar novas versões publicadas depois da implantação inicial.

Checklist para faturamento e TI

• A versão vigente das Notas Técnicas foi confirmada no Portal da NF-e?
• O schema instalado corresponde à versão exigida?
• As tabelas oficiais foram atualizadas?
• O ERP suporta os campos novos?
• As regras de tributação foram revisadas pelo fiscal?
• O CNPJ alfanumérico está suportado em banco, APIs e validações?
• Homologação e produção foram testadas separadamente?
• As principais operações da empresa foram simuladas?
• Rejeições novas foram mapeadas?
• O XML autorizado foi conferido campo a campo?
• O DANFE está adequado à modalidade aplicável?
• SPED e demais obrigações continuam coerentes?
• Existe rotina para acompanhar novas versões técnicas?

Perguntas frequentes

Existe um único “novo layout fiscal” para 2026?

Não. Existem várias atualizações técnicas em paralelo. Reforma Tributária, CNPJ alfanumérico, DANFE e outras mudanças possuem documentos e cronogramas próprios.

A Nota Técnica 2025.002 ainda é relevante em 2026?

Sim. Ela continua sendo o documento central das adequações de NF-e/NFC-e à Reforma Tributária e recebeu novas versões em 2026, incluindo a v.1.51 publicada em agosto.

IBS e CBS substituem imediatamente ICMS, PIS e COFINS no XML?

Não. A transição exige convivência de regras e cronogramas. O preenchimento deve seguir a legislação e a Nota Técnica vigente para cada período e operação.

Todo sistema precisa aceitar CNPJ alfanumérico?

Os sistemas que armazenam, validam ou transmitem CNPJ em fluxos alcançados pela mudança precisam ser preparados conforme o cronograma e as especificações técnicas oficiais.

Se o XML for autorizado, está fiscalmente correto?

Não necessariamente. A autorização comprova que o documento passou pelas validações do autorizador, mas não substitui a análise tributária da operação.

IBS e CBS entram na EFD ICMS/IPI em 2026?

Segundo a orientação oficial do Portal SPED, IBS, CBS e Imposto Seletivo não são incluídos na EFD ICMS/IPI. A escrituração deve seguir o Guia Prático vigente.

Fontes oficiais

• Portal Nacional da NF-e — Notas Técnicas vigentes
• Portal Nacional da NF-e
• Portal SPED
• Lei Complementar nº 214/2025

Leia também

• NF-e: guia fiscal da Nota Fiscal Eletrônica
• SPED Fiscal
• Tags do XML da NF-e

Conclusão

O novo layout fiscal de 2026 é uma evolução contínua da infraestrutura dos documentos fiscais eletrônicos. A Nota Técnica 2025.002 permanece central para a Reforma Tributária, enquanto outras Notas Técnicas tratam de CNPJ alfanumérico, DANFE, regras de validação e contribuintes específicos.

A implantação segura depende de quatro controles: versão técnica correta, tratamento fiscal correto, homologação completa e acompanhamento permanente das publicações oficiais. O maior risco não é apenas receber uma rejeição, mas manter um sistema aparentemente funcional com parâmetros fiscais desatualizados.