Rejeição 416 — Falha na descompactação da área de dados

O que é esta rejeição?#

A Rejeição 416 é retornada pela SEFAZ quando o sistema identifica o seguinte problema na NF-e: Falha na descompactação da área de dados. A nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Causas comuns#

• Dados incorretos ou inconsistentes no XML da NF-e
• Divergência entre os dados informados e o cadastro na SEFAZ
• Formatação ou preenchimento incorreto de campos obrigatórios

Como resolver#

1. Verifique a mensagem de rejeição completa retornada pela SEFAZ
2. Consulte o Manual de Orientação do Contribuinte (MOC) para a regra de validação específica
3. Corrija os campos indicados no XML da NF-e
4. Retransmita a NF-e após as correções

Verificações analíticas#

• Se o campo tpEmis for diferente de 1 (contingência) e o XML vier compactado ou codificado em base64 sem o envelope correto de envio (nfeDadosMsg), então o payload transmitido pode estar corrompido ou duplamente codificado, causando falha na descompactação: verifique se o conteúdo do nfeDadosMsg está sendo enviado como XML puro sem codificação adicional e que a tag raiz NFeProc ou enviNFe esteja íntegra.
• Se dhEmi tiver fuso horário divergente do offset oficial do estado do emitente (ex: -03:00 para SP mas enviado como -00:00 ou sem offset), e dhSaiEnt for anterior a dhEmi em valor absoluto UTC, então o parser da SEFAZ pode rejeitar o XML por inconsistência temporal antes mesmo de validar conteúdo, corrompendo a leitura da área de dados: padronize ambas as datas para o offset correto da UF emitente conforme ABNT NBR ISO 8601.
• Se o campo versao do atributo da tag NFe (ex: versao='4.00') não corresponder ao namespace xmlns declarado no mesmo elemento raiz, ou se houver namespace duplicado ou malformado, então a descompactação e parsing do schema falha antes da validação de negócio: confirme que versao='4.00' e xmlns='http://www.portalfiscal.inf.br/nfe' estão coerentes e sem caracteres invisíveis ou BOM (Byte Order Mark) no início do documento XML.
• Se o total de bytes do XML assinado após a serialização exceder o limite aceito pelo webservice sem compressão GZIP obrigatória, ou se a compressão GZIP foi aplicada mas o Content-Type ou o envelope SOAP não reflete isso corretamente, então a SEFAZ recebe um payload truncado ou indecifrável gerando rejeição 416: verifique se o tamanho do XML ultrapassa 500KB e, neste caso, aplique GZIP conforme especificação do MOC, garantindo que o cabeçalho SOAP Content-Encoding esteja declarado.
• Se o número de itens declarados no campo qNItem (ou inferido pela contagem de tags det) divergir da quantidade real de elementos det presentes no XML serializado — situação possível quando a serialização dinâmica corta itens por limite de buffer ou encoding incorreto de caracteres especiais em xProd, infCpl ou xNome — então a estrutura do XML fica truncada e a SEFAZ falha ao tentar descompactar/parsear a área de dados: sanitize todos os campos de texto livre removendo caracteres fora do range permitido pelo schema (somente caracteres ASCII imprimíveis e os definidos no pattern [!-ÿ]{1}) e valide a contagem de det antes da assinatura.