Validador de XSD
Cole ou envie um XML de DPS, NFS-e, evento, pedRegEvento ou CNC e veja exatamente onde ele viola o XSD oficial do ADN — sem enviar nada de verdade, gratuito e sem login.
Validação estritamente de contrato/schema contra os XSDs oficiais do ADN extraídos diretamente das últimas publicações do Nacional (versões 1.00 e 1.01, detectadas automaticamente pelo atributo versao do próprio XML — sem seleção manual). Nenhuma regra de negócio é verificada aqui.
Nota: o XSD 1.01 publicado pelo governo tem um erro de digitação no padrão do campo serie que faria uma validação estritamente literal rejeitar XMLs reais já aceitos pela ADN em produção — este validador corrige esse ponto pontualmente para refletir o comportamento real da ADN, em vez do texto literal com o typo.
Bem formado, válido e aceito: três coisas diferentes
Um XML passa por três filtros até virar uma NFS-e. Primeiro precisa estar bem formado: tags fechadas, aninhamento correto, caracteres especiais escapados. Depois precisa ser válido contra o XSD: os elementos certos, na ordem certa, com valores no formato que o schema define. Por último precisa ser aceito pelas regras de negócio do ADN, como alíquota compatível com o município, emitente habilitado e competência coerente.
Este validador cobre os dois primeiros. Um "conforme ao XSD" aqui significa que o ADN não vai rejeitar o documento por estrutura. Ele ainda pode ser rejeitado por regra de negócio. A vantagem é saber em qual das camadas está o problema antes de gastar uma tentativa real. Mais contexto no artigo sobre XML, XSD e namespaces.
As violações de schema que mais aparecem
- Ordem dos elementos. A maior parte do schema é declarada como
xs:sequence, então ter todos os campos não basta: se dois estiverem trocados de lugar, o XML é inválido. Isso é comum quando o XML é montado a partir de um dicionário ou objeto cuja serialização não preserva ordem. - Tag vazia no lugar de tag omitida. Para um campo opcional sem valor, o certo é não gerar a tag. Um
<campo/>vazio costuma falhar no padrão de formato do campo, porque para o schema o campo existe e está com valor inválido. - Formato de número e data. Decimais usam ponto, nunca vírgula, e com o número de casas que o tipo permite. Datas e horas seguem o padrão ISO com fuso horário (
2026-09-10T14:30:00-03:00). UmtoString()dependente da localidade do servidor é causa clássica: funciona no computador do desenvolvedor e quebra em produção. - Namespace ausente ou diferente. Sem o namespace da NFS-e nacional (
http://www.sped.fazenda.gov.br/nfse) no elemento raiz, nenhum elemento é reconhecido, e a mensagem de erro costuma apontar para o primeiro elemento em vez de dizer que falta o namespace. - Espaços nas pontas. Os padrões de texto dos schemas fiscais em geral proíbem espaço no início e no fim do valor. Um nome vindo de um cadastro com espaço sobrando no final basta para invalidar o documento.
Valide antes de assinar. Corrigir o XML depois da assinatura invalida a assinatura, porque qualquer byte alterado muda o hash. Veja o artigo sobre hash.