Rejeição 562: como recuperar a chave com o código numérico correto

A rejeição 562 deve ser investigada começando pelo serviço que respondeu. Em NfeConsultaProtocolo, ela indica que o código numérico presente na chave consultada difere daquele existente no banco da Sefaz. A solução é recuperar a identificação correta do documento e sincronizar sua situação no sistema, sem gerar outra nota só porque a consulta falhou.

O alerta é importante porque uma nota pode ter sido processada enquanto o ERP perdeu a resposta ou conservou outra chave. O código 562, sozinho, não comprova que a emissão foi recusada nem que o número está disponível para uso.

O que é o código numérico

O código numérico cNF é um componente de oito dígitos da chave de acesso. Ele ocupa as posições 36 a 43. O número sequencial da nota, nNF, é outro campo e ocupa as posições 26 a 34. O dígito verificador final, cDV, fica na posição 44.

Confundir esses campos leva a correções indevidas. A rejeição 562 não é uma ordem para avançar o número da nota, alterar sua série ou escolher um novo cNF. Ela pede a identificação da diferença entre a chave usada na consulta e o registro fiscal ao qual a consulta se refere.

O código numérico é definido na geração do documento, mas precisa permanecer coerente com aquela emissão. Regerá-lo a cada consulta ou tentativa de recuperar status faz o sistema procurar uma identificação diferente.

A regra J04 compara com o banco da Sefaz

A Tabela 5-16 do MOC 7.0, Visão Geral, página 84 vincula a rejeição 562 à regra J04. A aplicação é obrigatória no serviço de consulta de situação da NF-e, que admite os modelos 55 e 65.

Nessa etapa, o serviço verifica se o código numérico da chave apresentada diverge do existente no banco. A pesquisa anterior utiliza identificação do emitente, modelo, série e número, com tratamento de EPEC quando previsto. O pedido de consulta leva chNFe em consSitNFe; não leva o XML completo de uma nova venda.

Uma divergência entre o atributo Id e os campos internos de um XML de autorização é outro controle: A03-10, associado à rejeição 502. Embora os problemas possam ter a mesma origem no emissor, não se deve substituir a definição de J04 por uma comparação restrita a dois campos do arquivo local.

Quando a mensagem apresenta outra chave

O MOC permite acrescentar à mensagem de erro a chave existente no banco em situações específicas de identificação do transmissor. Entre elas estão a coincidência do CNPJ-base do certificado de transmissão com o do emitente, destinatário ou transmissor da nota, e a coincidência do CPF do certificado com o CPF do emitente.

Essa informação é opcional. Sua ausência não comprova que o documento deixou de existir nem significa, automaticamente, defeito no certificado. Se a resposta trouxer chNFe, confira sua relação com a operação e utilize-a para recuperar o registro correto pelos meios permitidos.

Não publique a chave ou os XMLs em fóruns abertos para pedir ajuda. Encaminhe os arquivos necessários ao suporte autorizado da empresa, com o retorno íntegro e contexto suficiente para a investigação.

Como resolver sem duplicar o documento

1. Identifique a chamada que retornou 562. Se o ERP só mostra um botão de transmitir, peça o histórico para separar envio, consulta e processamento da resposta.

2. Confira UF, modelo, autorizador e ambiente. Produção e homologação têm bases distintas; tpAmb deve corresponder ao serviço usado.

3. Recupere os arquivos da tentativa original, os retornos e os protocolos disponíveis. Compare a chave do XML, a do protocolo e chNFe da consulta rejeitada.

4. Se houver chave devolvida pela Sefaz, confira-a com a operação e investigue o registro indicado. Se não houver, utilize os arquivos originais e os recursos oficiais disponíveis ao emitente para esclarecer a situação.

5. Corrija a associação local e consulte a chave verdadeira. Registre o status obtido e só prossiga com a providência fiscal compatível com ele.

Quando a nota já foi autorizada, a tarefa é recuperar o XML correspondente e atualizar seu estado no ERP. Não substitua um documento autorizado por um arquivo local reconstruído que usa outro cNF, mesmo que número e série pareçam iguais.

Se os arquivos se perderam e a situação continua inconclusiva, não avance a numeração como tentativa de resolver. O suporte e o responsável fiscal precisam esclarecer o documento existente antes de autorizar qualquer nova emissão relacionada à mesma operação.

Exemplo parcial: dois cNF para a mesma tentativa

Imagine, apenas como ilustração, que o arquivo original tenha cNF igual a 48290173, mas uma rotina posterior passe a consultar uma chave com cNF igual a 60518429. Não são chaves completas nem exemplos de documentos reais. O cenário mostra apenas que duas identificações diferentes podem ter sido associadas localmente ao mesmo pedido comercial.

A correção não é escolher o código que parece mais recente. É descobrir qual integra o documento efetivamente registrado e recuperar sua chave completa. Se a origem foi uma rotina que sorteia cNF novamente ao consultar, ela precisa ser ajustada para reutilizar a identificação persistida.

O cuidado com orientações genéricas

A TecnoSpeed menciona a possibilidade de já existir nota com mesmo número e série sob outra chave. A Maxiprod orienta investigar o processamento com o suporte. O guia da NS7 aborda a coerência do código numérico.

Esses materiais ajudam a localizar falhas de integração, mas instruções genéricas para regerar a chave e emitir novamente exigem cautela. No cenário de J04, a prioridade é a comparação com o banco da Sefaz e a recuperação do estado fiscal, não a criação de uma nova identidade.

Também não use refNFeSig como atalho: ela é uma referência em sigilo com finalidade própria, não uma chave substituta para a consulta de situação. Zerar cNF de uma chave comum não recupera o documento original.

Conferência documental: 9 de outubro de 2026. A NT 2026.004 v1.01 também exige preservar letras legítimas no trecho de CNPJ da chave. A regra analisada é J04 de NfeConsultaProtocolo; outros serviços e consultas públicas precisam de diagnóstico próprio.