Erros no XML da NFS-e Nacional são comuns e bloqueiam a emissão. Veja como identificar o campo exato que falhou e corrigir de forma segura.
A cena é conhecida: você importa o XML para a NFS-e Nacional, clica em transmitir e recebe uma rejeição enigmática. O sistema retorna um código e uma mensagem genérica, o cliente pressiona pelo documento e o time perde tempo testando tentativas aleatórias.
Apesar de frustrante, esse erro geralmente está concentrado em poucos campos mal preenchidos, ausentes ou com formatação fora do padrão aceito pelo validador do serviço municipal ou do padrão nacional.
Em 2026, com mais municípios aderindo ao modelo unificado, a consistência do XML ganhou ainda mais peso. A boa notícia é que há um método simples e repetível para localizar o ponto exato da falha: ler corretamente o retorno, validar contra o schema, confirmar regras municipais e ajustar o cadastro fiscal envolvido.
Ao final deste artigo, você saberá interpretar as mensagens de rejeição, encontrar o campo problemático (inclusive por caminho XPath), conferir se a regra é do município ou do padrão nacional e aplicar a correção com segurança — reduzindo retrabalho e evitando novas rejeições.
A rejeição por XML acontece quando o arquivo de nota em formato estruturado não passa pelas validações técnicas e de negócio do serviço de NFS-e. O sistema confronta cada campo com um conjunto de regras: presença obrigatória, tipo e tamanho do dado, padrões de código (como códigos de serviço), relação entre campos (por exemplo, “ISS retido” exige percentual) e aderência às regras do município competente. Se algo diverge do esperado, a transmissão falha e a rejeição retorna com um código e uma descrição.
Surge na emissão de serviços por prestadores de todos os portes, sobretudo ao integrar ERPs, gerar lotes ou migrar para o padrão nacional. Escritórios que atendem múltiplos municípios sentem mais, pois as regras locais convivem com o esquema nacional. Times fiscais e desenvolvedores de integrações são diretamente afetados, mas o impacto chega ao cliente final quando a nota não sai a tempo.
A raiz do problema costuma estar em quatro frentes. Primeiro, campos obrigatórios ausentes ou em branco, como código de serviço municipal, natureza da operação ou identificação do tomador. Segundo, formatação inválida: CNPJ/CPF, CEP, UF, datas, valores e alíquotas com casas decimais fora do padrão aceito. Terceiro, inconsistências de negócio, como marcar ISS retido sem informar o percentual, ou escolher um código de serviço incompatível com o município.
Quarto, cadastro fiscal desatualizado: CNAE, regime tributário, inscrição municipal e responsabilidade tributária do tomador. Insight: muitos erros não estão na “tag visível”, mas em dependências silenciosas — um município pode exigir “código de tributação do município” além do “código do serviço”, e a ausência desse relacionamento quebra a validação.
1 - Reproduza o erro em homologação e guarde o retorno completo. Registre o código e a descrição exata da rejeição, inclusive o caminho do campo (quando disponível).
2 - Valide o XML no schema do provedor (XSD) usado pelo município/padrão nacional. A validação aponta a tag específica com tipo/tamanho incorreto ou ausência.
3 - Mapeie o campo no ERP: identifique de onde vem o dado (cadastro do prestador, do tomador ou item de serviço). Confirme se o município exige códigos próprios além do padrão nacional.
4 - Ajuste a regra de negócio: se houver ISS retido, informe o percentual; se o serviço exigir retenções federais, verifique se o cenário realmente se aplica e preencha apenas quando devido.
5 - Reenvie e documente a correção. Anexe o XML antes/depois e crie um checklist interno para o município, evitando recorrência.
É frequente tentar resolver trocando campos aleatoriamente, o que mascara a causa real. O erro mais comum é marcar retenção de ISS sem preencher a alíquota correspondente; o segundo é usar um código de serviço genérico que o município não reconhece. Outro tropeço: CNPJ ou inscrição municipal com zeros à esquerda suprimidos por formatação do ERP.
Exemplo prático 1: prestador optante pelo Simples marca “ISS retido” porque o tomador exige, mas esquece o percentual — rejeição imediata.
Exemplo prático 2: serviço de consultoria cadastrado com código municipal de “limpeza”, o schema aceita a tag, mas a regra de negócio municipal rejeita por incompatibilidade. Alerta: desconfie de “validadores” não oficiais que pedem certificado digital para “corrigir automaticamente” o XML; concentre-se no ambiente oficial de testes e no schema do provedor.
Localizar o campo errado reduz o tempo de emissão, melhora a previsibilidade de prazos e diminui o atrito com o cliente. Na prática, vale formalizar checklists por município, revisar cadastros críticos (CNAE, inscrição municipal, responsabilidade do tomador) e padronizar a entrada de dados no ERP.
No aspecto jurídico-tributário, lembre que a Lei Complementar 116/2003 disciplina o ISS e a competência municipal; divergências entre o código de serviço e a legislação local costumam motivar rejeições. Se o tomador for responsável pelo recolhimento, a indicação do percentual e da condição de retenção precisa fechar com a norma do município. Documentar os critérios adotados e guardar as memórias de cálculo protege você em fiscalizações.
Quase sempre nascem de obrigatórios não preenchidos, formatos inválidos ou regras municipais ignoradas. Ao adotar um processo simples — reproduzir o erro, validar no schema, mapear a origem do dado no ERP, ajustar a regra e reenviar — você identifica rapidamente o campo exato e evita retrabalho.
Daqui em diante, acompanhe os comunicados do seu município, mantenha cadastros fiscais alinhados e crie checklists por cidade e por tipo de serviço. Quer se aprofundar? Vale revisar rotinas de retenção de ISS e responsabilidades do tomador, tema que costuma puxar várias rejeições. Se este conteúdo ajudou, considere ler nosso material sobre parametrização de códigos de serviço e prevenção de glosas na emissão.
Aproveite para compartilhar clicando no botão acima!
Visite nosso site e veja todos os outros artigos disponíveis!