Rejeição 565: a raiz do lote de NF-e não foi reconhecida

A rejeição 565, “Falha no schema XML – inexiste a tag raiz esperada para o lote de NF-e”, indica que a mensagem encaminhada à autorização de NF-e (modelo 55) ou NFC-e (modelo 65) não apresentou a estrutura inicial esperada para o lote. A investigação começa no arquivo efetivamente transmitido e na montagem do envio pelo emissor.

Esse retorno não aponta, por si só, um problema no preço, no imposto ou no cadastro do cliente. Uma nota pode estar corretamente preenchida e ainda assim ser encaminhada dentro de uma mensagem inadequada. Mudar dados comerciais sem identificar a falha estrutural aumenta o retrabalho.

Onde está o problema

No serviço NfeAutorizacao, a mensagem de entrada utiliza o elemento raiz enviNFe. Dentro dele ficam as informações de controle do envio e a estrutura de cada documento. O MOC apresenta essa organização na seção 5.1.1 da Visão Geral. MOC 7.0, Visão Geral, páginas 71 e 72.

A palavra “raiz” significa o elemento principal daquela mensagem XML. Neste caso, é a raiz da área de dados do lote, e não a abertura genérica do envelope SOAP usado na comunicação.

Enviar somente NFe, enviar um arquivo processado nfeProc ou usar a mensagem de outro serviço não substitui o lote esperado. O suporte deve conferir qual conteúdo chegou à chamada de autorização, além do arquivo exibido na tela do usuário.

Regra facultativa não significa estrutura opcional

O MOC associa o código 565 à D01a, uma verificação facultativa realizada quando ocorre falha de schema. Ela ajuda a detalhar o problema detectado na validação estrutural D01, cujo retorno de lote é 225. MOC 7.0, Anexo I, página 72.

A facultatividade se refere a essa verificação complementar. Não autoriza transmitir um lote sem sua estrutura obrigatória, nem garante que um XML inválido seja aceito onde a mensagem 565 não for utilizada. Outro autorizador pode devolver um erro estrutural mais genérico.

A validação do schema considera a mensagem completa. Por isso, não transforme uma falha do lote em uma conclusão fiscal individual sobre cada nota. É necessário corrigir a transmissão e acompanhar os resultados correspondentes.

Causas que merecem investigação

A base do Berga destaca a diferença entre o documento e o envelope do lote. O ponto prático é conferir se a integração enviou o pacote correto, em vez de apenas exportar a nota e encaminhá-la diretamente.

Outras hipóteses são nome de elemento digitado incorretamente, alteração de maiúsculas e minúsculas, transformação que removeu a parte externa ou uso da mensagem destinada a outro método. São hipóteses de investigação, não causas comprovadas pelo número sozinho.

Um relato histórico no GUJ documenta a confusão entre envNFe e enviNFe. Ele ilustra como um detalhe no nome muda o reconhecimento do XML, mas utiliza serviços antigos; seus exemplos de versão e endereço não devem ser copiados para uma integração atual.

O arquivo do intermediário pode ter outro formato

Se o ERP entrega dados a um componente fiscal, pode haver duas etapas: a mensagem aceita pelo fornecedor e a mensagem que esse fornecedor gera para a SEFAZ. Validar a primeira não comprova a correção da segunda.

O manual de integração XML da Oobj distingue suas validações e retornos de integração. Essa separação ajuda a localizar a origem da falha. O leiaute próprio do intermediário não deve ser usado como substituto automático do schema oficial na chamada à SEFAZ.

Peça ao suporte para indicar em qual etapa a mensagem foi recusada. Um aviso local parecido com 565 e um cStat recebido do autorizador não são evidências idênticas.

Roteiro de correção

1. Registre o código e o motivo completos, o modelo, o ambiente, o horário e o serviço acionado.

2. Preserve a mensagem de envio e o retorno, incluindo os identificadores usados para relacioná-los.

3. Verifique a raiz da área de dados: para a autorização em análise, o elemento esperado é enviNFe.

4. Confira versão, namespace, estrutura e schema adequados ao serviço utilizado.

5. Corrija a geração da mensagem no emissor ou na integração, em vez de fazer um remendo isolado em arquivo assinado.

6. Valide novamente, teste em homologação e acompanhe o resultado do envio corrigido.

Se o arquivo parece correto, compare o conteúdo gerado com o que foi efetivamente transmitido. Uma conversão intermediária pode modificar o texto após a validação local. O registro precisa corresponder à tentativa rejeitada, não a uma exportação posterior.

Exemplo de arquivo errado selecionado

Uma empresa troca o componente de emissão. A nova integração procura XMLs numa pasta e, por engano, seleciona o arquivo de armazenamento da nota, sem montar a mensagem de autorização.

O documento abre normalmente num visualizador, então a equipe tenta alterar dados do cliente. O problema persiste porque o arquivo selecionado continua sendo o errado. A correção é ajustar a etapa de montagem e validar a mensagem final. Abrir um XML sem erro de sintaxe não significa que ele atende ao schema de qualquer serviço.

Uma nota por lote ainda precisa da raiz

A NFC-e, modelo 65, tem limite de uma nota por solicitação no contexto da NT 2023.002. A NF-e com série PAA também tem restrição específica. Nenhuma dessas condições elimina a estrutura de autorização.

Também não se deve usar o mesmo XML indiscriminadamente para autorização, consulta e eventos. Cada serviço tem sua mensagem. Os códigos 516 e 517 tratam de raiz ou versão em outros contextos de mensagem; o 568 detalha a ausência do atributo de versão do lote.

Como evitar repetição e duplicidade

Inclua nos testes a mensagem completa, a rota usada e o tratamento de retorno. A conferência de tags e versões também é uma orientação prática da TecnoSpeed para falhas de schema do lote; alertas antigos sobre campos específicos precisam ser verificados nas regras atuais.

Antes de repetir uma nota cuja tentativa anterior ficou incerta, consulte sua situação. Não renumere documentos nem recrie vendas para contornar a falha. Depois da correção, confira a resposta de cada documento e guarde a evidência de autorização. O desaparecimento do erro de lote é apenas uma etapa dessa confirmação.

Referência de atualização: 09/10/2026. Revisão documental e de integração; sem afirmar a utilização do código complementar por todas as UFs.