A evolução da NFS-e Nacional para acomodar informações de IBS e CBS exige uma leitura cuidadosa de três camadas diferentes: a obrigação de emitir e prestar informações fiscais, o leiaute efetivamente aceito no Ambiente de Dados Nacional (ADN) e a documentação técnica que já está disponível para testes. Confundir essas camadas pode levar tanto a mudanças prematuras em produção quanto à conclusão incorreta de que uma nota tecnicamente autorizada está, por isso só, em conformidade tributária.
Para desenvolvedores Delphi, fornecedores de ERP, integradores e profissionais de contabilidade, a questão é operacional: qual XML deve ser gerado agora, o que deve ser validado em Produção Restrita e como tratar a ausência de rejeição do grupo IBS/CBS. Este artigo organiza as evidências oficiais disponíveis sobre a NFS-e padrão nacional, delimita o que ainda depende de publicação formal e propõe uma rota de testes antes da próxima implantação anunciada.
O cenário atual: produção, obrigação e testes não são a mesma coisa
O ponto de partida é separar o ambiente de produção da regra tributária e da evolução do leiaute. No comunicado do CGNFS-e sobre o leiaute em produção, a orientação é que o ADN permanece, no ambiente oficial, com o padrão da Nota Técnica (NT) 004, acrescido do domínio tpRetPisConfins da NT 007. A comunicação anterior do Comitê especifica que se trata da NT 004 versão 2.0 até 30 de novembro de 2026.
Esse é o dado que deve orientar a emissão em produção enquanto não houver a virada efetiva do ambiente. Em termos de engenharia de software, não basta que uma estrutura mais nova esteja documentada ou acessível em teste para que ela se torne o contrato ativo de produção. O contrato ativo, segundo a orientação oficial consultada, continua sendo o leiaute vigente da NT 004 com o acréscimo mencionado da NT 007.
Já a obrigação de emissão dos documentos fiscais eletrônicos relacionados a IBS e CBS decorre do Ato Conjunto RFB/CGIBS nº 4, de 30 de julho de 2026, identificado tanto no repositório do CGIBS quanto na página de atos conjuntos da Receita Federal. O cronograma oficial deixa claro que obrigação tributária e disponibilização técnica de leiaute são marcos distintos.
Essa separação é relevante para a governança de um ERP. A equipe fiscal precisa determinar se determinado cliente, serviço ou operação está alcançado pela obrigação aplicável. A equipe de desenvolvimento, por sua vez, precisa produzir documentos aderentes ao contrato técnico do ambiente em uso. Uma decisão não substitui a outra.
IBS e CBS no ADN: o que a validação técnica informa
A orientação oficial do CGNFS-e afirma que a ausência do grupo IBS/CBS, por si só, não provoca rejeição técnica no ADN. A regra alcança inclusive contribuinte abrangido pela obrigatoriedade. Trata-se de uma característica de recepção e validação do ambiente nacional, e não de uma declaração de dispensa do dever tributário.
Essa distinção merece atenção especial porque a autorização de uma nota costuma ser interpretada, no cotidiano de sistemas fiscais, como sinal de que todas as regras relevantes foram atendidas. Neste caso, a evidência disponível não permite essa equiparação. O próprio comunicado combina dois pontos: há obrigatoriedade decorrente do Ato Conjunto nº 4 e há flexibilidade técnica para que a falta do grupo IBS/CBS não gere rejeição especificamente por essa ausência.
A inferência prática é direta, mas deve ser expressa com precisão: não use o resultado da rejeição técnica como único critério de conformidade tributária. Um sistema pode precisar controlar internamente quais documentos exigem análise ou preenchimento de informações de IBS/CBS, mesmo quando o ADN não bloqueia a transmissão por falta do grupo.
Quando o grupo IBS/CBS for informado
A flexibilidade de omitir o grupo não significa flexibilidade para preenchê-lo parcialmente. Segundo o CGNFS-e, quando o contribuinte optar por informar IBS/CBS, devem ser prestados os campos, os códigos e as classificações exigidos pela estrutura técnica. Conforme o tipo de operação, também são necessários os dados completos do adquirente ou destinatário.
Para quem desenvolve emissores em Delphi, a consequência é evitar uma modelagem baseada apenas em campos visuais opcionais. O domínio fiscal deve ser capaz de representar o grupo completo, suas dependências e as condições que exigem dados do tomador, adquirente ou destinatário. Uma tela que permita marcar IBS/CBS sem garantir a consistência dos elementos correlatos transfere para o XML um problema que deveria ser barrado antes da assinatura e transmissão.
O comunicado também declara que a mesma orientação vale para emissores próprios de municípios integrados ao ADN. Portanto, na abrangência da NFS-e padrão nacional e do ambiente integrado, não há base nas evidências para tratar um emissor municipal próprio como exceção à regra de preenchimento quando o grupo for informado.
A obrigatoriedade não começou de modo uniforme
Outro risco frequente é resumir o cronograma como se todas as NFS-e tivessem passado a seguir o mesmo marco em 1º de outubro de 2026. O cronograma de documentos fiscais eletrônicos da Receita Federal não sustenta essa simplificação.
Para NFS-e de serviços em geral sujeitos ao ISS, o início indicado é 1º de outubro de 2026. O mesmo cronograma aponta 1º de dezembro de 2026 para outras categorias, entre elas plataformas, determinados serviços específicos, bens imateriais, condomínios e locações. Logo, a data aplicável depende do enquadramento da operação ou do segmento indicado no cronograma oficial.
Para a contabilidade, isso recomenda uma matriz de decisão que identifique a natureza da operação antes de definir parâmetros fiscais no cadastro do cliente. Para o desenvolvimento, recomenda que datas e regras não sejam codificadas como uma chave global única de sistema. Uma parametrização versionada por cenário de emissão tende a refletir melhor a evidência disponível do que um simples indicador “IBS/CBS ativo”.
Não é possível, com as fontes reunidas, detalhar aqui todas as condições de cada categoria, nem transformar esse cronograma em parecer aplicável a uma operação concreta. A definição do enquadramento deve permanecer sob análise fiscal, com consulta à documentação oficial pertinente.
NT 009: o que já está disponível para validação
O release 1 das evoluções da NT 009 versão 1.0 está em Produção Restrita. O comunicado de 20 de outubro do CGNFS-e informa três alterações relevantes para as equipes técnicas: o reposicionamento de CST e cClassTrib, a criação do grupo vAjusteBC e a inclusão dos novos fatos geradores identificados pelos códigos 99.02 a 99.04.
O portal técnico também relaciona as versões e os anexos da NT 004, NT 007 e NT 009. Essa documentação deve ser a base para a conferência de schemas, ordem de elementos, cardinalidades e demais regras de integração, em vez de adaptações inferidas de exemplos informais.
Há uma restrição importante: para os códigos 99.02 a 99.04, a emissão em ambiente de testes está disponível, por ora, apenas via API. O emissor web não oferece ainda essa funcionalidade nesse cenário. Isso significa que uma equipe que dependa exclusivamente de testes manuais no emissor web não conseguirá cobrir esses casos; será necessário preparar chamadas pela API de Produção Restrita.
As fontes examinadas confirmam a existência desses códigos e sua disponibilidade técnica limitada por canal, mas não trazem, no material acessível na apuração, a definição nominal de cada um. Por isso, não é adequado atribuir-lhes significados ou associá-los a operações específicas sem consultar os anexos técnicos ou a tabela oficial correspondente.
O que a Produção Restrita prova — e o que não prova
Produção Restrita serve para validar integração, estrutura e comportamento do ambiente de testes. O CGNFS-e informa expressamente que esse ambiente não produz efeitos jurídicos ou obrigacionais para o contribuinte. Assim, um teste bem-sucedido demonstra que o fluxo foi aceito naquele ambiente e na versão examinada; não comprova, isoladamente, que a operação tenha efeito fiscal em produção nem que o enquadramento tributário esteja correto.
Essa limitação não diminui a importância dos testes. Ao contrário, ela define seu propósito: reduzir incerteza técnica antes da alteração de produção, sem substituir a revisão fiscal. Para organizações que mantêm biblioteca própria de geração XML em Delphi, é uma oportunidade de testar serialização, validação contra XSD, montagem condicional de grupos, assinatura, transporte e tratamento de retornos sem interferir na emissão oficial.
O marco de 1º de dezembro de 2026 exige acompanhamento
A implantação das evoluções em produção foi anunciada para 1º de dezembro de 2026 no comunicado de 20 de outubro. Porém, a orientação posterior, de 29 de outubro, afirma que os releases 1 a 3 deverão estar em produção nessa data e registra que o cronograma formal ainda seria publicado.
As duas comunicações apontam o mesmo marco, mas a segunda introduz uma ressalva relevante sobre a formalização do cronograma. A leitura prudente é tratar 1º de dezembro como data oficial anunciada de implantação técnica, acompanhada da condição de confirmação por cronograma formal. Não é correto apresentá-la como fato consumado antes da implantação efetiva, nem como uma nova data geral e única de obrigação tributária.
Para o planejamento, isso pede prontidão sem antecipação indevida: manter produção conforme o leiaute hoje declarado; concluir testes da NT 009 em Produção Restrita; e acompanhar novas publicações do CGNFS-e e da Receita Federal antes de ativar uma alteração em massa.
Aplicação prática
Uma estratégia segura começa por dividir o trabalho entre controles fiscais, configuração de ambiente e testes de integração. A seguir, há um roteiro baseado nas evidências disponíveis.
1. Mantenha uma trilha de produção separada
Até a mudança efetiva, mantenha a geração de NFS-e em produção aderente à NT 004, com o domínio tpRetPisConfins da NT 007. Evite usar a disponibilidade de uma estrutura em Produção Restrita como justificativa para alterar automaticamente o XML produtivo.
No código Delphi, isso favorece um resolvedor explícito de versão de leiaute por ambiente. Em vez de espalhar condicionais pela classe de serialização, centralize a escolha de versão e faça com que ela determine schema, mapeamento de campos e regras de montagem. A recomendação é arquitetural, baseada na necessidade prática de separar contratos de ambientes; ela não implica a existência de uma biblioteca ou endpoint específico.
2. Crie uma matriz entre obrigação e recepção técnica
Monte, com o responsável fiscal, uma matriz que tenha ao menos: tipo de serviço ou operação, categoria do cronograma, data de início aplicável, necessidade de informações IBS/CBS, condição de identificação do adquirente ou destinatário e leiaute ativo no ambiente. Registre a fonte oficial usada para cada decisão.
Essa matriz evita que a ausência de rejeição no ADN seja convertida em regra de negócio. Quando houver obrigação aplicável, o sistema deve sinalizar a necessidade de análise e preenchimento mesmo que a transmissão sem o grupo seja tecnicamente aceita. Quando o grupo for preenchido, valide previamente códigos, classificações e dependências antes do envio.
3. Teste a NT 009 pela API de Produção Restrita
Use a Produção Restrita para exercitar o release 1 da NT 009 versão 1.0. Os casos de teste devem cobrir, no mínimo, documentos sem grupo IBS/CBS, documentos com o grupo completo e cenários que demandem dados de adquirente ou destinatário. A finalidade é observar a validação técnica e garantir que o sistema não gere estruturas incompletas quando optar pelo preenchimento.
Inclua casos específicos para o reposicionamento de CST e cClassTrib e para o grupo vAjusteBC. Para os fatos geradores 99.02 a 99.04, execute a cobertura via API, pois o emissor web não é o canal disponível para esses testes no momento descrito pelas fontes. Documente request, XML gerado, resposta, versão do schema e data da execução para permitir repetição depois de qualquer atualização.
4. Valide o ciclo completo, não só o XML
A validação por XSD é necessária, mas não encerra o teste. Verifique a transformação dos dados de origem em objetos de domínio, a serialização XML, a assinatura quando aplicável ao seu fluxo, o envio para o ambiente correto e a leitura das respostas. Também confirme que logs não misturam requisições de Produção Restrita com produção e que as configurações de cada ambiente são auditáveis.
Para o contador, a contrapartida é revisar se os dados fornecidos ao ERP permitem formar os grupos exigidos quando houver preenchimento: classificações, códigos e identificação das partes conforme a operação. O software só consegue validar aquilo que recebe de forma estruturada e consistente.
5. Prepare a entrada em produção como mudança controlada
Antes de habilitar novo leiaute, defina um procedimento de virada: confirme a publicação formal e a documentação técnica vigente; congele versões de schemas usadas nos testes; realize emissão controlada após a liberação; e mantenha plano de retorno compatível com as regras então publicadas. A confirmação precisa ser feita em fonte oficial, porque o próprio CGNFS-e informou que o cronograma formal ainda seria publicado.
Limitações e cuidados de interpretação
Este recorte trata exclusivamente da NFS-e padrão nacional e do ADN. Não há base, nas evidências analisadas, para generalizar o comportamento de validação do ADN a sistemas municipais que não sejam integrados, nem a outros documentos fiscais eletrônicos.
Também não foram atribuídos significados aos códigos 99.02, 99.03 e 99.04. Embora sua presença no release e a disponibilidade por API em Produção Restrita estejam confirmadas, a definição de cada código não foi localizada em texto oficial acessível durante a apuração. A consulta aos anexos técnicos aplicáveis é indispensável antes de criar regras de negócio para eles.
Por fim, há uma tensão documental controlada, não uma contradição resolvida: um comunicado diz que a implantação ocorrerá em 1º de dezembro de 2026; outro mantém a expectativa para essa data, mas informa que o cronograma formal ainda seria publicado. Por isso, a data deve orientar preparação e monitoramento, não uma afirmação de implantação já concluída.
Conclusão
A orientação mais importante para a NFS-e Nacional é manter separados o dever fiscal, o comportamento técnico do ADN e a evolução do leiaute. Em produção, permanece o padrão da NT 004 com o domínio da NT 007 indicado pelo CGNFS-e. A omissão de IBS/CBS não gera, isoladamente, rejeição técnica, mas essa recepção flexível não elimina a obrigação aplicável conforme o cronograma e o Ato Conjunto RFB/CGIBS nº 4.
Enquanto isso, o release 1 da NT 009 oferece um campo concreto para testes em Produção Restrita, com mudanças em CST, cClassTrib, vAjusteBC e fatos geradores identificados pelos códigos 99.02 a 99.04. A melhor resposta técnica não é antecipar a mudança em produção, mas estruturar parametrização por ambiente, testar pela API quando necessário, envolver a área fiscal nas regras de negócio e acompanhar a formalização do cronograma de implantação.
Referências
COMITÊ GESTOR DA NOTA FISCAL DE SERVIÇO ELETRÔNICA (CGNFS-e). CGNFS-e informa: disponibilizadas no ambiente de testes o release 1 das evoluções da Nota Técnica 009. Portal da NFS-e, 20 out. 2026. Disponível em: https://www.gov.br/nfse/pt-br/noticias/cgnfs-e-informa-disponibilizadas-no-ambiente-de-testes-o-release-1-das-evolucoes-da-nota-tecnica-009. Acesso em: 30 out. 2026.
COMITÊ GESTOR DA NOTA FISCAL DE SERVIÇO ELETRÔNICA (CGNFS-e). NFS-e Nacional: confira as orientações sobre leiaute em produção, regras de preenchimento de IBS/CBS e status da Nota Técnica 009. Portal da NFS-e, 29 out. 2026. Disponível em: https://www.gov.br/nfse/pt-br/noticias/nfs-e-nacional-confira-oas-rientacoes-sobre-leiaute-em-producao-regras-de-preenchimento-de-ibs-cbs-e-status-da-nota-tecnica-009/. Acesso em: 30 out. 2026.
COMITÊ GESTOR DA NOTA FISCAL DE SERVIÇO ELETRÔNICA (CGNFS-e). RTC: documentação técnica com atualizações da Reforma Tributária do Consumo: grupos IBSCBS. Portal da NFS-e, 2025. Disponível em: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc/rtc. Acesso em: 30 out. 2026.
COMITÊ GESTOR DO IMPOSTO SOBRE BENS E SERVIÇOS (CGIBS). Atos Conjuntos. [S. l.], 2026. Disponível em: https://www.cgibs.gov.br/atos-conjuntos. Acesso em: 30 out. 2026.
RECEITA FEDERAL DO BRASIL. Atos Conjuntos: Reforma Tributária do Consumo. Brasília, DF, 2026. Disponível em: https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/reforma-tributaria-do-consumo/legislacao/atos-conjuntos. Acesso em: 30 out. 2026.
RECEITA FEDERAL DO BRASIL. Cronograma dos documentos fiscais eletrônicos. Brasília, DF, 18 set. 2026. Disponível em: https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/reforma-tributaria-do-consumo/orientacoes-da-reforma-tributaria/cronograma. Acesso em: 30 out. 2026.
0 comentário(s)