Rejeição 484 — Chave de Acesso com tipo de emissão diferente de 4 (posição 35 da Chave de Acesso)

O que é esta rejeição?#

A Rejeição 484 é 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: DPEC com tipo de emissão diferente de “4”(posição 35 da Chave de Acess.

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 dígito na posição 35 da chave de acesso (tpEmis) for diferente do valor declarado no campo ide/tpEmis do XML, então há inconsistência entre o tipo de emissão embutido na chave e o informado no elemento de identificação da NF-e: reconstrua a chave de acesso concatenando cUF+AAMM(dhEmi)+CNPJ(emit)+mod+serie+nNF+tpEmis+cNF e recalcule o dígito verificador (posição 44) pelo algoritmo módulo 11 da SEFAZ, garantindo que tpEmis=4 em ambos os locais caso a emissão seja em contingência DPEC.
• Se os primeiros dois dígitos da chave de acesso (cUF embutido) forem diferentes do código IBGE da UF presente em emit/enderEmit/UF, então o componente de UF foi preenchido com valor errado na montagem da chave: corrija o prefixo da chave usando o código numérico IBGE correto da UF do emitente (ex: 35 para SP, 33 para RJ) e regenere os 44 dígitos completos antes de retransmitir.
• Se os dígitos nas posições 4 a 9 da chave de acesso (AAMM) não corresponderem ao ano e mês extraídos de ide/dhEmi (formato AAAA-MM-DD), então a data de emissão usada na montagem da chave está divergente da data declarada no XML: sincronize a competência AAMM da chave com o campo dhEmi e refaça o cálculo do dígito verificador módulo 11.
• Se os 14 dígitos nas posições 10 a 23 da chave de acesso (CNPJ do emitente embutido) forem diferentes do valor de emit/CNPJ declarado no XML, então o CNPJ usado na geração da chave não pertence ao emitente da nota: atualize esse segmento com o CNPJ correto do emitente, regenere o cNF aleatório se necessário e recalcule o dígito verificador antes de retransmitir.
• Se o campo ide/cNF (8 dígitos, posições 36 a 43 da chave) contiver apenas zeros (00000000) ou não corresponder ao trecho extraído da chave de acesso em infNFe/@Id, então o código numérico aleatório foi gerado de forma inválida ou não foi propagado corretamente para a chave: gere um cNF aleatório não nulo com exatamente 8 dígitos, insira-o tanto em ide/cNF quanto no segmento correto da chave, e recalcule o dígito verificador módulo 11 para obter a chave final de 44 dígitos.