Novo Layout da NFS-e na Reforma Tributária: Nota Técnica 009.2026

No dia 4 de junho de 2026, a Secretaria-Executiva do Comitê Gestor da NFS-e publicou a Nota Técnica nº 009, que adapta o layout da Nota Fiscal de Serviço eletrônica à Reforma Tributária do Consumo.

Dessa vez, o foco está quase todo no leiaute do XML: campos que mudam de tipo, grupos que se fundem, fórmulas de base de cálculo que ganham novas variáveis e um conjunto de ajustes importantes para o Simples Nacional.

Se você desenvolve ou mantém um sistema de gestão com emissão de NFS-e, esse é o tipo de publicação que merece atenção, pois afeta diretamente tabelas, campos e rotinas do módulo fiscal do seu software.

Neste artigo, vou destrinchar cada bloco da NT 009, apresentando os campos e as fórmulas que receberam alterações e traduzindo o que cada mudança significa na prática para desenvolve sistemas.

O que é a Nota Técnica 009 da NFS-e?

A Nota Técnica SE/CGNFS-e nº 009 é um documento que atualiza o leiaute da NFS-e padrão nacional, complementando e ajustando o que já havia sido definido nas notas técnicas anteriores.

Resumidamente, essa NT trás atualizações na estrutura técnica do XML da NFS-e para acomodar melhor o IBS, a CBS e outras novidades da Reforma Tributária.

Junto com a nota, foram republicados dois anexos, que são onde mora o detalhe que interessa a quem integra:

• AnexoVI-LeiautesRN_RTC_IBSCBS-V1.04.00, que traz o layout consolidado da NFS-e com os novos grupos de IBS e CBS e as regras de negócio da DPS.
• AnexoVII-IndOp_IBSCBS_V1.02.00, com a tabela de códigos indicadores da operação, referenciados no campo cIndOp da DPS, baseada no art. 11 da Lei Complementar nº 214/2025.

Vale registrar uma informação que muda o seu planejamento: a própria nota avisa que o cronograma de implantação das funcionalidades ainda será publicado no portal da NFS-e nas próximas semanas.

Ou seja, você já tem o desenho técnico para começar a estudar e modelar, mas as datas de homologação e produção ainda não estão fechadas.

Novo CNPJ alfanumérico

A primeira atualização parece pequena e é uma das mais perigosas. Todos os campos de CNPJ no leiaute tiveram o tipo alterado de numérico (N) para caractere (C), para contemplar o novo formato alfanumérico do CNPJ, que entra em vigor a partir de julho de 2026.

Para quem desenvolve, essa mudança de tipo é exatamente o tipo de coisa que derruba sistema sem dar aviso claro. Pense em tudo que assume que CNPJ é um número:

• Colunas de banco tipadas como inteiro ou numérico vão truncar ou rejeitar valores com letras.
• Validações por expressão regular que esperam apenas dígitos passam a falhar em CNPJs válidos.
• Rotinas de cálculo de dígito verificador escritas para caracteres numéricos precisam ser revistas, porque o cálculo do novo CNPJ considera o valor dos caracteres alfanuméricos.

A correção não é difícil, mas precisa ser feita em toda a cadeia, do formulário ao banco, passando pelas validações e pelo serviço que monta o XML.

Se você ainda não tratou o CNPJ alfanumérico no seu sistema, recomendo começar por aí, porque o prazo de julho é curto. Já temos um conteúdo dedicado a CNPJ alfanumérico que explica o formato em detalhe.

O que muda para o Simples Nacional na NFS-e

Esse é o bloco mais relevante para boa parte do público de SaaS, porque uma fatia grande dessas empresas, e dos clientes dessas empresas, é optante do Simples Nacional.

A NT 009 trouxe um conjunto de campos novos para que a NFS-e destaque corretamente IBS e CBS quando esses tributos são apurados pelo Simples.

Na DPS (a Declaração de Prestação de Serviços, o documento que origina a NFS-e), as mudanças foram:

• O campo opSimpNac ganhou um novo valor de domínio, o 4 - Optante Pendente. Ele atende a situação em que o prestador tem a opção pelo Simples ainda pendente de regularização ou julgamento. Na prática, o seu cadastro de cliente precisa de mais um estado possível, além de não optante, MEI e ME/EPP.
• Entrou o campo regApIBSCBSSN, que indica o regime de apuração do IBS e da CBS para o optante do Simples. Os valores são: 1 para IBS e CBS apurados pelo Simples; 2 para CBS pelo Simples e IBS pelo regime regular; e 3 para ambos pelo regime regular. Esse campo é a tradução técnica, dentro do XML, da decisão que vem sendo chamada de Simples híbrido. Quem escreve o sistema precisa entender que essa escolha é por contribuinte e impacta o cálculo.
• Entrou o campo cAtvSN, código de enquadramento da atividade conforme a Lei Complementar nº 123/2006. O domínio cobre Anexo III, Anexo IV, Anexo V, atividades sujeitas ao Fator R, serviços contábeis com ISS fixo, locação de bens móveis e operações sem incidência de ISS, entre outros.

Na NFS-e (o documento resultante), entraram:

• O campo vReceitaBrutaSN, que representa a receita bruta do optante do Simples e serve de base para a apuração dos tributos do regime. A fórmula é vReceitaBrutaSN = vServ - descIncond - vCalcAjusteBCIBSCBS - vCalcAjusteBCISSQN, sendo que a parcela de vCalcAjusteBCISSQN só entra quando o ajuste por documentos for do tipo 9 - Profissional parceiro.
• O grupo gTribSN, que detalha a composição do IBS e da CBS para o optante, com os campos pIBSSN (alíquota do IBS), vIBSSN (valor do IBS), pCBSSN (alíquota da CBS) e vCBSSN (valor da CBS).

Há um detalhe técnico nesse bloco que merece destaque, porque é o tipo de mudança que mais quebra uma integração que já funcionava. Para acomodar o grupo do Simples, alguns campos que antes eram obrigatórios tiveram a ocorrência alterada e deixaram de ser. São eles:

• vIBSTot,
• gIBSUFTot
• gIBSMunTot
• pCredPresCBS
• vCredPresCBS
• vCBS.

Se a sua validação interna ainda trata esses campos como obrigatórios, ela vai rejeitar notas válidas. Revise as regras de obrigatoriedade desses pontos.

Para entender a lógica tributária por trás dessas escolhas de regime, vale a leitura do nosso material sobre o Simples Nacional na Reforma Tributária.

Notas de ajuste, merge de grupos e novas fórmulas de base de cálculo

A NT 009 introduziu a possibilidade de a NFS-e funcionar como nota de ajuste, de crédito ou de débito. O campo finNFSe foi deslocado e teve o domínio ampliado para 0 - NFS-e regular, 1 - NFS-e de crédito e 2 - NFS-e de débito.

Quando a finalidade é débito, entra o campo tpNFSeDebito, com seis tipos possíveis, como transferência de créditos para cooperativas, anulação de crédito por saídas imunes ou isentas, multa e juros, e pagamento antecipado. Quando é crédito, entra o tpNFSeCredito, com dois tipos. Há também o grupo gIBSCBSAjuste, com os campos vIBS e vCBS a ajustar.

Aqui cabe uma ressalva honesta, que a própria nota faz: parte das regras de obrigatoriedade ligadas às notas de ajuste foi inserida na planilha de regras de negócio, porém marcada como tachada, porque ainda está em evolução e vai mudar.

Então dá para você começar a modelar a estrutura de dados, mas implementar a regra de validação definitiva agora é prematuro.

A mudança mais trabalhosa para quem já tinha integração rodando é a unificação de grupos. Os grupos vDedRed e gReeRepRes, que tratavam de ajustes nas bases de cálculo do ISSQN, do IBS e da CBS, foram fundidos em um único grupo chamado vAjusteBC.

A justificativa oficial é concentrar campos de mesmo teor e dar mais clareza. O efeito para o seu código é refatoração: o caminho dentro do XML muda e vários campos foram renomeados.

As renomeações que quebram o mapeamento direto são:

• vCalcDR passou a se chamar vCalcAjusteBCISSQN.
• vCalcReeRepRes passou a vCalcAjusteBCIBSCBS.
• vCalcDedRedIBSCBS passou a vCalcAjusteBCLocImoveis.

Além disso, três tipos de ajuste antigos foram descontinuados por ficarem redundantes com os novos códigos: 1 - Alimentação e bebidas/frigobar, 3 - Produção Externa e 4 - Reembolso de despesas.

As situações que esses tipos cobriam passam a ser representadas pelos códigos 103, 104 e 199, conforme o caso. Se o seu sistema tem esses valores antigos gravados ou em uso, eles precisam ser remapeados.

As fórmulas de base de cálculo também mudaram. A base do ISSQN passou a ser vBC = vServ - descIncond - (vAjusteBCISSQN + vCalcAjusteBCISSQN) - (vRedBCBM ou VCalcBM), somando ajustes por percentual e por documentos.

A base do IBS e da CBS traz uma característica que exige atenção redobrada de quem programa, porque ela muda conforme o ano:

vBC = vServ - descIncond - vCalcAjusteBCIBSCBS ou
      vCalcAjusteBCLocImoveis - vISSQN - vPIS - vCOFINS   (até 2026)

vBC = vServ - descIncond - vCalcAjusteBCIBSCBS ou
      vCalcAjusteBCLocImoveis - vISSQN                    (de 2027 até 2032)

Repare que PIS e COFINS entram na subtração até 2026 e saem da conta a partir de 2027. Isso significa que você não pode fixar uma única fórmula no código. Precisa de lógica condicional por ano-calendário, e essa lógica tem que estar correta antes da virada de exercício, não depois.

gPgtoVinc: nota fiscal vinculada ao pagamento

Para quem opera plataforma, intermedeia pagamento ou faz split, esse é o ponto mais estratégico da NT 009. Foi criado o grupo gPgtoVinc, que vincula a NFS-e à transação de pagamento que a originou. É possível associar até 99 transações de pagamento a uma mesma nota.

Dentro do grupo, no subgrupo pgto, estão os campos:

• nPag, numerador único de cada pagamento.
• idTransacao, o identificador específico da transação financeira.
• tpMeioPgto, o meio de pagamento, com um domínio que inclui boleto, Pix QRCode dinâmico, TED, Pix por chave ou QRCode estático, Pix automático e TEF.
• CNPJReceb, o CNPJ completo de quem recebe o pagamento.
• CNPJBasePSP, o CNPJ base da instituição financeira ou de pagamento usada por quem recebe.

O detalhe que torna isso relevante para SaaS está na própria descrição dos campos, que cita expressamente o recebedor como podendo ser “fornecedor, plataforma, ou outra entidade que receba o pagamento do adquirente”.

Através dessa alteração, o fisco está construindo uma ponte entre o documento fiscal e o trilho financeiro, com identificação do prestador de serviço de pagamento.

Se você já tem os dados de transação no seu sistema, o que normalmente é o caso de quem processa pagamento, esse grupo conecta diretamente o que você já guarda ao que a nota agora pode informar.

Para quem trabalha com repasses e divisão de valores, vale revisar como você estrutura essa informação. Nosso conteúdo sobre split de notas fiscais ajuda a contextualizar.

O que fazer agora no seu sistema?

Reunindo o que a NT 009 traz, este é um roteiro objetivo de adaptação:

1. Trate o CNPJ como texto em toda a cadeia. Ajuste tipos de coluna, validações e cálculo de dígito verificador antes de julho.
2. Amplie o cadastro de cliente Simples Nacional. Inclua o estado de optante pendente, o regime de apuração de IBS e CBS e o código de atividade do Simples.
3. Remapeie os grupos de ajuste. Migre o que estava em vDedRed e gReeRepRes para o novo vAjusteBC e converta os tipos de ajuste descontinuados para os códigos atuais.
4. Implemente a fórmula de base de cálculo com transição por ano. Garanta que PIS e COFINS saiam da conta do IBS e da CBS a partir de 2027.
5. Revise as regras de obrigatoriedade. Os campos que deixaram de ser obrigatórios por causa do grupo do Simples não podem mais ser tratados como obrigatórios na sua validação.
6. Avalie o gPgtoVinc. Se você processa pagamento, mapeie como vincular transação e PSP à nota.

Lembre que o cronograma oficial de implantação ainda vai sair. Use esse intervalo para fazer o trabalho de modelagem e teste sem pressa, e deixe a entrada em produção alinhada às datas que a SE/CGNFS-e publicar.

A camada que você não precisa reconstruir

Uma virada de leiaute como essa expõe quanto trabalho existe em manter a emissão fiscal por conta própria. A cada nota técnica, alguém precisa ler o documento, comparar versões de schema, ajustar o código de comunicação com o ambiente nacional, tratar as novas rejeições e validar tudo em homologação antes de subir para produção. E isso se repete a cada nova publicação.

Esse é justamente o trabalho que a Spedy assume por você. Com a nossa API, o seu time cuida do que é seu, a regra de negócio e os dados do seu produto, enquanto a infraestrutura fiscal, incluindo o acompanhamento de cada nota técnica e a adequação ao novo layout, fica com a gente.

Você integra uma vez e deixa de reescrever o conector a cada mudança do fisco.

Se você desenvolve um SaaS e quer emitir nota fiscal com uma requisição, sem virar refém do calendário de notas técnicas, conheça a API Spedy.

Perguntas frequentes

A Nota Técnica 009 cria um novo imposto ou muda a forma de apuração do ISSQN? Não. A NT 009 atualiza o leiaute da NFS-e padrão nacional para acomodar melhor o IBS e a CBS. Ela complementa as notas técnicas anteriores e não altera, neste momento, a forma de apuração do ISSQN.

Quando as mudanças da NT 009 entram em vigor? A própria nota informa que o cronograma de implantação das funcionalidades será publicado no portal da NFS-e nas próximas semanas. Até lá, há o desenho técnico para estudo e modelagem, mas as datas de homologação e produção ainda não estão definidas.

Uso uma API de emissão de notas. Preciso me preocupar com a NT 009? Sim. A API cuida da comunicação com o fisco e do acompanhamento das versões de schema, mas o seu sistema continua sendo a origem dos dados. Mudanças de tipo de campo, novos campos do Simples Nacional e alterações de obrigatoriedade afetam o seu cadastro, o seu banco e as suas validações.

O que muda para clientes do Simples Nacional na NFS-e? Foram criados campos para indicar o regime de apuração de IBS e CBS (regApIBSCBSSN), o enquadramento da atividade (cAtvSN), a receita bruta (vReceitaBrutaSN) e um grupo de composição de IBS e CBS para o optante (gTribSN). Além disso, o campo opSimpNac passou a ter a opção de optante pendente.