Rejeição 658 — UF do destinatário da Chave de Acesso diverge da UF autorizadora

O que é esta rejeição?#

A Rejeição 658 é 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: UF do destinatário da Chave de Acesso diverge da UF autorizadora.

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 código IBGE da UF informada em emit/enderEmit/UF então há divergência entre a UF emitente codificada na chave e a UF do XML, indicando que a chave foi gerada com cUF incorreto ou que o campo UF do emitente foi alterado após a geração da chave: reconstrua a chave de acesso usando o cUF correto da UF autorizadora e recalcule o dígito verificador pelo algoritmo módulo 11.
• Se os dígitos nas posições 4-9 da chave de acesso (AAMM de emissão) não corresponderem ao ano e mês extraídos do campo ide/dhEmi então a data codificada na chave diverge da data de emissão declarada no XML, o que invalida a chave independentemente do dígito verificador estar correto: regenere a chave com o AAMM derivado de ide/dhEmi e recalcule o dígito verificador.
• Se os dígitos nas posições 10-23 da chave de acesso não corresponderem ao CNPJ informado em emit/CNPJ (sem pontuação) então o emitente codificado na chave difere do emitente declarado no XML, causando rejeição mesmo que o dígito verificador isolado seja válido: extraia o CNPJ limpo de emit/CNPJ, recomponha a chave e recalcule o módulo 11.
• Se os dígitos nas posições 26-34 da chave de acesso (série nas posições 26-28 e número nas posições 29-34) não corresponderem, respectivamente, aos campos ide/serie e ide/nNF formatados com seus comprimentos fixos então existe inconsistência entre a numeração da nota e a chave emitida, podendo ocorrer quando o número é incrementado após a geração da chave ou quando série é padded incorretamente: recomponha a chave com serie zero-padded em 3 dígitos e nNF zero-padded em 9 dígitos e recalcule o dígito verificador.
• Se o 44º dígito da chave de acesso (dígito verificador cDV em ide/cDV) não coincidir com o resultado do cálculo módulo 11 aplicado sobre os primeiros 43 dígitos da chave — usando pesos 2 a 9 ciclicamente da direita para a esquerda e adotando 0 quando o resto for 0 ou 1 — então a chave está corrompida e será rejeitada pela SEFAZ independentemente dos demais campos estarem corretos: recalcule o dígito verificador seguindo rigorosamente o algoritmo da NT 2019.001 e atualize simultaneamente ide/cDV e o atributo Id do elemento infNFe antes de assinar e transmitir.