Rejeição 395: endereço da consulta via QR-Code divergente

A Rejeição 395, regra ZX02-20, indica que o endereço do site da UF para consulta via QR-Code diverge do previsto. O exame recai sobre a URL informada em NFe/infNFeSupl/qrCode. Conseguir abrir um site no navegador não comprova que aquele é o endereço de consulta esperado pelo autorizador.

Qual endereço deve ser comparado?

Separe a base da URL, que contém protocolo, domínio e caminho da consulta, dos parâmetros que identificam a nota. Confira a base na publicação oficial da UF e na relação indicada pelo Manual DANFE NFC-e/QR-Code. O manual aponta os endereços por UF e ambiente no Portal Nacional da NFC-e; este artigo não fornece um endereço genérico para substituir a configuração real.

A URL de consulta via QR-Code é diferente da URL de autorização do webservice e pode ser diferente de urlChave, usada para consulta manual por chave de acesso. Não use a página inicial institucional da SEFAZ nem copie a URL de outra UF. Em algumas UFs, o mesmo endereço atende produção e homologação e o parâmetro tpAmb distingue os ambientes; portanto, igualdade de domínio não basta para conferir ambiente.

Maiúsculas, ambiente e DANFE Tipo 2 mudam a regra?

A ZX02-20 determina que diferenças de maiúsculas e minúsculas não sejam consideradas nessa validação do endereço. Isso não autoriza transformar indiscriminadamente todos os parâmetros, hashes ou assinaturas em minúsculas: são conteúdos com outras regras.

A observação de validação opcional até 01/11/2016 é histórica, não uma dispensa atual. A NT 2026.002 v1.11 aplica a regra aos modelos 55/65 quando qrCode foi informado e acrescenta que a NF-e modelo 55 usa a mesma URL de consulta QR-Code da NFC-e modelo 65. A extensão do Tipo 2 tem cronograma de testes 01/07/2026 e produção 03/08/2026; confirmar a situação individual do autorizador permanece necessário.

A NT 2025.001 introduziu QR-Code 3 sem exigir que todo emitente pessoa jurídica abandone a versão 2. Endereço correto e versão correta são verificações diferentes; trocar a versão não demonstra correção da base da URL.

Exemplo: serviço correto com configuração antiga

Cenário sintético A: a empresa transmite ao autorizador correto de sua UF, mas o gerador de QR-Code conserva uma base de consulta usada em outro ambiente de teste. A autorização e o QR-Code usam configurações distintas. A comparação entre a URL realmente enviada e a publicação atual da UF permite localizar o erro sem mudar a UF da nota.

Cenário sintético B: o domínio coincide com o oficial, mas o caminho aponta para a consulta por chave. A página abre normalmente; mesmo assim, não corresponde ao serviço QR-Code exigido. O próximo passo é revisar o mapeamento entre qrCode e urlChave, preservando os valores do documento.

Não há XML operacional: a conferência depende da URL oficial específica e da chave e dos parâmetros protegidos da tentativa. Os cenários não fabricam domínio fiscal, CSC, hash ou assinatura.

Como corrigir a origem e confirmar?

Registre UF, ambiente, modelo, versão do QR-Code e a URL que consta do XML enviado, com acesso restrito aos dados da nota. Compare protocolo, domínio e caminho com a fonte oficial atual e verifique se houve concatenação, redirecionamento ou cache de configuração indevido no emissor.

Atualize somente a origem comprovadamente incorreta, gere e valide de forma coerente com os demais parâmetros. Não altere uma nota autorizada nem trate impressão ou acesso HTTP bem-sucedido como nova autorização. Antes de considerar novo envio após falha de comunicação, esclareça o estado da tentativa anterior.

Fontes oficiais

• MOC 7.0 Anexo I — 7.00: pp. 65–66 leiaute ZD/ZX; pp. 128–133 regras ZD/ZX.
• NT 2025.001 — 1.03 corrigida: pp. 2–3 cronograma; p. 5 transição; pp. 8,11–14 QR-Code e rasuras.
• Manual de Padrões Técnicos DANFE NFC-e e QR Code — 6.0, março/2025: p. 5 fim QR 1; pp. 20–27 QR 2; pp. 28–32 QR 3.
• NT 2026.002 — 1.11: p. 3 cronograma; pp. 20–24 regras ZX e alterações Tipo 2.