NFS-e: um gestor financeiro, milhares de municípios e uma nota fiscal que ainda não fala a mesma língua

O gestor financeiro de uma grande empresa de serviços chega ao escritório, abre o notebook, pega o primeiro café do dia e encontra um e-mail com o assunto escrito em letras maiúsculas:

“URGENTE — ADEQUAÇÃO DA NFS-e PARA IBS E CBS.”

Ele já conhece o ritual.

Antes mesmo de terminar o café, encaminha a mensagem para Tax, Fiscal, Contabilidade, Faturamento e Tecnologia. Em poucos minutos, a agenda começa a ganhar reuniões, o grupo de mensagens passa a receber prints de notas técnicas e alguém pergunta se o desenvolvimento deve seguir a NT 004 ou aguardar a NT 009.

A pergunta parece objetiva.

A resposta, como quase tudo na Reforma Tributária, não é.

Para uma empresa que presta serviços em diversos municípios, a Nota Fiscal de Serviço eletrônica nunca foi exatamente um documento nacional. Cada prefeitura construiu seu próprio caminho, seu próprio leiaute, suas regras, seus fornecedores e, em alguns casos, até sua própria interpretação sobre como uma nota deveria funcionar.

Durante anos, as empresas aprenderam a conviver com esse cenário. Criaram interfaces, robôs, planilhas, conectores, arquivos TXT, integrações locais e uma coleção de manuais municipais que provavelmente ocupa mais espaço do que deveria em qualquer servidor corporativo.

Então chegou a promessa do padrão nacional.

A mesma estrutura. A mesma linguagem. Um Ambiente de Dados Nacional. Uma NFS-e capaz de alimentar a apuração do IBS e da CBS.

Parecia o começo da simplificação.

Mas nosso gestor logo descobre que, antes de chegar à terra prometida da padronização, precisará atravessar um caminho formado por notas técnicas sobrepostas, municípios formalmente aderentes, sistemas locais ainda em funcionamento e datas que mudam justamente quando a empresa termina o desenvolvimento.

É nesse momento que começa a verdadeira jornada.

O primeiro desafio: afinal, seguimos a NT 004 ou a NT 009?

Na primeira reunião do dia, Tax apresenta a NT 004. Tecnologia abre o leiaute em uma segunda tela. Faturamento pergunta quais campos precisam aparecer na nota. O fornecedor do sistema informa que existe uma versão mais recente, mas que ela ainda não está disponível no ambiente produtivo.

Alguém então faz a pergunta inevitável:

“Estamos desenvolvendo com base em uma nota técnica que já foi substituída?”

A resposta é: sim e não.

A Nota Técnica nº 009 foi publicada em 4 de junho de 2026 e trouxe uma evolução importante do leiaute da NFS-e. Entre as novidades estão a adaptação ao CNPJ alfanumérico, a criação de estruturas específicas para notas de ajuste de IBS e CBS, novos campos para notas de débito e crédito, a vinculação de pagamentos e a reorganização das informações relacionadas aos ajustes da base de cálculo.

Portanto, não é correto dizer que a NT 009 ainda não foi publicada.

O problema é outro: ela foi publicada, mas ainda não foi implantada.

O próprio Portal Nacional da NFS-e informa que a NT 009 não estaria disponível nos ambientes de produção e de produção restrita em. Para a obrigatoriedade que estava prevista para 3 de agosto, a orientação técnica era utilizar como base a NT 004, acrescida do campo tpRetPisCofins introduzido pela NT 007.

Nosso gestor respira fundo.

A empresa, portanto, precisa conhecer a NT 009, porque ela representa a direção futura do documento. Mas não pode simplesmente colocar todo o seu conteúdo em produção, porque o ambiente nacional ainda não está preparado para recebê-lo.

É como receber o mapa do próximo trecho da viagem sem saber quando a estrada será aberta.

Na prática, a arquitetura precisa ser preparada em camadas. A solução atual deve respeitar aquilo que o ambiente aceita hoje, mas o desenvolvimento não pode ser tão rígido a ponto de exigir uma nova reconstrução quando a NT 009 entrar em produção.

A conversa deixa de ser apenas “qual nota técnica devemos utilizar?” e passa a ser “como construiremos um sistema capaz de acompanhar versões diferentes sem interromper o faturamento?”

Essa é uma pergunta muito mais difícil.

E também muito mais cara.

A falsa sensação de que todos estão no mesmo portal

Depois de superar a primeira discussão, o gestor abre a planilha com os municípios em que a empresa presta serviços.

São dezenas de localidades, diferentes sistemas, diferentes fornecedores e diferentes formas de emissão.

Em alguns municípios, a empresa utiliza webservice. Em outros, envia arquivos em lote. Em outros, ainda depende de TXT. Há localidades em que o leiaute foi atualizado, enquanto outras sequer divulgaram uma documentação clara com os campos de IBS e CBS.

Alguém comenta que o problema seria resolvido se todos os municípios aderissem ao padrão nacional.

Mas aqui surge a segunda surpresa da jornada: formalmente, a adesão já aconteceu.

O painel oficial informa que todos os 5.571 entes federados estão aderentes à plataforma nacional da NFS-e, representando 100% da população e da arrecadação nacional de serviços.

Então por que a empresa continua convivendo com tantos sistemas diferentes?

Porque aderir ao sistema nacional não significa, necessariamente, abandonar o emissor municipal.

O município pode optar por utilizar o ambiente tecnológico nacional, permitindo que os contribuintes emitam a nota pelo Emissor Público Nacional ou diretamente por meio das APIs. Mas também pode continuar utilizando sua própria infraestrutura e seu próprio sistema autorizador, desde que compartilhe as NFS-e com o Ambiente de Dados Nacional, o ADN.

Essa distinção muda completamente o diagnóstico.

O problema atual não é, necessariamente, a falta de adesão formal. O problema é a diferença entre adesão, integração e prontidão operacional.

Um município pode ter aderido ao convênio e continuar utilizando seu fornecedor local. Pode compartilhar documentos com o ADN, mas ainda não ter publicado um novo leiaute para os contribuintes. Pode aceitar os campos de IBS e CBS em sua integração interna, mas manter um arquivo TXT que não contempla essas informações.

Para o gestor financeiro, isso significa que não basta marcar em uma planilha se o município aderiu ou não aderiu.

Será necessário entender como cada município aderiu, qual emissor está sendo utilizado, qual leiaute está vigente, quais campos são aceitos, como ocorre o compartilhamento com o ADN e em quanto tempo essa informação chega ao ambiente nacional.

A tão esperada padronização começa a parecer um condomínio em que todos assinaram o regulamento, mas cada apartamento ainda utiliza uma chave diferente.

O túnel do TXT

É nesse ponto da jornada que nosso gestor encontra um dos maiores obstáculos: os municípios que ainda recebem informações por arquivos TXT.

Do ponto de vista da empresa, o fluxo parece simples. O ERP produz os dados, gera o arquivo no formato municipal e o transmite ao sistema da prefeitura. O município processa o conteúdo, autoriza a nota e devolve o resultado.

Esse modelo funcionou durante anos.

Mas o novo ambiente tributário exige mais do que autorizar uma NFS-e para fins de ISS. A informação precisa chegar ao Ambiente de Dados Nacional e, no futuro, alimentar a apuração assistida do IBS e da CBS.

O ADN foi estruturado justamente como um repositório nacional de documentos fiscais, eventos, créditos, débitos e informações de apuração. Os sistemas autorizadores municipais devem compartilhar os documentos com esse ambiente, utilizando serviços de integração e estruturas padronizadas.

O TXT, entretanto, é apenas o formato de comunicação escolhido localmente entre a empresa e determinado município. Ele não é, por si só, o padrão nacional da NFS-e.

Para que o fluxo funcione, alguém precisará transformar aquelas informações municipais na estrutura nacional que será enviada ao ADN. Essa transformação poderá ocorrer no sistema da prefeitura, no fornecedor municipal ou em alguma camada intermediária de integração.

O problema aparece quando o TXT utilizado pelo contribuinte não possui campos capazes de representar todas as informações exigidas no padrão nacional.

Onde informar o Código de Classificação Tributária? Como registrar os grupos de IBS e CBS? Como identificar os ajustes de base? Como relacionar pagamentos? Como distinguir uma nota de débito de uma nota de crédito?

Se o leiaute local não possui esses campos, a empresa não consegue inventá-los no arquivo. Ela depende de uma atualização publicada pelo município ou pelo fornecedor responsável.

E, mesmo quando o município realiza a conversão internamente, surge outra preocupação: o tempo.

A nota pode ser autorizada no ambiente municipal em um momento e compartilhada com o ADN apenas depois. Se esse intervalo for relevante, a empresa poderá enxergar uma operação em sua contabilidade e em seu faturamento antes que ela apareça no ambiente nacional.

A legislação e a documentação técnica ainda precisam esclarecer com maior precisão os efeitos operacionais desse intervalo sobre a apuração assistida. Mas o risco é evidente: uma apuração alimentada por documentos que chegam em momentos diferentes poderá gerar divergências temporárias, conciliações adicionais e uma nova rotina de acompanhamento.

Nosso gestor percebe que não será suficiente conferir se a nota foi autorizada pela prefeitura.

Também será necessário confirmar se ela chegou ao ADN.

Nasce, assim, um novo controle que provavelmente não existia no fechamento anterior: a conciliação entre o ERP, o município e o ambiente nacional.

Mais um sistema. Mais um status. Mais um protocolo.

E mais um café. Qué¿

Quando a nota nasce em TXT, mas o ajuste precisa existir em XML

A aventura fica ainda mais interessante quando alguém da Contabilidade pergunta como serão emitidas as notas de débito e de crédito.

A NT 009 cria estruturas específicas para as notas de ajuste do IBS e da CBS. Foram incluídos o grupo os campos (finNFSe, tpNFSeDebito e tpNFSeCredito), permitindo identificar diferentes hipóteses de ajuste e formalizar notas de débito e crédito dentro do leiaute nacional.

No padrão nacional, essas informações fazem parte da estrutura eletrônica da DPS e da NFS-e.

Mas o que acontece quando a empresa emite por um arquivo TXT municipal?

A resposta depende do leiaute do município.

Se o sistema local continuar sendo o autorizador, ele precisará disponibilizar campos equivalentes no TXT, em uma API ou em outra interface de entrada. Depois, deverá converter essas informações para a estrutura nacional e compartilhá-las com o ADN.

Sem essa atualização, a empresa poderá até saber qual nota precisa emitir, mas não terá um campo para dizer ao sistema que se trata de uma nota de débito ou de crédito.

É como chegar ao pedágio com o dinheiro em mãos e descobrir que a cabine aceita apenas uma moeda que ainda não foi distribuída.

Existe ainda um segundo ponto: a NT 009, que contém essas estruturas, ainda não possui cronograma de implantação nos ambientes de produção. Portanto, as notas de ajuste de IBS e CBS não podem ser tratadas como uma funcionalidade plenamente operacional no padrão nacional em agosto de 2026.

Isso não impede que as empresas estudem os cenários, definam as regras e preparem os sistemas. Ao contrário, esse trabalho precisa começar agora.

Será necessário mapear quais situações exigirão notas de débito, quais poderão gerar notas de crédito, quais documentos originais deverão ser referenciados e como cada cenário será contabilizado.

Mas existe uma diferença importante entre preparar a regra de negócio e colocar o arquivo em produção.

Tax pode definir o tratamento. Contabilidade pode desenhar os lançamentos. Tecnologia pode preparar a arquitetura. O faturamento, porém, somente conseguirá emitir quando o ambiente nacional e o sistema municipal aceitarem a estrutura correspondente.

O herói, nosso gestor, começa a compreender que, nessa jornada, nem sempre estar pronto significa poder avançar.

Às vezes, significa apenas estar preparado para avançar assim que a próxima ponte for liberada.

E quando começa, de fato, a obrigatoriedade sistêmica?

Em maio e junho, os comunicados oficiais apontavam para 3 de agosto de 2026 como o momento em que os documentos fiscais eletrônicos passariam a ser rejeitados caso não apresentassem os campos de IBS e CBS. O Portal da NFS-e também indicava que, para essa etapa, seria utilizado o leiaute da NT 004, acrescido do campo introduzido pela NT 007.

As empresas fizeram o que se espera de empresas organizadas.

Mobilizaram Tax, TI, Fiscal, Contabilidade, Faturamento e fornecedores. Atualizaram sistemas, pressionaram desenvolvedores, testaram arquivos e reorganizaram cronogramas.

No Resenha Fiscal Clube, o assunto ocupou a semana. As conversas alternavam entre dúvidas técnicas, benchmarks, notícias de mercado e aquela expectativa conhecida por quem trabalha na área tributária: será que o prazo será mantido até o fim?

Em 27 de julho, a Receita Federal e o CGIBS informaram que ainda seria publicado um ato conjunto com as datas de início da obrigatoriedade dos documentos fiscais eletrônicos.

Na prática, a menos de uma semana da data que vinha orientando os projetos, o mercado ainda aguardava o cronograma definitivo.

Então chegou 1º de agosto.

A Receita Federal anunciou que as regras de validação seriam alteradas para evitar a rejeição de documentos fiscais que não contivessem as informações de IBS e CBS. O comunicado afirmou que um Ato Técnico Conjunto suspenderia a obrigatoriedade do preenchimento para documentos como NF-e, NFC-e, CT-e, CT-e OS, GTV-e, BP-e, NF3e e NFCom.

E aqui aparece mais um capítulo do suspense: a NFS-e não foi mencionada expressamente na lista apresentada pelo comunicado.

Isso não permite concluir, com segurança, que a NFS-e esteja fora da flexibilização. Mas também não permite afirmar, sem o ato técnico e sem atualização específica do Portal da NFS-e, que ela esteja automaticamente incluída.

Em 2 de agosto de 2026, portanto, a resposta mais responsável é que ainda existe uma lacuna de comunicação.

Para o leiaute da NT 009, não há data de implantação divulgada. Para as notas de débito e crédito nela previstas, também não existe uma data sistêmica definitiva. Quanto aos campos básicos de IBS e CBS na NFS-e, havia previsão de obrigatoriedade em 3 de agosto, utilizando a NT 004 e parte da NT 007, mas os últimos comunicados exigem nova confirmação específica.

Essa é a informação que o gestor gostaria de evitar levar à diretoria:

“Ainda estamos aguardando um esclarecimento oficial.”

Mas esconder a incerteza não a elimina.

A melhor decisão, nesse momento, não é interromper o projeto nem desfazer as parametrizações. É manter os sistemas preparados, acompanhar o comportamento dos ambientes, validar as regras de cada município e aguardar o ato técnico e a atualização oficial da documentação da NFS-e.

A flexibilização de uma regra de rejeição não significa que os dados deixaram de ser importantes. Significa apenas que a ausência do campo pode não bloquear o documento naquele momento.

E existe uma grande diferença entre uma nota ser autorizada e uma informação estar correta para a futura apuração.

A provação final: transformar incerteza em governança

Depois de alguns dias de reuniões, o gestor volta à mesma sala em que a jornada começou.

A situação ainda não está completamente resolvida. A NT 009 continua sem data de implantação. Os municípios continuam operando por modelos diferentes. Os arquivos TXT ainda dependem de adaptações locais. As notas de débito e crédito aguardam disponibilidade sistêmica. E o último comunicado ainda exige interpretação específica para a NFS-e.

Mas alguma coisa mudou.

No início, o gestor procurava uma única data e um único leiaute.

Agora, ele compreende que o projeto precisará ser administrado como uma transição contínua.

A empresa deverá construir uma matriz por município, identificando o sistema autorizador, o formato de emissão, a versão do leiaute, a disponibilidade dos campos de IBS e CBS, a forma de compartilhamento com o ADN e os prazos previstos pelo fornecedor local.

Também precisará separar aquilo que está disponível em produção daquilo que foi apenas publicado para uma etapa futura. A NT 004 representa a base atualmente implantada para os grupos de IBS e CBS; a NT 007 acrescenta ajustes específicos; e a NT 009 orienta a evolução futura, incluindo as notas de ajuste, mas ainda depende de cronograma.

As integrações em TXT deverão receber atenção especial. Para cada município, será necessário confirmar se haverá novo leiaute, qual será o responsável pela conversão para o padrão nacional e como a empresa acompanhará a chegada do documento ao ADN.

O fechamento financeiro também precisará evoluir. Não bastará conciliar faturamento e contabilidade. Será necessário acompanhar se as notas autorizadas localmente foram compartilhadas, se os valores chegaram corretamente ao ambiente nacional e se existem diferenças entre o documento municipal e sua representação nacional.

Nenhuma dessas atividades pertence exclusivamente ao departamento fiscal.

O Financeiro precisará compreender os efeitos sobre contas a receber, pagamentos e ajustes. A Contabilidade deverá definir os lançamentos das notas de débito e crédito. Tax será responsável pelos tratamentos e classificações. Tecnologia cuidará das versões, interfaces e integrações. Faturamento garantirá que o documento seja emitido pelo canal correto.

E o gestor terá a missão menos confortável de todas: fazer com que essas áreas avancem mesmo quando a resposta oficial ainda não chegou completa.

O retorno do herói

Na jornada clássica, o herói retorna para casa trazendo alguma coisa que não possuía quando partiu.

Nosso gestor não retorna com um sistema perfeito, uma data imutável ou um manual capaz de responder a todas as perguntas.

Ele retorna com algo mais útil: uma visão completa do risco.

Agora ele sabe que adesão municipal não significa padronização operacional. Sabe que uma nota autorizada localmente pode ainda precisar percorrer um caminho até o ADN. Sabe que uma nota técnica publicada pode não estar disponível em produção. E sabe que flexibilizar a rejeição de um documento não significa encerrar a obrigação de preparar os dados.

Também compreende a importância das comunidades técnicas.

Foi no Resenha Fiscal Clube que muitas dessas dúvidas apareceram antes de chegarem às pautas formais das empresas. Foi ali que profissionais compararam sistemas, compartilharam respostas de fornecedores, discutiram leiautes municipais e perceberam que aquele problema aparentemente isolado estava se repetindo em diferentes organizações.

Em um projeto com tantas versões, municípios e interpretações, o benchmark deixa de ser apenas uma troca informal e passa a funcionar como instrumento de antecipação de risco.

A NFS-e da Reforma Tributária ainda promete simplificação.

Mas, antes de simplificar, ela está expondo a complexidade que sempre existiu.

A diferença é que, agora, essa complexidade precisa alimentar um sistema nacional, sustentar a apuração assistida e conversar com o IBS e a CBS.

Na manhã seguinte, o gestor chega novamente ao escritório.

O café continua na mão. A caixa de e-mails continua cheia. O comunicado definitivo ainda não chegou.

Mas a empresa já não está apenas esperando.

Está mapeando municípios, preparando versões, revisando integrações e construindo controles.

Porque, na Reforma Tributária, talvez o verdadeiro herói não seja aquele que conhece todas as respostas.

É aquele que consegue manter a empresa em movimento enquanto as respostas ainda estão sendo publicadas.