Rejeição 411 — Campo versaoDados inexistente no elemento nfeCabecMsg do SOAP Header

O que é esta rejeição?#

A Rejeição 411 é retornada pela SEFAZ quando o sistema identifica o seguinte problema na NF-e: Campo versaoDados inexistente no elemento nfeCabecMsg do SOAP Header. A nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Este código indica que rejeição: Campo versaoDados inexistente no elemento nfeCabecMsg do SOAP Header.

Causas comuns#

• O XML contém erros de formatação, namespaces inválidos ou codificação incorreta
• A versão do layout XML não é suportada ou é superior à vigente na SEFAZ
• Há caracteres especiais, espaços ou quebras de linha indevidas no XML
• O XML deve usar codificação UTF-8 sem BOM (Byte Order Mark)

Como resolver#

1. Valide o XML com um parser antes de enviar — ele deve ser bem-formado (well-formed)
2. Use apenas o namespace padrão da NF-e: http://www.portalfiscal.inf.br/nfe
3. Salve o XML com codificação UTF-8 sem BOM
4. Atualize a versão do layout no sistema emissor para a versão vigente aceita pela SEFAZ
5. Remova caracteres de edição (tabs, espaços extras) do início e fim do XML

Verificações analíticas#

• Se o elemento nfeCabecMsg no SOAP Header não contém o atributo versaoDados preenchido com o valor '4.00' enquanto o atributo versao do elemento infNFe está definido como '4.00', então há descompasso entre a versão declarada no corpo da NF-e e o cabeçalho SOAP, indicando que o sistema emissor atualiza o layout do XML mas não sincroniza o cabeçalho do envelope: atualize o módulo de montagem do SOAP Header para injetar versaoDados='4.00' no nfeCabecMsg sempre que a versão do layout for alterada.
• Se o namespace declarado no elemento raiz nfeProc ou NFe difere de 'http://www.portalfiscal.inf.br/nfe' — por exemplo contém subpastas adicionais, versão numérica embutida ou variação de capitalização — enquanto o atributo versaoDados do nfeCabecMsg aponta para '4.00', então o parser SEFAZ rejeita o documento por inconsistência de namespace mesmo que a versão numérica esteja correta: padronize todos os elementos ao namespace único 'http://www.portalfiscal.inf.br/nfe' sem sufixos ou variações.
• Se o XML enviado contém os três bytes EF BB BF (BOM UTF-8) no início do stream enquanto o Content-Type do SOAP indica charset=UTF-8, então o parser SEFAZ interpreta o BOM como conteúdo textual corrompendo o elemento inicial e causando falha na leitura do nfeCabecMsg antes de qualquer validação de schema: regenere o arquivo garantindo codificação UTF-8 sem BOM usando função de escrita explicitamente sem marcador de ordem de byte.
• Se o valor do campo cUF no ide é diferente do cUF codificado no endpoint SOAP utilizado para transmissão — por exemplo XML com cUF=35 (SP) enviado ao webservice de MG — enquanto o versaoDados do nfeCabecMsg está presente porém com valor correspondente à versão homologada em outro estado, então a SEFAZ receptora rejeita o cabeçalho por não reconhecer a versão naquele ambiente: confirme que o endpoint de destino corresponde ao cUF do emitente e que a versão homologada naquele estado é idêntica à declarada no nfeCabecMsg.
• Se o elemento infNFe possui o atributo versao com valor diferente de '4.00' — como '3.10' ou '4.0' sem o zero decimal — enquanto o nfeCabecMsg traz versaoDados='4.00', então existe contradição entre a versão do schema utilizado para gerar os campos e a versão anunciada no cabeçalho SOAP, fazendo com que campos obrigatórios do layout 4.00 como infRespTec e indIntermed possam estar ausentes: atualize o gerador de XML para emitir versao='4.00' no infNFe e valide a presença de todos os grupos obrigatórios da versão vigente antes de montar o envelope SOAP.