NFS-e em testes exige revisar o ERP antes de dezembro

Por Helena Prado
26 de outubro de 2026

A liberação das funcionalidades da Nota Técnica nº 009, versão 1.0, da NFS-e para testes já permite trabalhar em três frentes concretas: localização dos campos tributários no XML, novos códigos na API de emissão e reorganização das informações de ajuste da base de cálculo. Para Fiscal e Tecnologia, isso significa revisar a integração, não apenas atualizar uma tela do ERP.

O Comitê Gestor da NFS-e anunciou a disponibilidade em 21 de outubro. O registro das funcionalidades e do cronograma, publicado em 25 de outubro, também informa a implantação dos ajustes de leiaute das versões 1.01 e superiores em 1º de dezembro de 2026, após sua disponibilização em produção restrita.

Esse marco não abrange indistintamente todas as entregas da reforma. As notas de finalidade de ajuste e os eventos específicos terão cronograma próprio, ainda a divulgar. Separar esses pacotes evita antecipar funcionalidades ou atribuir à abertura dos testes uma obrigatoriedade que ela, sozinha, não estabelece.

Testes, implantação e obrigação têm papéis diferentes

Produção restrita é o ambiente para homologar a comunicação e o comportamento dos sistemas. Produção é o ambiente operacional. A aplicação tributária de uma informação depende das regras da operação; sua obrigatoriedade exige observar as condições de preenchimento e os atos pertinentes. São verificações relacionadas, mas não equivalentes.

O cronograma informado distingue as evoluções da versão 1.0 já disponíveis para testes dos ajustes das versões 1.01 e superiores, que passam primeiro pela produção restrita até a implantação prevista para dezembro. O planejamento deve registrar qual versão está sendo homologada e qual será implantada, sem tratar todas como um pacote indistinto.

Também é necessário separar as datas documentais. 21 de outubro é a data do anúncio; 25 de outubro é a publicação da notícia. Nenhuma delas deve ser registrada automaticamente como data de publicação da NT. No controle de versões, vale a identificação do próprio documento técnico utilizado no desenvolvimento.

CST e cClassTrib mudam de lugar no XML

A primeira alteração é o reposicionamento de CST, Código de Situação Tributária, e cClassTrib, Código de Classificação Tributária, na estrutura do XML, indicado no item 2.16 da NT 009. O efeito imediato é estrutural: sistemas que escrevem ou procuram esses campos na localização anterior precisam revisar seu mapeamento.

No ERP, a origem dos valores pode continuar a mesma, mas o gerador do XML precisa colocá-los na posição especificada. Na integração, transformações e leitores devem acompanhar a mudança. Reposicionar um campo não significa, por si só, mudar seu conteúdo ou o tratamento tributário da operação. Fiscal valida a classificação; Tecnologia valida sua transmissão e leitura.

A homologação deve acompanhar CST e cClassTrib desde a parametrização até o documento retornado e armazenado. É preciso verificar se o integrador preserva os valores e se os sistemas internos conseguem recuperá-los. O controle de versões é semelhante ao discutido na adaptação de integrações após mudanças de leiaute do SPED: aceitar a estrutura não comprova a correção fiscal do conteúdo.

A API passa a contemplar os códigos 99.02 a 99.04

A segunda frente é a inclusão dos novos fatos geradores de códigos 99.02 a 99.04 na API de emissão. A referência informada é o item 2.15 da NT 009, em conjunto com o item 2.1.3 da NT 005. A análise precisa, portanto, considerar os dois pontos da documentação, e não apenas acrescentar três opções ao cadastro.

O impacto potencial está nas listas de códigos aceitos pelo ERP, nas validações locais e na mensagem enviada à API. Uma integração pode impedir a transmissão antes mesmo de consultar o ambiente nacional se mantiver uma relação antiga de valores permitidos. Essa é uma hipótese de falha a testar, não uma rejeição específica anunciada pelo Comitê.

Para cada código aplicável às operações da empresa, a equipe deve preparar um cenário com enquadramento validado pelo Fiscal. Depois, conferir geração, transmissão, resposta e registro interno. Também convém preservar testes das operações já utilizadas: incluir novos códigos não pode interromper a emissão regular. A disponibilidade técnica não autoriza escolher um código apenas porque o sistema o aceita.

vAjusteBC exige rever a origem dos valores

A terceira alteração cria o grupo vAjusteBC a partir da unificação dos grupos vDedRed e gReeRepRes, conforme o item 2.3 da NT 009. Aqui, o trabalho vai além da localização de campos: é necessário revisar como as informações anteriormente separadas serão representadas na nova estrutura.

O ERP e a plataforma fiscal devem ter um mapeamento explícito entre origem e destino. A equipe precisa identificar quais dados alimentavam cada grupo anterior, quais transformações são necessárias e como o resultado será conferido. A unificação não deve ser implementada como uma soma automática sem verificar as regras e a composição previstas no leiaute.

Os testes devem cobrir operações aplicáveis que utilizavam cada grupo anterior e verificar a preservação do significado dos valores no novo formato. O controle central é impedir perda ou duplicidade de informação entre ERP, integrador e documento. Uma reorganização do XML não deve produzir, por erro de implementação, um segundo ajuste sobre o mesmo valor.

A integração precisa funcionar até o documento final

A homologação não termina com uma resposta positiva da API. Cada alteração precisa ser acompanhada até o XML armazenado, os registros do ERP e os sistemas que consomem a nota. A necessidade de conciliar o envio com a NFS-e efetivamente emitida permanece: transmitir uma solicitação não comprova, isoladamente, a conclusão do processo.

Na integração municipal, a empresa deve mapear o caminho de emissão de cada estabelecimento e confirmar a versão suportada pelos componentes envolvidos. A disponibilidade no ambiente de testes não comprova que todos os conectores utilizados pela organização estejam atualizados. Para serviços tomados, a mudança técnica também não substitui a conferência de onde recolher e quando reter o ISS.

O IMTT — Índice de Maturidade Tecnológica em Tax, da Confeb, de 2026, com 190 profissionais respondentes, mostra por que essa verificação importa: 100% das empresas respondentes utilizam ERP, mas 31% ainda fazem envio manual na integração interna entre ERP e plataformas de Tax. Na adaptação tecnológica à reforma, 49% apontam integrações entre sistemas como uma complexidade.

O que precisa estar pronto antes de dezembro

O plano de trabalho deve separar três entregas: atualização dos mapeamentos de CST e cClassTrib; suporte aos códigos 99.02 a 99.04; e conversão das estruturas anteriores para vAjusteBC. Cada uma precisa ter responsável, versão de referência, cenários aplicáveis e evidências de teste. Isso permite cobrar do fornecedor uma entrega verificável, e não apenas a declaração de que o sistema está atualizado.

Antes da implantação prevista para 1º de dezembro, Fiscal e Tecnologia devem comparar a versão homologada com a versão destinada à produção. Também precisam definir o acompanhamento das primeiras emissões e o tratamento de falhas conforme as regras aplicáveis. Notas de ajuste e eventos específicos devem permanecer em uma frente separada, aguardando seu cronograma.

A decisão prática é começar agora a homologação das mudanças disponíveis, sem antecipá-las na emissão operacional. Há alterações identificadas e uma data informada para os ajustes de leiaute; não há fundamento para tratar toda a reforma da NFS-e como uma única entrada em vigor.

Este conteúdo foi produzido com apoio de inteligência artificial e revisado pela equipe editorial da Live University.