Rejeição 316 — Chave de Acesso referenciada com a mesma Chave de Acesso da Nota Fiscal atual

O que é esta rejeição?#

A Rejeição 316 é 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.

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 campos cUF (2 dígitos), AAMM (4 dígitos derivados de dhEmi), CNPJ emit (14 dígitos), mod (2 dígitos), serie (3 dígitos), nNF (9 dígitos) e cNF (8 dígitos) concatenados e recalculados com módulo 11 produzirem cDV diferente do cDV declarado na chave de acesso em chNFe, então o dígito verificador está correto somente na chave referenciada mas incorreto na chave atual, criando autorreferência ao ser rejeitada: reconstrua a chave de acesso completa a partir dos campos canônicos do XML, recalcule o dígito verificador e substitua o valor de cDV antes de retransmitir.
• Se o cUF embutido nas posições 1-2 da chave de acesso em chNFe divergir do cUF declarado no elemento ide ou da UF do CNPJ emit consultado na Receita Federal, então o componente UF da chave foi gerado a partir de uma fonte incorreta (ex.: UF do destinatário ou UF hardcoded errada) fazendo a chave não representar a NF-e atual: corrija o cUF para o código IBGE da UF do emitente conforme tabela SEFAZ e regenere toda a chave.
• Se o AAMM extraído das posições 3-6 da chave de acesso não corresponder ao ano e mês de dhEmi (ex.: dhEmi='2024-03-15' exige AAMM='2403' mas a chave contém '2303'), então a chave foi gerada com data de emissão de competência anterior ou futura em relação à data declarada no XML, tornando a chave auto-inconsistente e passível de duplicidade com nota de outra competência: atualize o AAMM da chave para coincidir exatamente com ano/mês de dhEmi e recalcule o cDV.
• Se o nNF nas posições 32-40 da chave de acesso (zero-padded 9 dígitos) não for idêntico ao nNF declarado no elemento ide, então o número da nota fiscal usado para compor a chave diverge do número informado no documento, gerando uma chave que referencia uma nota inexistente ou de terceiros: sincronize o nNF da chave com o nNF do elemento ide, assegure padding esquerdo com zeros até 9 dígitos e recalcule o cDV.
• Se cNF (posições 36-43 da chave, 8 dígitos) for igual a '00000000' ou for numericamente idêntico ao nNF zero-padded, então o código aleatório foi gerado de forma inválida ou derivado diretamente do número da nota, reduzindo a entropia da chave e podendo colidir com outra chave existente além de falhar na validação SEFAZ: gere um novo cNF pseudoaleatório de 8 dígitos distinto de zero absoluto e diferente do nNF, atualize a chave e recalcule o cDV com módulo 11.