Schema XML da NFS-e nacional: o que muda na sua integração e onde estão os pontos de atenção
Guia técnico para times que precisam adaptar a camada de integração ao padrão DPS sem reescrever a base existente.
Resumo executivo
O que você vai entender neste post:
O que é o padrão DPS e como ele difere do RPS antigo no fluxo de emissão.
Quais são as 5 áreas do schema XML que mais geram retrabalho na adaptação.
Por que a NT 004 v2.00 (dezembro/2025) é a versão que vale para janeiro de 2026, mesmo com as NTs 005 e 007 já publicadas.
Como organizar a camada de integração para sobreviver à convivência entre o webservice nacional e os webservices municipais.
O que sua squad deveria estar fazendo neste mês para chegar pronta no segundo semestre.
1. O contexto: por que o schema XML mudou
Antes de 2025, cada município com NFS-e operava o próprio layout. Mais de 5.500 prefeituras no país, padrões diferentes de XML, regras de negócio inconsistentes, webservices independentes. Para a software house que atende prestadores de serviço em mais de um município, isso virou rotina de manter integrações múltiplas, cada uma com suas particularidades.
A NFS-e nacional, prevista pela Emenda Constitucional 132/2023 e detalhada pelas Notas Técnicas SE/CGNFS-e, propõe um layout único de XML, um ambiente nacional de validação e padronização da identificação do prestador através da DPS (Declaração de Prestação de Serviço).
A partir de janeiro de 2026, todos os prestadores de serviço (com regras específicas para optantes do Simples Nacional) passam a emitir NFS-e seguindo o layout da NT 004, em sua versão 2.00, publicada em 10 de dezembro de 2025. A adesão dos municípios ao ambiente nacional é gradual, mas o layout padronizado é o ponto de partida obrigatório.
Para o time de engenharia, isso significa três coisas concretas: novo schema XSD, novo fluxo de emissão via DPS, e novo conjunto de validações no ambiente da Sefin Nacional. Adaptar ou ignorar não é mais uma escolha.
2. DPS, NFS-e e Sefin Nacional: o fluxo em uma frase
Para quem está chegando agora ao tema, vale alinhar o vocabulário antes de mergulhar.
A DPS (Declaração de Prestação de Serviço) é o documento que o sistema emissor preenche e envia. Pense nela como o equivalente ao RPS do modelo antigo, com diferenças importantes: o layout é nacional, a assinatura digital é obrigatória em todos os casos, e o destino é único.
A Sefin Nacional é o ambiente da Receita Federal que recebe a DPS, valida estrutura, calcula tributos e gera a NFS-e em formato XML. A partir desse XML, o documento fiscal é compartilhado com o município competente e fica disponível para consulta pelo prestador, tomador e ADN (Ambiente de Dados Nacional).
Em uma frase: o emissor preenche a DPS, assina, envia para a Sefin Nacional, e recebe a NFS-e autorizada. O município entra como destinatário do dado, não mais como porta de entrada.
3. Os 5 pontos do schema que mais geram retrabalho
Na adaptação ao novo schema, há 5 áreas que concentram a maior parte das rejeições e dos bugs em produção. Quem trata isso bem desde o início economiza meses de patch.
3.1. Convivência com layouts municipais existentes
O webservice legado ABRASF 2.03 ainda existe e ainda é usado por muitos municípios em paralelo. O novo padrão nacional não desliga o antigo da noite para o dia. Sua camada de integração precisa decidir, por município, qual fluxo é o ativo no momento da emissão. Isso não é if/else simples: é máquina de estados com fallback.
3.2. Campos obrigatórios novos do grupo IBSCBS
A NT 004 criou o grupo IBSCBS tanto na DPS quanto na NFS-e gerada. Centraliza informações sobre os novos tributos (IBS e CBS). Importante: a NT 004 v2.00, publicada em 10 de dezembro de 2025, suspendeu as regras de validação de obrigatoriedade dos campos desse grupo nos ambientes de Produção Restrita e Produção no início de 2026. Em prosa simples: os campos existem no layout, mas a Sefin Nacional não vai rejeitar a emissão se vierem em branco, no curto prazo. Aproveite o período de carência para implementar com tempo.
3.3. Identificação do prestador (DPS) e assinatura digital
A DPS exige assinatura digital padrão ICP-Brasil, válida e não revogada. A rejeição mais comum em ambiente de homologação é a rejeição E1235 (XML não aderente ao XSD oficial), seguida de problemas de assinatura. Implementar validação local antes do envio reduz drasticamente o ruído de logs em produção.
3.4. Tabelas externas referenciadas
O layout referencia várias tabelas auxiliares: cIndOp (Código Indicador da Operação), cTribNac (Código de Tributação Nacional), Tabela de CST e Classificação Tributária (cClassTrib), Tabela de Crédito Presumido (cPres), NCM-SH e NBS. Essas tabelas são atualizadas pelo CGNFS-e periodicamente. Manter um cache local versionado, com refresh automatizado, evita rejeição em produção quando o Fisco atualiza um código.
3.5. Estratégia de versionamento durante a transição
A NT 005 (publicada em 19 de novembro de 2025) já trouxe novos campos e grupos, mas a previsão era de implementação futura. A NT 007 (7 de fevereiro de 2026) trouxe ajustes em PIS, COFINS e na tabela cIndOp. O ponto é: o layout vai mudar nos próximos 12 meses. Sua arquitetura precisa lidar com versionamento de schema de forma estruturada (não com if-else espalhados pelo código).
4. Por que a NT 004 v2.00 é a versão que importa agora
Há confusão recorrente sobre qual versão da Nota Técnica é a vigente. Vale clarificar.
A NT 004 v1.00, publicada em 19 de agosto de 2025, introduziu os ajustes nos agrupamentos e campos do layout para suportar o IBS e a CBS. A v2.00, publicada em 10 de dezembro de 2025, manteve a mesma estrutura, mas suspendeu a validação de obrigatoriedade dos campos do grupo IBSCBS em ambiente de Produção Restrita e Produção.
A NT 005 (19 de novembro de 2025) trouxe novos campos e grupos voltados para evoluções futuras do ambiente IBS/CBS. Apesar de já publicada, sua implementação está prevista para data futura, ainda a ser divulgada no Portal da NFS-e.
A NT 007 (7 de fevereiro de 2026), na versão 1.0, promoveu ajustes estruturais em campos de PIS e COFINS, além de atualizações na tabela de códigos indicadores da operação (cIndOp). Esta NT impacta diretamente o layout da DPS.
Em resumo prático: para entrar em janeiro de 2026 sem rejeição, o layout de referência é o da NT 004 v2.00. As NTs 005 e 007 são para o roadmap dos próximos meses.
5. Como pensar a camada de integração na prática
A pior arquitetura para esse cenário é ter código de emissão por município, em arquivos separados, sem camada de abstração entre o sistema emissor e o destino. Quem fez isso há 3 ou 4 anos sente agora.
A camada saudável tem 3 elementos básicos. Primeiro, abstração da identificação do destino: sua aplicação não decide qual webservice usar dentro do código de negócio. Existe uma camada de roteamento que, dado o município do prestador e a data de operação, retorna o endpoint correto.
Segundo, validação local antes do envio. Validar XSD localmente, com schema atualizado, reduz em mais de 60% o ruído de rejeições da Sefin Nacional. Vale o investimento.
Terceiro, versionamento de schema como cidadão de primeira classe. Cada versão do layout tem seu XSD, suas regras de negócio, suas tabelas referenciadas. Quando a NT 005 ou outra entrar em produção, sua aplicação precisa saber qual versão usar com base em data e município, não com base em variável de ambiente.
6. O que fazer nas próximas 4 semanas
Para times que ainda não começaram, há um roadmap mínimo razoável para os próximos 30 dias.
1. Baixe os schemas oficiais da NT 004 v2.00 no Portal Nacional da NFS-e e configure validação local.
2. Mapeie em quais municípios os seus clientes operam e qual webservice cada um está usando hoje (nacional, municipal ou misto).
3. Defina o cronograma de testes em ambiente de Produção Restrita.
4. Implemente o grupo IBSCBS na DPS, mesmo com a validação desligada, para que a transição quando ela for ligada seja apenas um deploy.
5. Documente o roteamento e o versionamento de schema. Quem entrar na squad nos próximos 6 meses não pode descobrir essas regras lendo código.
7. Perguntas frequentes
1. A NFS-e nacional substitui completamente os webservices municipais?
Não no curto prazo. Os municípios estão migrando para o ambiente nacional de forma gradual. Para os próximos meses, é preciso suportar os dois fluxos em paralelo.
2. Qual a diferença entre DPS e RPS?
DPS (Declaração de Prestação de Serviço) é o documento de entrada do novo modelo nacional. O RPS era o equivalente no modelo antigo, mas com layout municipal próprio. A DPS é padronizada nacionalmente, tem assinatura digital obrigatória e é enviada à Sefin Nacional, que valida e gera a NFS-e oficial.
3. O que acontece se eu emitir com o layout da NT 004 v1.00 a partir de janeiro de 2026?
O layout estrutural é o mesmo entre v1.00 e v2.00. A diferença é a suspensão de algumas validações em v2.00. Emitir com schemas v1.00 não gera rejeição estrutural, mas pode haver inconsistência em campos relacionados ao grupo IBSCBS quando o Fisco voltar a ligar as validações.
4. Quando a NT 005 entra em produção?
A NT 005 está publicada desde novembro de 2025, mas sua implementação efetiva em ambiente de Produção e Produção Restrita está prevista para data futura, ainda a ser divulgada pelo Comitê Gestor da NFS-e Nacional.
5. Posso continuar usando o webservice ABRASF 2.03?
Para os municípios que ainda não migraram para o ambiente nacional, sim. Mas a tendência é de migração progressiva. Manter compatibilidade com ABRASF 2.03 em paralelo ao padrão nacional é o desenho mais seguro para os próximos 12 a 24 meses.
6. Qual a melhor estratégia de testes para a virada?
Configure ambiente de Produção Restrita da Sefin Nacional, monte uma bateria automatizada de testes por município (não por cenário genérico), e teste casos limítrofes (rejeições por validação, contingência, retorno fora do timeout esperado).
Referências
BRASIL. Receita Federal. Nota Técnica SE/CGNFS-e nº 004/2025, versão 1.00, de 19 de agosto de 2025. Portal Nacional da NFS-e. https://www.gov.br/nfse
BRASIL. Receita Federal. Nota Técnica SE/CGNFS-e nº 004/2025, versão 2.00, de 10 de dezembro de 2025. Portal Nacional da NFS-e. https://www.gov.br/nfse
BRASIL. Receita Federal. Nota Técnica SE/CGNFS-e nº 005/2025, versão 1.1, de 19 de novembro de 2025. https://www.gov.br/nfse
BRASIL. Receita Federal. Nota Técnica SE/CGNFS-e nº 007/2026, versão 1.0, de 7 de fevereiro de 2026. https://www.gov.br/nfse
BRASIL. Presidência da República. Lei Complementar nº 214, de 16 de janeiro de 2025. https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp214.htm
BRASIL. Congresso Nacional. Emenda Constitucional nº 132, de 20 de dezembro de 2023. https://www.planalto.gov.br/ccivil_03/constituicao/emendas/emc/emc132.htm
Migrate ao seu lado em NFS-e nacional
A NFS-e nacional vai trazer mais Notas Técnicas, mais campos obrigatórios e mais ajustes de layout nos próximos 12 meses. Cada uma dessas mudanças entra na squad como sprint extra. Para software house que quer manter foco de produto, o caminho é terceirizar a camada de conformidade fiscal para quem faz isso como negócio principal.
A Migrate opera emissão NFS-e em mais de 3.100 municípios brasileiros, com integração via API REST, suporte ao padrão nacional e aos webservices municipais legados. Se faz sentido conversar sobre como sua arquitetura pode integrar com o InvoiCy, fale com um especialista técnico.
