Rejeição 464 da NFC-e e hash inválido na consulta do QR Code

Na autorização da NFC-e, a rejeição 464 indica que o hash do QR Code enviado diverge do cálculo esperado. A investigação precisa comparar versão, parâmetros, ambiente e configuração do CSC. Embora o segredo incorreto seja uma possibilidade, não é a única: a montagem da sequência usada no cálculo também pode estar errada.

Na consulta pública, o código 100 informa hash do QR Code inválido. Esse aviso pertence a outro serviço e não deve ser confundido com cStat 100 de autorização de uso. A seguir, os dois cenários são tratados com seus limites.

Primeiro identifique qual QR Code foi gerado

O MOC 7.0 prevê a rejeição 464 na regra ZX02-320 para QR versão 2. Também registra ZX02-120 para a versão histórica “100”. A presença do leiaute antigo no documento não justifica adotá-lo para corrigir uma emissão atual. MOC 7.0, páginas 130 e 133.

Confirme modelo 65, versão do QR e modo de emissão no XML da tentativa, especialmente infNFeSupl/qrCode. Registre cStat, mensagem completa, UF, ambiente e versão do emissor. Não analise somente uma imagem impressa ou a configuração atual: elas podem não corresponder ao arquivo rejeitado.

Hash divergente, hash ausente e parâmetro fora do formato hexadecimal têm verificações diferentes. Na v2, o MOC associa a ausência a 396 e a falha de formato a 400. Leia o retorno recebido, sem chamar toda inconsistência do QR de 464.

O que entra no cálculo da versão 2

O hash é um resultado calculado com os parâmetros definidos no manual e o CSC da empresa. O CSC deve permanecer protegido na configuração; ele não é publicado na URL. O identificador do CSC, por sua vez, aparece no QR e permite localizar o registro usado.

Na emissão online v2, a sequência contém chave, versão, ambiente e identificador. O programa concatena esses valores na ordem especificada, separados por barras verticais, acrescenta o CSC ao final da sequência e calcula SHA-1, representado por 40 caracteres hexadecimais. O hash é o quinto parâmetro da URL final.

Na contingência offline v2, entram também dia de emissão, valor total e DigestValue convertido para hexadecimal, antes do identificador. O hash fica na oitava posição. O DigestValue vem da assinatura do XML e precisa corresponder ao documento; ele não é o próprio hash dos parâmetros do QR. Manual DANFE NFC-e v6.0, páginas 21–24.

Esses detalhes servem para orientar o suporte técnico. Não é necessário que o empresário faça o cálculo manualmente, nem envie o CSC a um site público de testes.

Uma ordem prática de verificação

1. Confira empresa, UF e ambiente da emissão e da configuração utilizada. Produção e homologação precisam usar as credenciais fornecidas para o contexto correto.

2. Um operador autorizado deve comparar localmente identificador e CSC com o cadastro oficial, preservando o segredo exatamente como fornecido, inclusive caracteres significativos.

3. Verifique espaços acidentais, campos invertidos e configurações antigas em caixas, integrações ou filas.

4. Solicite ao fornecedor a comparação entre os parâmetros realmente usados no cálculo e aqueles gravados no QR, incluindo ordem, separadores e formatação.

5. Gere novamente pelo fluxo correto do emissor e confira o novo retorno individual.

A TecnoSpeed orienta revisar ambiente e correspondência entre CSC e identificador. Sua instrução de preencher seis posições refere-se à configuração do produto; o manual determina que o identificador na URL v2 apareça sem zeros não significativos. Não transfira uma máscara de tela diretamente para a sequência de cálculo.

O Gweb também destaca os três campos de configuração. A Alterdata recomenda conferir o CSC utilizado pelo emissor. Persistência do erro, contudo, não prova por si só que o segredo continua incorreto. É necessário investigar a geração do QR antes de revogar ou criar credenciais.

Exemplo de falha que não está no segredo

Uma loja fictícia recebe a rejeição depois de atualizar sua integração de contingência. O CSC e o identificador estão corretos, mas a rotina passou a formatar o valor total com vírgula, enquanto outra etapa preservou ponto na sequência enviada. Os valores usados no cálculo e no QR deixaram de coincidir.

A equipe reproduz o cenário em teste com dados próprios de homologação, compara as duas sequências localmente e corrige a formatação. Não muda o valor da venda e não troca o CSC sem necessidade. Na v2 offline, o manual exige ponto decimal e ausência de separador de milhar no parâmetro de valor.

O mesmo raciocínio vale para parâmetros reaproveitados de outra versão ou para um QR montado com dados anteriores à geração definitiva do documento. A correção deve manter coerência entre XML, URL e impressão.

Consulta pública NFC-e: código 100, hash do QR Code inválido

Na tabela de consulta do Manual v6.0, o código 100 significa hash inválido. A descrição é mais ampla que a comparação especificada na regra 464 e não estabelece equivalência entre os dois retornos. Manual v6.0, item 5.3, páginas 38–39.

Confira URL oficial, UF, ambiente, versão e modo. Compare o conteúdo lido com a origem, procurando cortes, alterações de separadores ou conversões indevidas. Na v2, o suporte deve verificar a sequência e o cálculo localmente. Se a mensagem efetiva mencionar vínculo ou identificador do CSC, os códigos de consulta 101, 103 e 104 têm diagnóstico próprio no artigo 462.

Uma nota com protocolo de autorização não se torna rejeitada porque o consumidor recebeu 100 na consulta. Preserve o XML autorizado; não gere outra venda, modifique o arquivo fiscal ou recompute parâmetros de uma nota histórica indiscriminadamente. Defeito no documento auxiliar e inconsistência no portal exigem investigação específica.

A versão 3 exige outra abordagem

A v3 online leva somente chave, versão e ambiente. Na contingência, usa campos próprios e assinatura com certificado digital. Não inclua CSC, identificador, hash da v2 ou DigestValue como parâmetros avulsos. A assinatura de contingência possui regras e retornos próprios, inclusive 583 para divergência; não a trate automaticamente como 464. NT 2025.001 v1.03, páginas 5, 13–14.

A tabela da consulta não define todos os códigos por versão. Se o portal acusar CSC ou hash em um QR identificado como v3, preserve a resposta e confira geração e serviço com o fornecedor. A extinção definitiva do CSC continua sem data geral nessa NT.

Ao concluir, confirme autorização e protocolo no cenário de emissão, ou a consulta correta no cenário de leitura. O desaparecimento da mensagem inicial, sozinho, não comprova que toda a operação terminou.

Referência documental: 09/10/2026. Conteúdo ALRA original; conferir aplicação por serviço, UF e ambiente.