Rejeição 568: falta o atributo de versão na raiz do lote

A rejeição 568, “Falha no schema XML – inexiste atributo versao na tag raiz do lote de NF-e”, aponta para uma informação estrutural da mensagem enviada à autorização. O lote precisa declarar sua versão no local previsto pelo leiaute. A versão preenchida dentro da nota não substitui o atributo da estrutura externa.

Para o empresário, a providência mais útil é preservar o retorno e acionar o responsável pelo emissor ou integração. Em geral, a correção está na geração do XML transmitido, não nos produtos, no valor da venda ou na identificação do cliente.

Qual informação está faltando

Na mensagem de autorização, enviNFe é o elemento raiz do lote. O MOC identifica versao como atributo obrigatório desse elemento. No leiaute 4.00, o início da estrutura contém a declaração versao="4.00" vinculada a enviNFe, junto das demais informações exigidas pelo schema. MOC 7.0, Visão Geral, seção 5.1.1.

Esse trecho é uma indicação de localização, não um XML completo pronto para transmissão. O lote também precisa apresentar namespace, campos de controle e documentos organizados conforme o contrato do serviço.

Há outras declarações de versão no arquivo. A declaração inicial do próprio XML, como version="1.0", identifica a linguagem XML e não o leiaute fiscal. A versão em infNFe identifica a estrutura da nota. Nenhuma das duas preenche automaticamente o atributo exigido em enviNFe.

Por que a SEFAZ devolve esse código

A D01b do MOC é uma verificação complementar, de aplicação facultativa, executada após falha de schema. No contexto do lote de autorização, ela associa a ausência do atributo à mensagem 568. O código geral de falha estrutural do lote é 225. MOC 7.0, Anexo I, página 72.

A palavra “facultativa” não torna o atributo opcional. Ela descreve a adoção desse detalhamento do diagnóstico pelo autorizador. Um lote sem um atributo obrigatório continua incompatível com o schema, mesmo que o serviço devolva outra descrição de erro.

Também não se trata de autorização parcial das notas contidas na mensagem. A falha ocorre na estrutura do envio e deve ser acompanhada como problema do lote, sem presumir a situação fiscal individual de documentos que possam ter outras tentativas anteriores.

Causas comuns na integração

A orientação do Berga aponta situações como montagem própria do envelope e transformação que remove atributos. Isso pode acontecer quando o sistema gera uma estrutura correta, mas outra etapa a reconstrói sem preservar todos os metadados.

Outra hipótese é a configuração existir apenas no componente que produz a nota, enquanto o componente responsável pelo lote não recebe o valor. Uma tela pode mostrar “versão 4.00” e, ainda assim, o arquivo transmitido omitir o atributo externo.

O teste decisivo é abrir a mensagem associada à tentativa recusada e localizar a informação no elemento certo. Não basta procurar o texto “4.00” em qualquer ponto do arquivo.

Atributo não é um campo filho

No XML, um atributo faz parte da abertura de um elemento. Uma tag filha chamada versao dentro de enviNFe não equivale ao atributo versao esperado ali. A grafia também precisa respeitar o padrão: o nome técnico é versao, sem acento.

O suporte deve usar o schema oficial para validar localização e formato. Acrescentar a informação indiscriminadamente em NFe, em todos os grupos ou no corpo de outra mensagem pode criar novas falhas, em vez de corrigir a original.

O manual XML da Oobj também descreve o atributo ligado à estrutura de envio. Como o documento trata de integração com um produto, diferencie seus campos e convenções do XML final encaminhado à SEFAZ.

Exemplo: versão perdida na conversão

Imagine uma empresa cujo ERP envia a nota para uma integração. O primeiro componente gera infNFe com a versão correta. O segundo cria enviNFe para transmitir o documento, mas uma atualização remove o atributo da abertura do lote.

A equipe confere o XML da nota, encontra a versão e conclui que o erro é da SEFAZ. Ao examinar a mensagem final, percebe que a versão está somente na estrutura interna.

A correção deve alcançar o segundo componente e os testes dessa conversão. Editar manualmente um único arquivo pode resolver uma tentativa e deixar as próximas sujeitas ao mesmo defeito. Se for necessário regenerar o documento, use o fluxo regular do sistema, com as validações e assinaturas pertinentes.

Passo a passo para resolver

1. Salve cStat e xMotivo completos, horário, ambiente, modelo e serviço utilizados.

2. Obtenha o XML efetivamente transmitido, além do arquivo da nota mostrado no emissor.

3. Localize enviNFe e verifique a presença do atributo versao na sua abertura.

4. Confira se o valor é aceito pelo leiaute e pelo serviço, sem confundir versão do software, da Nota Técnica e do XML.

5. Corrija o gerador ou a transformação responsável pela omissão e valide a mensagem completa.

6. Teste em homologação, verifique eventuais tentativas anteriores incertas e acompanhe a resposta da transmissão corrigida.

A TecnoSpeed, ao tratar da falha 225, recomenda conferir a estrutura e a versão esperada pelo Web Service. Essa orientação ajuda no diagnóstico complementar; avisos antigos sobre retirar determinados grupos do XML não devem ser aplicados sem nova conferência normativa.

Erros próximos exigem cuidados diferentes

Se a raiz do lote não foi reconhecida, investigue 565. Se a versão existe, mas seu valor não é suportado, o problema não é simplesmente ausência do atributo. Se o retorno veio de outro serviço, a mensagem pode ter uma raiz diferente e usar códigos como 517.

Não acrescente o antigo cabeçalho nfeCabecMsg para resolver 568. O MOC, seção 4.4.1 da Visão Geral, registra a retirada das variáveis de controle do SOAP Header nos Web Services do leiaute 4.0. O atributo da raiz do lote pertence à área de dados e continua sendo uma exigência distinta.

A mesma estrutura de autorização atende NF-e (modelo 55) e NFC-e (modelo 65), respeitadas as regras de quantidade e processamento aplicáveis a cada fluxo. Um lote com apenas uma nota também precisa declarar sua versão.

Quando considerar o problema encerrado

Confirme que o sistema passou a gerar corretamente a mensagem e que cada documento obteve o resultado fiscal esperado. Se existiu uma tentativa sem retorno conclusivo, consulte a situação antes de transmitir novamente. Não troque a numeração nem duplique a venda para contornar a falha.

Guarde o retorno original, a versão do componente corrigido e o resultado posterior. Essas informações permitem verificar se a solução alcançou a origem do problema e ajudam a evitar a repetição na próxima atualização.

Referência de atualização: 09/10/2026. Fontes oficiais e práticas confrontadas; sem certificação operacional de todos os autorizadores.