Pular para o conteúdo
FiscalAPI
402 Schema XML

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

3 min de leitura

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#

  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 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 &amp; ou < sem &lt; 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 &lt;NFe&gt; 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.
Compartilhar: WhatsApp LinkedIn Twitter

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 →