Rejeição 225: falha no schema XML do lote de NF-e

A rejeição 225, regra D01, informa que a área de dados do lote enviado ao serviço de autorização não atende ao schema XML esperado. Ela pode decorrer da estrutura do lote ou de uma NF-e contida nele. Não significa, por si, erro de imposto ou de cadastro.

Nesta página:

• O que a validação do lote abrange?
• Como separar gerador incorreto de schema desatualizado?
• Exemplo: ordem de elementos incorreta dentro de uma nota
• O que conferir depois de passar no XSD?

O que a validação do lote abrange?

O MOC determina a validação da mensagem de entrada inteira e informa que um erro em uma NF-e implica rejeição de todo o lote. Assim, não trate as demais notas como autorizadas somente porque não aparecem no primeiro erro.

Na autorização, a mensagem de envio é o lote enviNFe, com seu atributo versao e documentos NFe. O integrador deve validar o XML final pelo XSD da mensagem e suas dependências, preservando a primeira localização de erro: elemento, atributo, ordem, ocorrência ou formato apontados pelo validador.

Fontes: MOC Anexo I, regra D01.

Como separar gerador incorreto de schema desatualizado?

Registre o pacote XSD usado, a versão da mensagem, o modelo, o ambiente e a nota técnica pertinente. A NT 2026.004 altera campos do ecossistema para CNPJ alfanumérico; a RTC também evolui o leiaute. Um pacote antigo pode recusar uma estrutura prevista em versão posterior.

Essa possibilidade não autoriza aceitar qualquer XML. Confronte a exigência exata do pacote oficial aplicável com o arquivo gerado. Corrija a origem do dado ou a serialização comprovadamente incorreta; não remova campos obrigatórios nem force valores fiscais apenas para silenciar o validador.

Fontes: MOC Anexo I, regra D01; NT 2026.004 — CNPJ alfanumérico; NT 2025.002-RTC — Adequações NF-e/NFC-e.

Exemplo: ordem de elementos incorreta dentro de uma nota

Em um lote hipotético, a raiz e a versão estão corretas, mas o gerador escreve dois grupos de uma NF-e em ordem incompatível com a sequência do XSD. A primeira mensagem pode apontar um elemento que existe e é conhecido, porque naquele ponto era esperado outro.

Compare o caminho completo, seus ancestrais e a sequência definida no schema. Depois de corrigir o gerador, valide novamente todo o lote. Não basta remover o elemento denunciado, pois isso pode apagar informação necessária e criar nova falha.

Fontes: MOC Anexo I, regra D01.

O que conferir depois de passar no XSD?

XML bem formado, validade no XSD, validade da assinatura e autorização são etapas distintas. Se a correção afetou conteúdo assinado, regenere a assinatura pelo fluxo legítimo e valide o resultado final.

565 e 568 são detalhamentos facultativos para raiz ou versão ausentes no lote. A 215 é a mensagem genérica de schema de outras áreas de dados. A 225 não deve ser apresentada como código exclusivo de eventos. Esclareça resultados de tentativas incertas antes de transmitir novamente.

Fontes: MOC Anexo I, regra D01.

Limite do exemplo e preservação dos dados

A localização real do erro exige o lote protegido completo e suas dependências XSD; o cenário textual explica a sequência sem fabricar NF-e assinada ou XML pronto para transmissão. A conferência deve preservar o original e ocorrer em ambiente protegido; não publique certificado, senha, chave privada ou dados fiscais de clientes.

Fontes oficiais

• MOC 7.0 — Anexo I, versão 7.00. p. 72, regra D01, código 225; quadro completo e notas da seção.
• MOC 7.0 — Visão Geral, versão 7.00. pp. 50–51, namespace e validação XSD; pp. 71–72, lote enviNFe e seus atributos; pp. 53–55, assinatura.
• NT 2026.004 — CNPJ alfanumérico, versão 1.01. pp. 3–4, cronograma e alcance dos schemas; pp. 5–14, campos alterados e mensagens de serviços, incluindo envEvento p. 10.
• NT 2025.002-RTC — Adequações NF-e/NFC-e, versão 1.52. pp. 8–9, evolução do leiaute e DFeTiposBasicos; pp. 73–74, lista e registro de eventos, parte geral e schemas específicos.