Rejeição 522 — Chave de Acesso referenciada com UF inválida

O que é esta rejeição?#

A Rejeição 522 é 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: CFOP de Operação Estadual e UF emitente difere UF destinatário.

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 o código de UF contido nos dois primeiros dígitos da chave de acesso (cChave[1..2]) não corresponde ao cUF informado no campo ide/cUF E este por sua vez não coincide com a UF do endereço do emitente (emit/enderEmit/UF), então há tripla inconsistência de UF que invalida a chave de acesso: alinhe os três valores ao código IBGE correto da UF do emitente antes de recalcular o dígito verificador.
• Se o número da NF-e (ide/nNF) formatado com 9 dígitos não coincide com os dígitos 26 a 34 da chave de acesso, ou a série (ide/serie) formatada com 3 dígitos não coincide com os dígitos 23 a 25, então os componentes sequenciais da chave foram montados fora de ordem ou com zero-padding incorreto: recomponha a chave concatenando cUF(2)+AAMM(4)+CNPJ(14)+mod(2)+serie(3)+nNF(9)+tpEmis(1)+cNF(8) e recalcule o dígito verificador.
• Se o CNPJ do emitente (emit/CNPJ) com 14 dígitos não coincide com os dígitos 7 a 20 da chave de acesso, então a chave foi gerada com CNPJ divergente do emitente declarado no XML, possivelmente por troca de estabelecimento ou erro de template: extraia os 14 dígitos da posição correta da chave atual, compare com emit/CNPJ e regenere a chave a partir dos dados do XML vigente.
• Se a competência AAMM extraída dos dígitos 3 a 6 da chave de acesso não corresponde ao ano e mês de ide/dhEmi, então a chave foi gerada em data diferente da emissão declarada no XML, o que ocorre tipicamente quando o sistema reusa uma chave de contingência ou incrementa o número sem regenerar a chave: recalcule AAMM a partir de ide/dhEmi e regenere a chave completa com novo cNF aleatório e novo dígito verificador.
• Se o dígito verificador (posição 44 da chave de acesso) não resulta do algoritmo módulo 11 com pesos 2 a 9 ciclicamente aplicados da direita para a esquerda sobre os 43 dígitos anteriores, onde o resto 0 ou 1 mapeia para dígito verificador 1, então o dígito verificador está incorreto independentemente dos demais campos: recalcule o módulo 11 sobre os 43 primeiros dígitos da chave já corrigida e substitua o 44º dígito pelo valor apurado antes de retransmitir.