Falha no schema XML do DF-e: como achar o campo que a mensagem não diz

O emissor devolve uma linha só:

E1235 - Falha no esquema XML do DF-e.

Ou, na NF-e:

Rejeição 215: Falha no schema XML

E nada mais. Nenhum campo, nenhuma linha, nenhuma pista. É um dos erros mais frustrantes de quem emite documento fiscal eletrônico, porque a nota inteira volta sem que ninguém diga o que está errado nela.

A boa notícia é que a mensagem tem um segundo parágrafo, quase sempre escondido pelo emissor, e é ele que aponta o campo. Este guia mostra como ler esse texto, o que cada formato de mensagem quer dizer, e por que o mesmo número de erro significa coisas diferentes em cada documento fiscal.

As duas camadas de validação, e por que isso importa

Todo documento fiscal eletrônico passa por duas conferências antes de ser autorizado, e elas são independentes:

A segunda camada é a que produz as rejeições da NF-e e os erros da NFS-e que todo mundo conhece, com campo e regra. A primeira é anterior: se o arquivo não passa nela, nenhuma regra fiscal chega a ser avaliada.

É por isso que a mensagem é muda. No Buscador NCM, o E1235 aparece com a lista de campos vazia, e não é omissão da nossa base: o próprio leiaute não associa campo nenhum a ele, porque o erro não pertence a um campo. Já a rejeição 215 traz como verificação apenas “Verifica Schema XML da área de Dados”, aplicada ao grupo D01, que é a raiz da mensagem.

O texto longo é a resposta

O validador de esquema é um componente padrão de XML, e a mensagem dele segue três formatos previsíveis. Quem emite pela plataforma do município ou por um sistema próprio costuma ver esse texto abaixo da mensagem curta, ou no retorno bruto do serviço.

Formato 1: elemento inesperado na sequência

The element 'cServ' in namespace 'http://www.sped.fazenda.gov.br/nfse'
has invalid child element 'xDescServ' in namespace 'http://www.sped.fazenda.gov.br/nfse'.
List of possible elements expected: 'cTribNac' in namespace 'http://www.sped.fazenda.gov.br/nfse'.

Parece dizer que o xDescServ está errado. Não está. O campo que falta é o que aparece depois de expected.

O esquema oficial define o grupo do código do serviço nesta ordem exata:

Duas fontes oficiais discordam do tamanho da descrição. O Anexo I do leiaute publica 1.000 caracteres para o xDescServ, e o arquivo de esquema define o tipo com máximo de 2.000. Quem valida a nota é o esquema, então uma descrição de 1.500 caracteres passa. Mas o Anexo I é o documento que o município lê para montar o próprio sistema, e nada garante que a plataforma municipal aceite o mesmo. Na dúvida, fique em 1.000.

O validador percorre a sequência em ordem. Ele estava esperando o cTribNac, encontrou o xDescServ e parou. Ou seja: a DPS foi montada sem o código de tributação nacional, e o erro aponta o campo seguinte porque foi nele que a leitura tropeçou.

A mesma leitura vale para qualquer grupo: o elemento citado depois de expected é o que deveria estar ali. Quando a lista traz mais de um nome, o esquema aceita qualquer um deles naquela posição, e nenhum apareceu.

Formato 2: valor que não bate com o tipo

The 'http://www.sped.fazenda.gov.br/nfse:email' element is invalid
- The value '' is invalid according to its datatype
'http://www.sped.fazenda.gov.br/nfse:tsEmail'
- The Pattern constraint failed.

Aqui o campo está nomeado, e o valor recusado aparece entre aspas. No exemplo acima o valor é vazio, e é o caso mais comum de todos.

Campo opcional aceita não existir, não aceita existir vazio. No esquema da NFS-e Nacional, os campos de texto herdam um tipo genérico com um formato que exige pelo menos um caractere visível e proíbe espaço no começo e no fim do valor. Uma tag como <email></email> viola esse formato, e o sistema recusa a nota inteira por causa dela.

Três consequências práticas, todas do mesmo formato:

• Tag vazia derruba. Se o dado não existe, a tag não deve ser gerada.
• Espaço sobrando derruba. Um valor que termina em espaço, coisa que passa despercebida quando o dado vem de banco, é recusado pelo mesmo motivo.
• Quebra de linha derruba quase todo campo. O formato genérico não inclui a quebra de linha entre os caracteres aceitos. A exceção é a descrição do serviço, que usa um tipo próprio, feito para aceitar texto em várias linhas. Texto colado de outro documento costuma trazer a quebra junto, e ela reprova em qualquer outro campo.

Quando a recusa é por tamanho, a mensagem troca de constraint e fica explícita, dizendo que o valor é longo demais ou curto demais para o tipo.

Formato 3: a raiz da mensagem

Falha no schema XML – inexiste atributo versao na tag raiz da mensagem
Falha no schema XML – inexiste a tag raiz esperada para o lote de NF-e

Esses dois não falam de campo nenhum: falam do envelope. Aparecem quando o sistema monta a mensagem sem o atributo de versão na tag raiz, ou quando envia o documento fora do lote esperado pelo serviço. Na NF-e eles têm código próprio, o 517 e o 565, e costumam indicar problema de integração, não de preenchimento.

O mesmo erro, um código diferente em cada documento

Aqui mora uma armadilha que custa tempo. O código de status não é único entre os documentos fiscais eletrônicos: cada um tem a própria tabela, e o mesmo número aparece em vários com significados diferentes.

Cruzando as tabelas de todos os documentos que o Buscador NCM cataloga, nove números carregam uma mensagem de falha de esquema, e em sete deles o mesmo número quer dizer outra coisa em algum outro documento:

Quem recebe “580” de um emissor de MDF-e e pesquisa o número solto encontra a explicação da NF-e, que fala de evento e de nota autorizada, e perde a tarde procurando um problema que não existe. O comparador de cStat do Buscador NCM existe por causa disso: digite o número e ele mostra o que ele significa em cada um dos documentos do Ato Conjunto nº 4.

Na NFS-e Nacional a numeração é outra, com a letra E na frente. A tabela oficial reúne 887 erros da NFS-e nos dois padrões, e desses apenas 14 códigos de esquema. Além do E1235, que é o mais comum, estão ali a codificação fora de UTF-8, o conteúdo compactado mal formado, o uso de prefixo de namespace não permitido e o prazo de aceitação de versão de leiaute vencido. São causas de infraestrutura, e cada uma tem a página com o texto oficial em erros da NFS-e.

O que o esquema da NFS-e cobra

Para dimensionar onde a falha costuma estar, vale olhar o que o esquema oficial exige. A versão publicada pelo Portal Nacional traz 597 campos no esquema, e a distribuição das exigências explica por que a maioria das falhas cai em quatro ou cinco padrões:

O último merece atenção porque não é intuitivo. Em vários pontos o leiaute oferece uma escolha: informar o endereço nacional ou o endereço no exterior, informar a obra ou a atividade de evento. Preencher os dois lados é erro de esquema, e a mensagem sai no formato 1, dizendo que encontrou um elemento inesperado.

Checklist para achar o campo em poucos minutos

1. Pegue o texto completo do retorno. A mensagem curta não resolve. Se o emissor não mostra o detalhe, procure o retorno bruto do serviço, o arquivo de resposta ou o histórico do documento.
2. Ache a palavra expected. O campo citado depois dela é o que falta. Se não houver expected, procure o nome do campo entre aspas antes de element is invalid.
3. Confira se o campo é obrigatório e onde ele entra. A tabela de tags do XML da NFS-e traz o caminho completo de cada campo, e a tabela de tags de IBS e CBS faz o mesmo para o grupo novo da NF-e.
4. Procure tags vazias no arquivo. Um documento com <tag></tag> ou <tag/> num campo de texto é candidato imediato.
5. Procure espaço no começo e no fim dos valores. Principalmente em descrição, razão social e endereço.
6. Confira a ordem dos campos dentro de cada grupo. Sistema que monta o XML por concatenação inverte a sequência com facilidade, e o esquema não perdoa a troca.
7. Confira a versão do leiaute e o atributo de versão na raiz. Falha de esquema também acontece quando o arquivo está certo e a versão declarada não é a aceita.
8. Passe o arquivo por um validador antes de transmitir de novo. É mais rápido do que uma nova recusa.

Quando não é falha de esquema

Nem toda recusa que menciona XML vem do esquema. Vale separar, porque a correção é outra:

• Rejeição com campo e regra numerada. Se a mensagem cita um campo do leiaute e uma regra, é conteúdo, não estrutura. As rejeições da NF-e trazem a regra de validação de cada código, e o guia de rejeições organiza as mais comuns por causa.
• Erro de assinatura ou certificado. Mensagem sobre assinatura digital, cadeia ou CNPJ do certificado é outra camada.
• Erro do grupo de IBS e CBS. Desde 3 de agosto de 2026 a NF-e carrega o grupo da reforma, e as recusas da série 1000 têm causa própria, listadas em rejeições da reforma. O guia de emissão com IBS e CBS cobre o preenchimento.
• Erro de negócio na NFS-e. Local de incidência, retenção e obra têm códigos próprios, com o campo apontado. O guia de erros da NFS-e trata deles, e o guia dos documentos fiscais eletrônicos mostra o calendário de cada documento.

Fontes oficiais

• Leiaute da DPS e da NFS-e (Anexo I) e leiaute do RTC (Anexo VI), Portal Nacional da NFS-e, Secretaria Especial do Comitê Gestor da NFS-e (Receita Federal). Os arquivos de esquema que acompanham a documentação técnica definem a sequência, o tamanho e o formato de cada campo citado neste guia.
• Tabela de erros da NFS-e Nacional, com o texto oficial de cada código, publicada na documentação técnica do Portal Nacional da NFS-e.
• Manual de Orientação do Contribuinte da NF-e e NFC-e, Regras de Validação, consolidado pelo Portal da NF-e, de onde saem a rejeição 215 e as demais da classe de esquema.
• Ato Conjunto RFB/CGIBS nº 4, de 30 de julho de 2026, que fixa os documentos fiscais eletrônicos e o calendário de IBS e CBS de cada um.
• Lei Complementar nº 116/2003, que define a lista de serviços de onde sai o código de tributação nacional.

As tabelas e contagens deste guia saem das mesmas bases que alimentam as páginas do Buscador NCM, com a data de cada fonte em fontes oficiais.