Skip to main content

NT 009 da NFS-e: o leiaute nacional entra de cabeça na Reforma Tributária

A Nota Técnica nº 009 (v1.0), publicada em 4 de junho de 2026 traz renomeações que quebram contrato, notas de ajuste de IBS/CBS, CNPJ alfanumérico, Simples Nacional com cálculo próprio e vinculação de pagamento. Um guia campo a campo da maior virada do padrão nacional até agora. Veja neste artigo as mudanças e impactos desta NT.

A NT 009 da NFS-e

A Nota Técnica nº 009 (v1.0), publicada em 4 de junho de 2026 pela Secretaria-Executiva do Comitê Gestor da NFS-e (SE/CGNFS-e), consolida o leiaute da NFS-e nacional para a Reforma Tributária do Consumo. Ela vem acompanhada de dois anexos revisados — AnexoVI-LeiautesRN_RTC_IBSCBS v1.04.00 e AnexoVII-IndOp_IBSCBS v1.02.00 — com as mudanças destacadas em fúcsia e os ajustes específicos das notas de débito/crédito marcados em azul.

São oito frentes de mudança. Boa parte delas é de renomeação e unificação de grupos — ou seja, quebra de contrato para quem já integrou as NTs anteriores. As outras introduzem capacidades inéditas: notas de ajuste de IBS/CBS, tratamento próprio de Simples Nacional e vinculação da NFS-e à transação de pagamento (o gancho com o Split Payment).

O cronograma de implantação ainda não foi publicado — a própria NT informa que sairá “nas próximas semanas” no portal da NFS-e. E parte das regras das notas de ajuste está tachada nos anexos, sinalizando que ainda vai mudar.

Resumo das mudanças em um quadro

image.png

Legenda dos tipos nas tabelas: E = Elemento · G = Grupo · CE = Escolha de elemento · CG = Escolha de grupo · N = Numérico · C = Caractere · D = Data · Ocor. = ocorrência (mín-máx) · V2 = duas casas decimais.

A seguir, cada uma das oito frentes em detalhe: o que a NT determina, os campos envolvidos e — o mais importante para quem desenvolve — o que isso significa na prática da integração.

CNPJ Alfanumérico

A mudança parece pequena na descrição e é enorme na prática. Todos os campos CNPJ tiveram o tipo alterado de numérico (N) para caractere (C), para contemplar o novo formato alfanumérico do Cadastro Nacional de Pessoas Jurídicas, previsto para começar a partir de julho de 2026.

O CNPJ alfanumérico mantém a estrutura de 14 posições, mas as oito primeiras (raiz) e as quatro de ordem passam a aceitar letras e números; apenas os dois dígitos verificadores permanecem numéricos. O cálculo do DV continua pelo módulo 11, agora considerando o valor ASCII dos caracteres. Por isso a NFS-e não pode mais tratar o CNPJ como inteiro.

image.png

Notas de Ajuste de IBS/CBS

Aqui está um conceito novo: a NFS-e passa a poder formalizar notas de ajuste — de crédito ou de débito — de IBS e CBS. Para suportar isso, a NT mexe na ocorrência de vários grupos e campos (marcados em azul no AnexoVI) e cria uma planilha norteadora, a NFS-e_AJUSTE_LEIAUTE, que indica, para cada tipo de nota de ajuste, quais campos não devem ser informados (marcados com X) e quais podem ser informados, entrando nas regras gerais (marcados com V).

O campo finNFSe ganha um novo papel

O indicador de finalidade da NFS-e foi deslocado e teve o domínio ampliado. É ele que diferencia uma nota regular de uma nota de ajuste e, junto com tpNFSeDebito / tpNFSeCredito, qualifica a natureza do ajuste.

image.png

O grupo gIBSCBSAjuste

Para carregar os valores de ajuste propriamente ditos, foi criado um grupo dentro de IBSCBS/valores/trib:

image.png

Atenção — capítulo em construção

A própria NT avisa: várias regras das notas de ajuste foram inseridas na planilha RN DPS_NFS-e porém tachadas, porque ainda estão em evolução e devem mudar. Elas foram mantidas tachadas apenas para deixar clara a lógica de obrigatoriedade que será implementada. Trate este tópico como direção arquitetural confirmada, mas regras de validação ainda voláteis — não congele código de validação aqui ainda.

O merge de vDedRed e gReeRepRes em vAjusteBC

Se você só tem tempo para tratar uma seção desta NT primeiro, é esta. Os grupos vDedRed e gReeRepRes — que carregavam, respectivamente, os ajustes (dedução/redução) da base de cálculo do ISSQN e os de IBS/CBS por documentos — foram unificados em um único grupo: vAjusteBC. A justificativa da NT é clareza, economia e concentração de campos com o mesmo teor informacional.

A nova estrutura na DPS

O grupo concentra o ajuste percentual do ISSQN e um subgrupo de documentos (docAjusteBC, com até 1.000 ocorrências), cada um com seu tipo de ajuste, valores, datas e a referência ao documento de origem — seja do Repositório Nacional, de documento fiscal fora dele, ou de documento não fiscal.

image.png

O grupo fornec traz a identificação completa do fornecedor: CNPJ (agora caractere, conforme 2.1), CPF, NIF com cNaoNIF para não residentes, xNome, além do endereço nacional (endNac: cMun, CEP) ou no exterior (endExt: cPais, cEndPost, xCidade, xEstProvReg) e contatos. Para entender os efeitos de cada tipo de ajuste sobre as bases, o AnexoVI traz a tabela AJUSTE_BC_REPERCUSSÃO, que cruza cada tipo com seu reflexo no ISSQN, no IBS/CBS e na Receita Bruta do Simples Nacional.

Domínio de tpAjusteBC

image.png

Três tipos que existiam em vDedRed/documentos/docDedRed/tpDedRed foram descontinuados na unificação:

1 — Alimentação e bebidas/frigobar: não pode mais entrar na NFS-e, pois alimentos e bebidas já são registrados em outros documentos fiscais eletrônicos do próprio fornecedor; incluí-los afetaria o cálculo de IBS/CBS desses fornecimentos.

3 — Produção externa: redundante: passa a ser registrado pelo tipo 103, que descreve melhor a operação e reflete em IBS/CBS.

4 — Reembolso de despesas: redundante — os casos com reflexo em IBS/CBS estão cobertos por 103, 104 ou 199. Reembolsos admitidos pelo município e fora dessas hipóteses devem usar o tipo 99, apenas com reflexo na BC do ISSQN.

Renomeações na NFS-e e fórmulas de base de cálculo

Espelhando a reorganização da DPS, três campos de valor calculado foram renomeados na NFS-e:

image.png

A fórmula de vCalcAjusteBCISSQN também evoluiu: passa a considerar todas as deduções com repercussão na BC do ISSQN — percentual mais documentos, desde que o tipo de ajuste por documento possa ser informado em concomitância com o percentual.

image.png

O corte temporal reflete a transição: até 2026 ainda há PIS e COFINS a subtrair; a partir de 2027, com a entrada do regime, essas parcelas saem da fórmula, restando o ISSQN durante o período de coexistência (até 2032).

Evoluções para o Simples Nacional

Para o correto destaque de alíquotas e valores de IBS/CBS quando esses tributos são apurados pelo Simples Nacional, o leiaute ganhou um conjunto de campos próprios. Esta é uma das áreas mais densas da NT.

Na DPS

image.png

  • 7 Serviços/cessão de direitos com incidência do ISS, tributados exclusivamente pelo Anexo III
  • 8 Serviços contábeis autorizados a pagar ISS em valor fixo no Município — Anexo III
  • 9 Serviços sujeitos ao Fator “R” — Anexo III ou V
  • 10 Transporte municipal de passageiros (subitem 16.01 da LC 116/2003) — Anexo III
  • 11 Locação de bens móveis e operações com bens imateriais/direitos, inclusive imóveis, sem incidência de ISS — Anexo III
  • 12 / 13 Construção civil (subitens 7.02 e 7.05 da LC 116/2003) — Anexo III (12) ou Anexo IV (13)
  • 14 Prestação de serviços — Anexo IV · 90 Operações não tributadas

A numeração ordinal foi mantida (por padronização entre documentos de padrão nacional), adotando-se apenas os códigos aplicáveis às operações da NFS-e — daí a lista começar em 7.

Na NFS-e: receita bruta e o grupo gTribSN

Para acomodar o destaque de IBS/CBS dos optantes (ou pendentes) com apuração pelo SN, a ocorrência de vários campos/grupos que antes eram obrigatórios na NFS-e foi flexibilizada: vIBSTot, gIBSUFTot, gIBSMunTot, pCredPresCBS, vCredPresCBS e vCBS. Quem trata esses campos como sempre presentes vai precisar revisar a lógica de leitura e validação.

image.png

Receita Bruta do Simples Nacional

vReceitaBrutaSN = vServ − descIncond − vCalcAjusteBCIBSCBS − vCalcAjusteBCISSQN*

  • apenas quando o valor calculado vier de docAjusteBC/tpAjusteBC = 9 (Profissional parceiro)

image.png

Reinserção do campo indFinal

O campo indFinal volta ao leiaute para indicar operações que se configurem como de uso ou consumo pessoal, na forma do art. 57 da LC 214/2025. É um campo simples, mas com peso na lógica de tributação — operações de uso/consumo pessoal têm tratamento próprio quanto ao creditamento.

image.png

Reestruturação das operações com bens imóveis

As operações com imóveis — exceto obras — formalizadas por NFS-e, tanto as no campo de incidência do ISSQN quanto os novos fatos geradores (locação, cessão onerosa ou arrendamento), passaram por uma reestruturação do grupo imovel. Três movimentos centrais:

image.png

 

image.png

A lógica de proporcionalidade por copropriedade

Com a criação do gLocacao, as regras de validação de vServ, vDescIncond e vDescCond mudaram. Para os códigos de tributação nacional do subitem 99.03, esses valores passam a ser proporcionais ao percentual de copropriedade:

image.png

Na prática: informa-se o valor total da operação uma vez (em gLocacao), e a NFS-e de cada coproprietário carrega a sua fração. O vTotOper e os valores de ajuste nunca recebem o valor já rateado — o rateio acontece nos campos de valor do serviço.

De gLocBensMoveis para bensMoveis

Movimento de padronização: o grupo de locação de bens móveis foi renomeado de gLocBensMoveis para bensMoveis, alinhando a nomenclatura aos demais grupos de novos fatos geradores (imovel e bensMoveis). Além do nome, o grupo passou a aceitar até 1.000 registros.

image.png

Impacto na integração

Renomeação simples no papel, quebra de contrato na prática: qualquer parser, schema de validação, mapeamento ORM ou template de geração de XML que referencie gLocBensMoveis precisa apontar para bensMoveis. Vale uma busca textual no código por todos os nomes antigos desta NT de uma vez.

Criação do grupo gPgtoVinc

O grupo gPgtoVinc vincula a NFS-e à transação de pagamento relacionada, quando essa informação está disponível até o momento da emissão. Para os casos em que o pagamento só é conhecido depois, a NT antecipa que será implementado um evento de mesma estrutura. Cada NFS-e pode vincular até 99 transações de pagamento.

image.png

O elo com o Split Payment

Não é coincidência o grupo carregar idTransacao, tpMeioPgto e o CNPJBasePSP. Esse é exatamente o vocabulário do mecanismo de Split Payment da LC 214/2025: para que o prestador de serviço de pagamento (PSP) consiga segregar e recolher IBS/CBS na liquidação, a NFS-e precisa entregar a “cola” entre o documento fiscal e a transação financeira. O gPgtoVinc é a peça da NFS-e que viabiliza essa amarração.

Conclusão

Se for priorizar, comece pelo que quebra contrato: a mudança de tipo do CNPJ (2.1), o merge em vAjusteBC com as renomeações de campos calculados (2.3), o bensMoveis (2.7) e as renomeações de bens imóveis (2.6). Uma varredura textual no código pelos nomes antigos — vDedRed, gReeRepRes, vCalcDR, vCalcReeRepRes, vCalcDedRedIBSCBS, gDedRedIBSCBS, gLocBensMoveis — resolve metade do mapeamento de impacto.

Em paralelo, as mudanças de obrigatoriedade do Simples Nacional (2.4) exigem revisar a leitura dos campos que deixaram de ser mandatórios. Já as notas de ajuste (2.2) e o gPgtoVinc (2.8) são funcionalidades novas: vale desenhar a arquitetura desde já, mas sem congelar as validações das notas de ajuste, que ainda estão tachadas e em evolução.

Cronograma: ainda não publicado. A NT informa que o calendário de implantação das funcionalidades sairá “nas próximas semanas” no portal da NFS-e.

Regras voláteis: parte das regras de notas de ajuste está tachada nos anexos, sinalizada como em evolução.

Anexos a acompanhar: AnexoVI-LeiautesRN_RTC_IBSCBS v1.04.00 (leiaute consolidado + RN; ao entrar em produção será identificado como ANEXO_I-SEFIN_ADN-DPS_NFSe-SNNFSe) e AnexoVII-IndOp_IBSCBS v1.02.00 (indicadores de operação do campo cIndOp, baseados no art. 11 da LC 214/2025).

Origem: Marco Paulo Viana - Arquiteto Fiscal em Software e Compliance Advisor