Rejeição 402 — XML da área de dados com codificação diferente de UTF-8
Motivo da rejeição
XML da área de dados com codificação diferente de UTF-8
O que é esta rejeição?#
A Rejeição 402 é retornada pela SEFAZ quando o sistema identifica o seguinte problema na NF-e: XML da área de dados com codificação diferente de UTF-8. A nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.
Este código indica que rejeição: XML da área de dados com codificação diferente de UTF-8.
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#
- Valide o XML com um parser antes de enviar — ele deve ser bem-formado (well-formed)
- Use apenas o namespace padrão da NF-e: http://www.portalfiscal.inf.br/nfe
- Salve o XML com codificação UTF-8 sem BOM
- Atualize a versão do layout no sistema emissor para a versão vigente aceita pela SEFAZ
- Remova caracteres de edição (tabs, espaços extras) do início e fim do XML
Verificações analíticas#
- Se o XML transmitido contém declaração <?xml version="1.0" encoding="UTF-8"?> mas o arquivo foi salvo com BOM (bytes EF BB BF no início do stream) então o parser SEFAZ rejeita o documento por codificação inválida apesar da declaração correta: remova os bytes de BOM usando editor hexadecimal ou configuração do stream de saída do emissor antes de assinar e transmitir.
- Se o valor do atributo versao no elemento nfeProc ou NFe difere de '4.00' ou se o namespace xmlns declarado no elemento raiz NFe não é exatamente 'http://www.portalfiscal.inf.br/nfe' sem barra final ou sufixo adicional então o schema não será reconhecido pela SEFAZ e o envelope será rejeitado com 402: padronize namespace e versão para os valores vigentes em todos os elementos que os declaram.
- Se algum campo textual do XML — como xNome do emitente ou destinatário, xMun, xLgr, infCpl ou xPed — contém caracteres fora do subconjunto Latin-1 mapeado em UTF-8 ou contém entidades HTML não escapadas como & sem & ou < sem < então o XML deixa de ser well-formed e é rejeitado antes mesmo da validação de schema: serialize todos os campos de texto com escape XML correto e garanta que a codificação do buffer de saída é UTF-8 puro.
- Se o processo de geração do XML aplica concatenação direta de strings ou template sem serializer XML e o campo xCont, infAdFisco ou infCpl contém quebra de linha \n ou tabulação \t embutida no conteúdo do elemento então esses caracteres de controle tornam o XML mal-formado segundo a especificação XML 1.0 seção 2.2: substitua quebras de linha e tabs por espaço simples ou remova-os antes de serializar o documento.
- Se o envelope soap ou o lote enviado à SEFAZ encapsula o XML da NF-e como string serializada duas vezes — ou seja, o conteúdo do elemento nfeDadosMsg já chegou com entidades como <NFe> em vez do elemento XML nativo — então a SEFAZ interpreta o corpo como texto puro com codificação divergente e rejeita com 402: envie o XML da NF-e como nó DOM filho do elemento de dados do envelope, nunca como string escapada dentro de CDATA ou com double-encoding.
Consulte IEs e CNPJs antes de emitir NF-e
Muitas rejeições acontecem por dados cadastrais desatualizados. Com a FiscalAPI, consulte Inscrições Estaduais e CNPJs em tempo real direto da SEFAZ e Receita Federal.
Criar conta →