Rejeição 613 — Chave de Acesso difere da existente em BD

O que é esta rejeição?#

A Rejeição 613 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a chave de acesso que identifica unicamente a NF-e, dígito verificador calculado a partir da chave de acesso. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Este código indica que rejeição: Chave de Acesso difere da existente em BD.

Os campos afetados estão na seção de chave de acesso, identificação da NF-e do XML.

Campos XML relacionados#

Esta rejeição está associada aos seguintes campos do XML da NF-e. Verifique cada um deles ao diagnosticar o problema:

Causas comuns#

• O dígito verificador da chave de acesso está incorreto
• A chave de acesso tem formato inválido (deve ter exatamente 44 dígitos)
• Os componentes da chave (UF, data, CNPJ, modelo, série, número) não correspondem aos dados da NF-e
• O código numérico aleatório (cNF) está ausente ou com formato incorreto

Como resolver#

1. Recalcule o dígito verificador usando o algoritmo módulo 11 conforme especificação da SEFAZ
2. Verifique se todos os componentes da chave de acesso correspondem aos dados informados na NF-e
3. Confirme que a chave tem exatamente 44 dígitos numéricos, sem espaços ou caracteres especiais
4. Regenere a chave de acesso completa no seu sistema emissor e retransmita

Verificações analíticas#

• Se os dois primeiros dígitos da chave de acesso (posições 1-2) não corresponderem ao cUF do elemento ide/cUF, e o cUF do emit/enderEmit/UF também divergir, então há tripla inconsistência de UF entre chave, ide e emitente: reconstrua a chave extraindo o cUF diretamente do cadastro do emitente e valide se a UF é um código IBGE válido de 2 dígitos (11-53).
• Se as posições 3-6 da chave de acesso (AAMM) não corresponderem ao ano e mês extraídos de ide/dhEmi, então a data de emissão usada na composição da chave diverge da data declarada no XML: recalcule o AAMM a partir de dhEmi e regenere a chave garantindo que dhEmi não esteja em fuso horário convertido erroneamente que altere o mês.
• Se as posições 21-25 da chave de acesso (modelo+série, sendo mod=2 dígitos e série=3 dígitos) não baterem com ide/mod='55' e ide/serie, então o modelo ou a série foram inseridos com padding incorreto na montagem da string da chave: normalize modelo para 2 dígitos e série para 3 dígitos com zeros à esquerda antes de concatenar.
• Se as posições 26-34 da chave (nNF com 9 dígitos) não corresponderem ao ide/nNF com padding de zeros à esquerda, e simultaneamente o dígito verificador na posição 44 falhar na verificação módulo 11 com pesos 2-9 aplicados da direita para a esquerda sobre os 43 primeiros dígitos, então o número da nota foi truncado ou não foi zerado à esquerda antes da composição: formate nNF como string de 9 caracteres com zeros à esquerda e recalcule o DV pelo algoritmo SEFAZ (resultado 0 ou 1 → DV=1, caso contrário DV=11−resto).
• Se as posições 35-43 da chave de acesso (cNF, 8 dígitos) não coincidirem com o valor de ide/cNF no XML, ou se ide/cNF contiver menos de 8 dígitos numéricos ou for composto apenas por zeros (00000000), então o código numérico aleatório está ausente, malformatado ou não foi persistido corretamente antes da composição da chave: gere um cNF aleatório de 8 dígitos não nulos, armazene-o em ide/cNF, use-o na posição 35-43 da chave e só então calcule o dígito verificador na posição 44.