WhatsAppTeste grátis
Voltar para o blog

NF-e e NFC-e

Rejeição 402: como corrigir a codificação UTF-8 do XML

A rejeição 402 indica que o XML da área de dados foi enviado com codificação diferente de UTF-8. A correção deve alcançar a geração e o transporte do arquivo: o texto declarado como UTF-8 precisa estar realmente gravado e transmitido nesse padrão.

Blog ALRA
Capa ilustrada da ALRA: Rejeição 402: como corrigir a codificação UTF-8 do XML.

A rejeição 402 indica que o XML da área de dados foi enviado com codificação diferente de UTF-8. A correção deve alcançar a geração e o transporte do arquivo: o texto declarado como UTF-8 precisa estar realmente gravado e transmitido nesse padrão.

Mensagem: “Rejeição: XML da área de dados com codificação diferente de UTF-8”.

Acentos não são, por si só, incompatíveis com UTF-8. Antes de apagar palavras, símbolos ou observações, peça ao suporte que confira como o sistema converteu os caracteres e quais bytes foram enviados.

O que a SEFAZ verifica

Codificação é a forma de representar os caracteres em bytes. O MOC adota XML 1.0 com UTF-8 e estabelece a declaração correspondente no início do documento. A regra D03 da validação da área de dados é obrigatória e associa a codificação diferente de UTF-8 à rejeição 402. MOC 7.0, Anexo I, seção 4.1.3, MOC, Visão Geral, seção 4.2.1.1.

Alterar somente o texto “encoding” da declaração não converte o conteúdo. Um arquivo gravado em ISO-8859-1, por exemplo, continua contendo os bytes daquela codificação se alguém apenas trocar seu rótulo para UTF-8. Essa inconsistência também pode impedir a leitura do XML, antes de outras validações.

UTF-8 representa caracteres Unicode, incluindo letras acentuadas. As regras do XML e do campo fiscal ainda precisam ser atendidas: “&” e “<”, por exemplo, exigem tratamento próprio quando usados como texto. Corrigir codificação, escapar caracteres e validar o schema são verificações diferentes. W3C XML 1.0, seções 2.2, 2.4 e 4.3.3.

O MOC recomenda evitar acentos e símbolos nos campos alfanuméricos. Essa orientação de preenchimento não significa que esses caracteres estejam fora do UTF-8, nem dispensa verificar os bytes quando ocorre a 402. MOC, Anexo I, seção 3.2.

Qual serviço retornou a 402?

Autorização de NF-e/NFC-e e demais Web Services do MOC: examine a área de dados da operação realizada. Para emissão, o escopo abrange os modelos 55 e 65. Em uma consulta, examine a consulta, sem alterar uma nota já autorizada.

Distribuição DF-e: a NT 2014.002 v1.40 mantém a D03 para o pedido de distribuição de documentos da NF-e, modelo 55. O XML a corrigir é a solicitação enviada pelo interessado. O fato de ela ser rejeitada não indica que o arquivo fiscal guardado no Ambiente Nacional foi corrompido. NT 2014.002 v1.40, seção 3.10.1.

Eventos: há previsão da 402 na manifestação do destinatário, no EPEC da NF-e e na prorrogação de industrialização, referentes ao modelo 55. O EPEC da NFC-e, modelo 65, também a relaciona, mas sua adoção e implantação dependem da UF. Corrija a mensagem do evento que estava sendo enviado. NT 2020.001 v1.60, seção 6.3.6, NT NFC-e 2014.003 v1.02, seções 01 e 03.8.

Outros eventos e consulta GTIN: a 402 também aparece no comprovante de entrega, insucesso de entrega e ator interessado da NF-e (55), no cancelamento por substituição da NFC-e (65) e no ECONF (55/65). Cada evento mantém seu destino e leiaute. No serviço consGTIN, corrija a codificação da consulta, sem modificar o código do produto. ECONF, NT 2024.002, seção 3.6, Consulta GTIN, NT 2022.001, seção 04.6.

Gerenciamento do CSC: a A12 consta nos serviços de consulta, requisição e revogação do CSC da NFC-e. Confira se esse Web Service está disponível na UF e qual operação foi rejeitada. A 402 não recomenda revogar um CSC nem gerar outro. NT NFC-e 2014.001, páginas 7 a 9.

Como investigar com o suporte

  1. Guarde cStat, xMotivo, operação, UF, ambiente, horário e versão do emissor.

  2. Preserve o arquivo original efetivamente transmitido. Evite abri-lo e salvá-lo antes de entregar a cópia ao suporte: essa ação pode alterar a codificação e esconder a causa.

  3. Peça a comparação entre a declaração XML, a codificação real dos bytes e o tratamento feito pela integração até o envio.

  4. Confira se a falha surgiu após importar dados, trocar biblioteca, atualizar o sistema ou alterar uma etapa de comunicação.

  5. Corrija a conversão na origem, gere novamente a mensagem e faça as validações locais antes de transmitir.

Bases práticas da Oobj e da TecnoSpeed concentram a investigação nos campos de texto e no emissor. Recomendações genéricas de remover acentos não substituem a análise da codificação exigida pelo MOC.

O que fazer em cada cenário

O XML foi gravado em outra codificação: ajuste o gerador para produzir UTF-8 de verdade, mantendo a declaração coerente. A mudança deve valer também para os próximos documentos, não apenas para uma cópia editada manualmente.

A declaração já diz UTF-8: verifique os bytes. A declaração pode estar correta e a gravação incorreta, ou uma etapa posterior pode ter convertido o conteúdo. Compare os arquivos antes e depois dessa etapa.

O texto apareceu como “Café” em vez de “Café”: investigue uma leitura ou conversão com codificação errada. Esse aspecto visual é um indício, não a prova automática da 402: um texto já corrompido pode estar gravado em UTF-8 válido. Reconstitua o conteúdo correto a partir da origem e corrija o percurso dos dados.

Acontece somente em uma UF: reúna mensagens e retornos comparáveis, sem presumir que a aceitação em outra UF prove conformidade. A TOTVS documentou em 2021 um caso envolvendo MT, MG e uma conversão de símbolo. Esse relato histórico não comprova uma proibição atual de todos os acentos ou símbolos em MT.

A codificação passa, mas aparece outro erro: siga o novo diagnóstico. A 243 aponta XML malformado; 215/225 tratam falha de schema; 404 trata prefixo de namespace. Mudar todas essas características ao mesmo tempo dificulta encontrar a origem.

Exemplo hipotético

Uma pequena indústria usa a descrição fictícia “Café torrado em grãos”. Depois de uma alteração na exportação, o gerador passa a salvar o XML em ISO-8859-1, com declaração correspondente. A SEFAZ devolve 402.

O fornecedor configura a saída para UTF-8, regenera o documento e confere se “Café” foi preservado corretamente. O emissor valida e assina a nova mensagem antes de enviá-la. A descrição comercial continua a mesma; a correção foi a forma de representar seus caracteres.

Como confirmar a solução

O suporte deve confirmar a codificação real do novo arquivo e a consistência entre o conteúdo gerado, assinado e transmitido. Se houver alteração em conteúdo assinado, a assinatura deve ser produzida novamente pelo emissor.

Depois, confira o retorno definitivo da operação: protocolo da autorização, resultado do evento ou resposta da consulta. A ausência da 402, sozinha, não comprova que a nota foi autorizada. Se uma tentativa anterior ficou sem resposta conclusiva, consulte a situação antes de retransmitir.

Revisão: 09/10/2026. Regras nacionais e documentos específicos de serviços foram cotejados; não foi realizado teste em cada UF e ambiente.

Referências complementares

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.

Baixar teste grátisFalar no WhatsApp