Rejeição 402 e 878 na NFC-e da SEFAZ-MT: Encoding UTF-8 vs ASCII 7-Bit e URL HTTP do QR Code / Consulta Chave

Qualquer engenheiro que já colocou um sistema de PDV ou varejo para rodar em Mato Grosso (UF MT, código IBGE 51) conhece a sensação de olhar para um XML 100% codificado em UTF-8, assinado corretamente com Certificado A1, e receber de volta da SEFAZ-MT uma resposta desconcertante: cStat 402 — Rejeição: XML utiliza codificação diferente de UTF-8.

O mais intrigante é que o mesmo ERP emite NF-e (Modelo 55) para o mesmo CNPJ mato-grossense com acentos ("PRODUÇÃO", "COMÉRCIO", "SÃO JOSÉ") e a nota é autorizada em menos de um segundo. Porém, ao transmitir uma NFC-e (Modelo 65) ou um Evento (RecepcaoEvento4, como cancelamento ou Carta de Correção) contendo um único caractere acentuado, o autorizador de Mato Grosso derruba a requisição com cStat 402. E, logo depois que você remove os acentos da NFC-e em produção, surge uma segunda armadilha exclusiva da UF: a cStat 878 — Rejeição: Endereço do site da UF da Consulta por chave de acesso diverge do previsto por causa de um único 's' no protocolo https:// versus http://.

Aqui na Notaas, nós dissecamos o comportamento interno dos servidores da SEFAZ-MT nas releases v0.56.135, v0.56.142 e v0.56.143. Neste artigo, vou explicar a causa raiz exata nos autorizadores MT_A2_NFCe-4.100 e RecepcaoEvento4, por que a regra ZX03-20 exige http:// em produção para a NFC-e de Mato Grosso, e como nossa engine resolve ambos os problemas automaticamente sem que você precise sanitizar strings no seu código.

Na SEFAZ-MT, o problema do cStat 402 na NFC-e não é o seu header HTTP nem o prólogo do XML: é uma re-serialização interna em ISO-8859-1 dentro do próprio servidor autorizador MT_A2_NFCe-4.100.

Por que a SEFAZ-MT retorna cStat 402 na NFC-e (v0.56.142) e nos Eventos (v0.56.135), mas não na NF-e Modelo 55?

Quando investigamos os pacotes SOAP enviados para Mato Grosso, comparamos o comportamento dos três webservices estaduais:

1. Emissão de NF-e Modelo 55 (/nfews/v2/services/NfeAutorizacao4 — servidor MT_NFE-4.000):
   • Preserva o stream de bytes UTF-8 original durante toda a validação. Textos com caracteres multibyte (0xC3 0x87 para Ç, 0xC3 0x83 para Ã) passam normalmente.
2. Emissão de NFC-e Modelo 65 (/nfcews/services/NfeAutorizacao4 — servidor MT_A2_NFCe-4.100 — corrigido na v0.56.142):
   • Ao desempacotar o nó <NFe> de dentro do lote <enviNFe> no pipeline SOAP, o servidor MT_A2_NFCe-4.100 da SEFAZ-MT re-serializa internamente o XML em ISO-8859-1 (Latin-1) antes de invocar o validador de encoding UTF-8.
   • Resultado: qualquer caractere fora da tabela ASCII de 7 bits (bytes > 0x7F, como Ç, Ã, É, Õ, º) vira um byte isolado inválido em UTF-8 durante a etapa interna da SEFAZ-MT, disparando falsamente o cStat 402 — Rejeição: XML utiliza codificação diferente de UTF-8.
   • Pior: mesmo usando entidades numéricas XML (ç), o parser DOM do autorizador expande a entidade antes da re-serialização Latin-1 e continua rejeitando com 402. A única representação que é byte-a-byte idêntica tanto em UTF-8 quanto em ISO-8859-1 é o ASCII puro de 7 bits (0x20..0x7E).
3. Eventos de NF-e e NFC-e em MT (RecepcaoEvento4 — cancelamento 110111 e CC-e 110110 — corrigido na v0.56.135):
   • O webservice RecepcaoEvento4 da SEFAZ-MT sofre do mesmo comportamento ao processar a justificativa (<xJust>), a descrição do evento (<descEvento>Cancelamento</descEvento> / <descEvento>Carta de Correcao</descEvento>) ou o texto da correção (<xCorrecao>). Na release v0.56.135, ativamos o modo híbrido ASCII para eventos na SEFAZ-MT e passamos a expor errorMessage no retorno da API caso uma tentativa de cancelamento seja rejeitada pela SEFAZ.

Como funciona a transliteração 1-para-1 e o Fallback CAS na Notaas (v0.56.142)

Para que o desenvolvedor integrado ao nosso guia prático de API NFC-e (Modelo 65) ou à API de NF-e (Modelo 55) nunca precise se preocupar com isso, implementamos na v0.56.142 uma defesa em duas camadas:

1. Prevenção Proativa por UF (UFS_NFCE_ASCII_ONLY = new Set(['MT'])):
   • Quando modelo === 65 e a UF do emitente está em UFS_NFCE_ASCII_ONLY, o NfceBuilder ativa asciiOnly: true antes de assinar o XML.
   • Nossa função transliterateNfeTextToAscii faz o mapeamento 1-para-1 (preservando rigorosamente o tamanho length da string) via decomposição Unicode NFD + remoção de diacríticos combinantes + mapa explícito de símbolos (º ➔ o, ª ➔ a, § ➔ S, ° ➔ o, travessões –/— ➔ -), sem jamais estourar os limites de maxLength dos campos XSD (xNome, xLgr, xBairro, xProd, infCpl) e mantendo a assinatura XMLDSig (DigestValue) 100% íntegra.
2. Auto-Recovery Reativo com Guard CAS (replaceSignedXmlForProcessing):
   • E se outra UF atualizar seu autorizador no futuro e passar a devolver cStat 402 em uma NFC-e com acentos?
   • Nosso worker detecta o retorno síncrono cStat === '402' no modelo 65, verifica se o XML assinado contém bytes > 0x7F e executa um único retry imediato: reconstrói e re-assina o XML da NFC-e com asciiOnly: true (recalculando DigestValue, SignatureValue e o cHashQRCode do QR Code v2.00), persiste o novo XML no banco sob lock atômico CAS (WHERE id = $1 AND status = 'processing') e reenvia à SEFAZ na mesma requisição.

export function transliterateNfeTextToAscii(input: string): string {
  const symbolMap: Record<string, string> = {
    'º': 'o',
    'ª': 'a',
    '°': 'o',
    '§': 'S',
    '–': '-',
    '—': '-',
    '´': "'",
    '`': "'",
  };

  return input
    .normalize('NFD')
    .replace(/[\u0300-\u036f]/g, '') // Remove diacríticos mantendo 1 char base
    .replace(/[^\x20-\x7E]/g, (ch) => symbolMap[ch] ?? ' ');
}

Rejeição cStat 878 na SEFAZ-MT (v0.56.143): O detalhe do protocolo http:// em <urlChave> e <qrCode>

Superada a barreira do encoding, quem emite NFC-e em produção (tpAmb=1) no estado de Mato Grosso encontra a validação da Regra ZX03-20 (cStat 878 — Rejeição: Endereço do site da UF da Consulta por chave de acesso diverge do previsto).

A causa é uma assimetria entre os ambientes de homologação e produção na tabela oficial de endereços da SEFAZ-MT:

• Em Homologação (tpAmb=2), a SEFAZ-MT utiliza https://homologacao.sefaz.mt.gov.br/....
• Em Produção (tpAmb=1), o Portal Nacional da NFC-e (nfce.encat.org/desenvolvedor/qrcode/) e o validador ZX03-20 da SEFAZ-MT exigem o protocolo http:// (sem s) tanto na URL base do <qrCode> quanto na tag <urlChave>.

Veja a tabela exata configurada na release v0.56.143 (src/lib/nfce/nfce-qrcode-urls.ts):

Se o seu sistema montar https://www.sefaz.mt.gov.br/nfce/consultanfce em produção, o autorizador MT_A2_NFCe-4.100 rejeita imediatamente o lote com cStat 878.

⚡ Resumo do Pipeline de Emissão de NFC-e para Mato Grosso na Notaas:

• 1. Recepção JSON Normal (Com Acentos): Sua aplicação envia os dados do cliente, endereço e produtos normalmente em UTF-8 para POST /api/v1/nfce.
• 2. Transliteração Determinística (v0.56.142): Para UF = MT (e em eventos RecepcaoEvento4 da v0.56.135), o builder converte o conteúdo textual do XML para ASCII 7-bit (0x20..0x7E) antes da assinatura XMLDSig, eliminando o cStat 402.
• 3. Resolução Exata de URLs (v0.56.143): O gerador de <infNFeSupl> injeta http://www.sefaz.mt.gov.br/nfce/consultanfce em produção e calcula o cHashQRCode com o CSC do emitente, eliminando o cStat 878.
• 4. Contingência e Alta Disponibilidade: Se o webservice estadual oscilar em datas de pico, nossa camada de contingência automática de NFC-e e NF-e garante a continuidade do PDV.

Emita NFC-e e NF-e em Mato Grosso e em todas as 27 UFs com uma única API

Não desperdice horas de engenharia mantendo regras de exceção de encoding e tabelas de URLs por estado no código do seu ERP ou PDV. Na API de Nota Fiscal Gratuita da Notaas, você envia o mesmo JSON limpo para qualquer estado brasileiro:

• 20 notas fiscais gratuitas por mês em Produção Real (1 CNPJ) + até 5 projetos simultâneos em Homologação via Org API.
• Suporte completo a NF-e (Mod 55), NFC-e (Mod 65), NFS-e (4.836 municípios) e CT-e/MDF-e.
• DANFE NFC-e 80mm e DANFE A4 gerados em milissegundos.

👉 Criar Conta Gratuita na Notaas Platform · Consultar a Documentação Técnica