Rejeição 565: tag raiz do lote de NF-e não encontrada
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A rejeição 565, regra D01a, detalha uma falha de schema no serviço de autorização: não foi encontrada a tag raiz esperada para o lote de NF-e. O ponto central é conferir qual XML chegou à área de dados, e não apenas se uma tag NFe existe em algum lugar do arquivo.
Nesta página:
- Qual raiz é esperada na autorização?
- Exemplo: arquivo individual entregue no lugar do lote
- O envelope SOAP pode ocultar a área de dados?
- Como confirmar a correção e distinguir 516?
Qual raiz é esperada na autorização?
A mensagem de envio de autorização usa enviNFe no namespace da NF-e. Uma NFe individual é conteúdo do lote; um nfeProc é o documento processado com seu protocolo. Nenhum dos dois substitui automaticamente a mensagem de envio.
A regra D01a é facultativa e pode ser aplicada depois da falha D01. O autorizador também pode devolver a mensagem genérica 225. Não se deve concluir que um arquivo sem 565 tem a raiz correta sem validá-lo no schema do serviço.
Fontes: MOC Anexo I, regra D01a.
Exemplo: arquivo individual entregue no lugar do lote
Suponha que o gerador produza uma NFe individual e o cliente SOAP a encaminhe diretamente onde o serviço espera enviNFe. O arquivo pode abrir normalmente em um visualizador e ainda faltar a raiz da mensagem de autorização.
Compare a saída do gerador com a entrada efetiva do método chamado. A correção é montar a mensagem prevista no contrato, preservando a nota e sua assinatura. Não renomeie simplesmente NFe para enviNFe: seus filhos e responsabilidades são diferentes.
Fontes: MOC Anexo I, regra D01a.
O envelope SOAP pode ocultar a área de dados?
O envelope transporta a chamada; não é a raiz fiscal validada por essa regra. Um cliente pode enviar o XML como texto escapado, usar o parâmetro errado ou introduzir uma camada adicional. Analise a área de dados efetivamente entregue ao serviço e seu namespace expandido, com os logs mantidos em canal protegido.
O namespace padrão fiscal é http://www.portalfiscal.inf.br/nfe. Não o troque por HTTPS nem pelo namespace do WSDL. Uma grafia diferente representa outro identificador, ainda que pareça uma atualização de segurança.
Fontes: MOC Anexo I, regra D01a.
Como confirmar a correção e distinguir 516?
Valide o lote reconstruído no XSD aplicável e confira estrutura, versão e assinatura. A 516 também trata de raiz ausente, mas é o detalhamento da mensagem fora da linha específica do lote de autorização. O código deve ser interpretado com o serviço chamado.
Se houve envio anterior cujo resultado se perdeu, consulte sua situação antes de repetir a transmissão. Passar na conferência da raiz apenas permite prosseguir nas demais validações; não comprova autorização.
Fontes: MOC Anexo I, regra D01a.
Limite do exemplo e preservação dos dados
A prova exige a área de dados original, o envelope e a nota assinada protegida. O exemplo textual compara raízes reais sem inventar chave, assinatura ou lote transmissível. 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 D01a, código 565; 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.