BRASÍLIA/DF — A pergunta que passou a circular entre empresas, escritórios de contabilidade, software houses e prefeituras é objetiva: o que exatamente muda no XML da NFS-e com a Nota Técnica 009 a partir de dezembro de 2026? A resposta também é objetiva, mas exige atenção técnica. O Comitê Gestor da NFS-e confirmou que a primeira leva de mudanças do release 1 entra em produção em 1º de dezembro de 2026, depois de já ter sido disponibilizada em ambiente de testes em 20 de outubro. Até 30 de novembro, porém, o leiaute atualmente em produção continua válido.
Mais do que uma troca de campos, a atualização mexe na estrutura lógica do XML, no comportamento das integrações e na forma como os sistemas precisam validar informações ligadas à reforma tributária do consumo. Entre os pontos já confirmados estão o reposicionamento dos campos CST e cClassTrib, a inclusão de novos fatos geradores na API de emissão e a criação do grupo vAjusteBC. Para quem emite NFS-e em grande volume, esperar dezembro para começar a adaptação pode significar rejeições, retrabalho e risco operacional.
Quando as mudanças do XML passam a valer na NFS-e?
O cronograma oficial divulgado no Portal da NFS-e informa que as evoluções do release 1 da Nota Técnica 009 foram disponibilizadas em produção restrita em 20 de outubro de 2026 e passarão ao ambiente de produção em 1º de dezembro de 2026. Até 30 de novembro, permanece em produção o leiaute definido pela Nota Técnica nº 004, versão 2.0, com a documentação já publicada no portal.
Na prática, isso significa que novembro é o mês de transição técnica. Empresas, desenvolvedores e integradores podem usar o ambiente de testes para conferir se seus emissores, ERPs e validadores de XML estão preparados para o novo formato. Não se trata de uma mudança apenas documental: o ajuste impacta schema, mapeamentos e rotinas de preenchimento.
O que muda com o reposicionamento dos campos CST e cClassTrib?
Uma das alterações mais sensíveis está no reposicionamento dos campos CST e cClassTrib dentro da estrutura do XML da nota fiscal. À primeira vista, a informação continua sendo a mesma. O problema é que muitos sistemas consomem ou geram XML com base em caminhos fixos da estrutura, e qualquer deslocamento pode quebrar integrações, rotinas de importação e regras automáticas de validação.
Por isso, o impacto real não está no nome do campo, mas no lugar em que ele passa a existir dentro da árvore do XML. Em termos práticos, softwares que fazem leitura por posição, XPath ou mapeamento rígido precisarão revisar o apontamento desses elementos. O mesmo vale para motores de conferência tributária, robôs de conciliação e conectores que importam dados da NFS-e para a escrituração.
Quais novos fatos geradores entram na API de emissão?
O release 1 também inclui os novos fatos geradores 99.02, 99.03 e 99.04 na API de emissão. Esse ponto interessa especialmente às empresas e equipes que já estão adaptando a NFS-e para as regras da reforma tributária do consumo. A mudança amplia o escopo do documento e exige atenção ao preenchimento correto dos códigos de operação vinculados às novas hipóteses previstas na documentação técnica.
Em termos operacionais, isso pode exigir atualização das tabelas internas do sistema emissor, adequação das telas de parametrização e revisão das regras que vinculam natureza da operação, incidência tributária e tipo de fornecimento. Quando a API passa a aceitar novos fatos geradores, não basta apenas “liberar o campo”: é preciso garantir coerência entre o XML gerado, a regra de negócio e a validação esperada pelo ambiente nacional da NFS-e.
O que é o grupo vAjusteBC e por que ele importa?
Outra mudança relevante é a criação do grupo vAjusteBC, resultante do merge dos grupos vDedRed e gReeRepRes. Em linguagem menos técnica, o sistema deixa de trabalhar com grupos separados para determinadas informações de dedução, redução ou ajuste da base de cálculo e passa a consolidá-las em uma nova estrutura.
Essa alteração importa porque afeta diretamente o modo de serializar os dados no XML. Quem já montava mensagens com base na estrutura anterior terá de adaptar o preenchimento ao novo grupo, evitando repetir informações em campos que deixarão de existir da mesma forma. Também será necessário revisar manuais internos, layouts de integração e rotinas de transformação de dados, sobretudo em empresas que utilizam middleware entre ERP e emissor fiscal.
A Nota Técnica 009 muda apenas esses três pontos?
Não. A Nota Técnica 009, em seu conjunto, é mais ampla e consolida adaptações da NFS-e e da DPS no contexto da reforma tributária. Entre as evoluções já divulgadas oficialmente em junho e atualizadas depois pela versão 1.01, estão temas como CNPJ alfanumérico, reinserção do campo indFinal, ajustes para operações com bens imóveis, mudanças em bens móveis e vinculação de pagamentos por meio do grupo gPgtoVinc.
Ocorre que nem todas as funcionalidades entram em produção ao mesmo tempo. O próprio portal da NFS-e esclarece que a implantação será gradual e que as versões 1.01 e superiores também passarão primeiro pela produção restrita. Por isso, a pergunta “o que muda em dezembro” deve ser respondida com precisão: em 1º de dezembro, entram em produção os itens já expressamente listados para o release 1, e não necessariamente toda a NT 009 em sua extensão máxima.
Como essas mudanças afetam ERPs, emissores e software houses?
O efeito mais imediato é técnico. Toda empresa ou fornecedor que gera XML da NFS-e precisará revisar schemas XSD, mapeamento de campos, regras de negócio e testes de rejeição. Não basta atualizar a interface do sistema: a estrutura de saída do XML deve estar compatível com o ambiente nacional no momento da transmissão.
Para software houses, o ideal é separar a adaptação em quatro frentes: leitura da documentação oficial, revisão dos pontos de integração, teste em produção restrita e validação com casos reais. Para empresas usuárias, a providência mais segura é cobrar de seus fornecedores um cronograma claro de atualização. Escritórios contábeis, por sua vez, devem verificar se os documentos importados por seus sistemas continuam sendo lidos sem perda de dados relevantes.
Quais erros podem ocorrer se a adaptação não for feita a tempo?
Os problemas mais prováveis são rejeição por schema incompatível, falhas na identificação de campos, perda de informação na importação do XML e geração de documentos com estrutura desatualizada. Em alguns casos, o erro pode ser visível no momento da transmissão. Em outros, ele só aparece depois, quando o arquivo é recebido pelo ERP, por um validador interno ou por uma rotina de apuração tributária.
Esse risco cresce quando o sistema depende de bibliotecas antigas, integrações terceirizadas ou desenvolvimento sob medida. Mesmo pequenos ajustes estruturais podem afetar automações construídas em cima do leiaute anterior. Por isso, a mudança de dezembro deve ser tratada como projeto técnico e não apenas como atualização rotineira.
O que as empresas devem fazer antes de dezembro de 2026?
O passo mais prudente é usar o ambiente de produção restrita para testar cenários reais de emissão, conferindo se o XML gerado está compatível com os novos schemas e se os campos reposicionados continuam sendo lidos corretamente por todos os sistemas da cadeia. Também convém revisar parametrizações ligadas aos novos fatos geradores e à nova estrutura vAjusteBC.
Além disso, empresas e desenvolvedores devem acompanhar as publicações do Portal da NFS-e, porque a própria documentação oficial informa que outras evoluções da versão 1.01 e posteriores serão disponibilizadas de forma progressiva. Quem trabalha com nota fiscal de serviços não deve olhar apenas para a data de entrada em produção, mas para o conjunto de ajustes necessários para manter a emissão estável e aderente às regras da reforma tributária.
Fontes oficiais consultadas:
1. Portal da NFS-e — Atualizações e Implantações
3. Portal da NFS-e — Publicada a Nota Técnica 009 com evoluções da NFS-e
5. Portal da NFS-e — RTC / Documentação Técnica com Atualizações da Reforma Tributária do Consumo
6. Presidência da República — Lei Complementar nº 214/2025
Conteúdo informativo produzido com base em fontes oficiais consultadas na data da publicação desta matéria. A implantação da Nota Técnica 009 ocorre de forma gradual, e novas versões, cronogramas e regras de validação podem ser divulgados posteriormente pelo Portal da NFS-e.