Duplicidade de NF-e com diferença na Chave de Acesso

O que significa esta rejeição

A SEFAZ já tem uma NF-e autorizada com a mesma combinação de CNPJ do emitente, modelo, série e número (<nNF>), mas a nota que acabou de chegar gera uma chave de acesso de 44 dígitos diferente da que já está na base. Como a numeração lógica coincide, mas a chave de acesso diverge, a SEFAZ trata como duplicidade e rejeita com 539.

A chave de acesso é formada por vários campos. Além de CNPJ, modelo, série e número, ela inclui a data de emissão (mês e ano), o tipo de emissão (<tpEmis>) e o código numérico aleatório (<cNF>), entre outros. Qualquer diferença nesses campos, mantendo o mesmo número de nota, produz uma chave diferente e dispara a rejeição.

Causas mais comuns

• Instabilidade na comunicação: a SEFAZ autorizou a nota, mas o retorno não chegou ao emissor. O operador ativa contingência e reenvia a nota, que volta com <tpEmis> diferente e, portanto, chave diferente.
• Reenvio da mesma nota com algum dado alterado (data de emissão, <cNF>) depois que a original já foi autorizada.
• Reuso de numeração em ano seguinte: como o mês/ano entra na chave, a mesma série e número emitidos no ano anterior geram chave diferente e colidem.
• Geração de novo <cNF> aleatório em uma retransmissão, mantendo o mesmo <nNF> da nota já autorizada.
• Dois fluxos paralelos (normal e contingência) usando a mesma faixa de numeração.

Regra de validação oficial

A SEFAZ verifica se já existe NF-e autorizada para a mesma combinação de CNPJ do emitente, modelo, série e número. Se existir, mas a chave de acesso completa de 44 dígitos for diferente da já registrada, a operação é rejeitada com 539. A distinção em relação à 204 é justamente essa: na 204 a chave é idêntica (retransmissão pura); na 539 a numeração coincide mas a chave diverge.

Exemplo XML, antes (errado)

Primeira nota autorizada (chave termina em ...1234567890):

<ide>
  <mod>55</mod>
  <serie>1</serie>
  <nNF>15842</nNF>
  <dhEmi>2026-05-22T14:30:00-03:00</dhEmi>
  <tpEmis>1</tpEmis>
  <cNF>00012345</cNF>
</ide>

Reenvio em contingência com o mesmo número (gera chave diferente, rejeitado com 539):

<ide>
  <mod>55</mod>
  <serie>1</serie>
  <nNF>15842</nNF>
  <dhEmi>2026-05-22T14:35:00-03:00</dhEmi>
  <tpEmis>9</tpEmis>
  <cNF>00098765</cNF>
</ide>

Exemplo XML, depois (correto)

Como a nota original já está autorizada, a operação seguinte usa a próxima numeração disponível:

<ide>
  <mod>55</mod>
  <serie>1</serie>
  <nNF>15843</nNF>
  <dhEmi>2026-05-22T14:35:00-03:00</dhEmi>
  <tpEmis>1</tpEmis>
  <cNF>00078902</cNF>
</ide>

Passo a passo para corrigir

1. Consulte a situação da NF-e na SEFAZ pela numeração (<serie> + <nNF>) ou pela chave da nota original. Confirme se ela já está autorizada.
2. Se a nota original está autorizada, baixe o XML e o protocolo, e arquive. A operação fiscal já está registrada.
3. Não reenvie a mesma operação com numeração repetida. Para uma nova nota, incremente o <nNF> e gere novo <cNF>.
4. Separe as faixas de numeração de emissão normal e de contingência para evitar colisão de chave entre os dois fluxos.
5. Ao reusar série e número em ano novo, lembre que o mês/ano entra na chave; use numeração ainda não autorizada.
6. Reenvie com a numeração correta.

Como o FazendaNota previne

O FazendaNota persiste a chave de acesso no momento da geração da nota e controla a numeração de forma sequencial, sem reaproveitar <nNF> já autorizado. Em caso de queda de comunicação, o emissor consulta a situação da nota na SEFAZ antes de reenviar, evitando gerar uma segunda chave para a mesma operação.

Rejeições relacionadas

• Rejeição 204, Duplicidade de NF-e
• Rejeição 217, NF-e não consta na base de dados da SEFAZ
• Rejeição 218, NF-e já está cancelada na base de dados da SEFAZ

Referência oficial

Esta rejeição está descrita no Anexo I - Leiaute e Regra de Validação do Manual de Orientação do Contribuinte (MOC) v7.0 da NF-e, publicado pelo CONFAZ. Texto integral em https://www.confaz.fazenda.gov.br/legislacao/arquivo-manuais/moc7-visao-geral.pdf