Rejeição 613: recupere a chave que corresponde ao registro da SEFAZ

A rejeição 613, “Chave de Acesso difere da existente em BD”, indica uma diferença entre a chave usada na solicitação e aquela encontrada no banco de dados da SEFAZ. O caminho seguro é localizar o documento fiscal verdadeiro e conciliar seu registro no sistema. Não é uma autorização para trocar a chave de uma nota já autorizada ou emitir outra nota para a mesma venda.

Antes de mexer no faturamento, confirme qual chamada recebeu a resposta. Um botão chamado “cancelar” pode executar uma consulta de situação antes de enviar o evento. Nesse caso, a consulta pode ter parado com 613, sem que o cancelamento tenha sido transmitido.

O que a comparação realmente verifica

No MOC 7.0, Visão Geral, páginas 83 e 84, o código aparece na regra J06 do Web Service NfeConsultaProtocolo. A consulta usa a chave informada em consSitNFe/chNFe. A busca considera identificação do emitente, modelo, série e número, e há verificações posteriores dos componentes e da chave completa.

É possível, portanto, ter uma chave com estrutura aparentemente correta e, mesmo assim, obter 613. Ela pode representar uma versão local diferente daquela efetivamente registrada. Uma troca indevida do tipo de emissão, um arquivo de outra tentativa ou uma migração incompleta entre sistemas pode explicar o desencontro. São hipóteses para investigação, não conclusões extraídas apenas do número da rejeição.

A consulta documentada contempla modelos 55 e 65. Isso não transforma J06 em regra de todos os eventos, nem prova que a consulta pública por QR Code usa o mesmo retorno. Modelo, serviço, ambiente e autorizador precisam constar do diagnóstico.

Quais documentos reunir

Separe o XML original, seu protocolo, o retorno completo da tentativa e a chave que o sistema enviou. Um DANFE ajuda a identificar a operação, mas não substitui a conferência do arquivo eletrônico e do protocolo. Se houve troca de ERP, procure também os arquivos preservados no sistema anterior.

Compare estabelecimento, modelo, série e número antes de analisar caracteres isolados. Duas filiais podem usar numerações semelhantes. Produção e homologação também são ambientes diferentes: um registro de teste não confirma uma autorização em produção.

Na composição da chave, a identidade nem sempre segue a hipótese simplificada de “CNPJ da empresa”. Há emissão por CPF e situações especiais de nota avulsa. A integração deve interpretar o leiaute pertinente, preservando os 44 caracteres da chave autêntica. Com CNPJ alfanumérico, filtros que retiram letras podem corromper esse vínculo; não converta a chave em número de planilha.

Como corrigir o vínculo com segurança

1. Guarde a ocorrência antes de repetir. Registre cStat, xMotivo, horário, ambiente, endereço do serviço e versão do emissor. Preserve também as tentativas sem resposta conclusiva.

2. Localize a nota efetivamente registrada. Use o arquivo fiscal preservado, o protocolo e os meios oficiais disponíveis para aquele documento. Não construa chaves por tentativa para procurar registros.

3. Compare a chave completa com a enviada. Peça ao suporte que verifique o XML da solicitação, pois a tela pode mostrar um valor diferente do transmitido.

4. Concilie o cadastro local. Se o ERP guardou uma tentativa anterior, faça a recuperação ou importação do documento correto pelo procedimento do produto, mantendo o histórico anterior identificável.

5. Repita somente a consulta necessária. Confira a situação retornada e o documento a que ela se refere. O desaparecimento de 613, sozinho, não prova autorização nem cancelamento.

6. Retome a tarefa original separadamente. Se a intenção era registrar um evento, confira sua permissão, prazo e resultado individual depois que o vínculo estiver correto.

Não substitua manualmente a chave dentro do XML autorizado, não altere a assinatura e não apague protocolos para fazer os registros coincidirem. O ajuste no ERP deve recuperar a correspondência com o documento fiscal existente.

Exemplo: contingência e tentativa local

Uma empresa iniciou uma emissão normal, enfrentou uma interrupção e acionou uma modalidade de contingência admitida para seu cenário. Depois, o sistema ficou com arquivos de tentativas diferentes. Ao consultar a chave guardada na primeira tentativa, encontrou 613.

A equipe deve reconstruir a sequência: quais arquivos foram enviados, quais respostas chegaram e qual documento foi efetivamente registrado. Não basta mudar o tipo de emissão da nota antiga para o que parece ter funcionado. Também não se deve cancelar uma operação sem confirmar qual documento seria atingido.

EPEC exige cuidado adicional: seu registro não equivale à autorização da NF-e. A consulta possui tratamento para busca na base de eventos EPEC quando a NF-e não é encontrada. É preciso conservar e conciliar os resultados de cada etapa, sem transformar qualquer protocolo em autorização de uso.

Diferenças que evitam uma correção errada

O código 217 trata da ausência identificada na consulta, enquanto 613 trata da diferença de chave encontrada no ramo J06. As regras J04/562 e J05/561 examinam, respectivamente, código numérico e mês em confronto com a base. Esses retornos ajudam a localizar a divergência; não justificam modificar o documento registrado.

A rejeição 502 compara o identificador com os campos do próprio XML em contratos próprios. A 572 examina a composição do identificador do evento. Já 614, 615, 616 e 617 verificam componentes da chave em serviços determinados. Uma chave pode passar nessas verificações e ainda divergir da existente na base.

Se a dificuldade for a antiguidade da consulta, o código pertinente pode ser 526, com condições próprias. Não “atualize” o ano de uma chave antiga. Isso criaria outra identificação, sem recuperar a situação do documento procurado.

Eventos antigos e consultas públicas

O MOC 5.0 também registrava 613 no antigo serviço de cancelamento. Essa ocorrência histórica não transfere a regra para qualquer evento atual. Em contratos de eventos, a ausência ou divergência de vínculo tem outras validações, como 494, conforme o serviço.

As consultas públicas de QR Code da NFC-e e do DANFE Simplificado Tipo 2 da NF-e possuem tabelas próprias. Uma falha ao abrir o QR Code deve ser investigada com sua mensagem e versão, sem pressupor que J06 foi executada.

Para prevenir novos casos, mantenha um único vínculo confiável entre operação, XML, protocolo e chave, inclusive após migração ou contingência. Quando a chave local já coincidir com o arquivo original, encaminhe a comparação e o retorno ao suporte em canal seguro, sem repetir emissões.

Fontes e escopo

Base oficial: MOC 7.0 Visão Geral; NT 2015.002 v1.41, página 32; MOC 5.0, página 54, apenas histórico; NT 2026.004 v1.01, acervo preservado. Revisão documental em 10/10/2026, sem teste universal de autorizadores.

Apoio prático lido: NFeLink, Invoisys e TecnoSpeed. As orientações foram limitadas à recuperação da chave autêntica e à conciliação do sistema.