WhatsAppTeste grátis
Voltar para o blog

NF-e e NFC-e

Rejeição 539: duplicidade com chave diferente. Localize a nota já registrada

Se apareceu a rejeição 539, preserve a chave original e consulte o documento já registrado. A SEFAZ identificou uma colisão de identificação fiscal, embora a chave da tentativa atual seja diferente. Antes de reservar outro número, descubra se a operação já está documentada.

Blog ALRA
Capa ilustrada da ALRA: Rejeição 539: duplicidade com chave diferente. Localize a nota já registrada.

Se apareceu a rejeição 539, preserve a chave original e consulte o documento já registrado. A SEFAZ identificou uma colisão de identificação fiscal, embora a chave da tentativa atual seja diferente. Antes de reservar outro número, descubra se a operação já está documentada.

O que significa a mensagem

O retorno oficial é “Rejeição: Duplicidade de NF-e com diferença na Chave de Acesso”. A resposta pode apresentar a chave preexistente em chNFe e, em fluxo assíncrono, um recibo nRec quando o autorizador puder devolvê-lo.

A regra 2B08-10 do MOC 7.0, Anexo I, página 134, distingue os modelos:

  • Na NF-e, modelo 55, compara modelo, UF, CNPJ ou CPF do emitente, série e número

  • Na NFC-e, modelo 65, o texto da regra relaciona modelo, UF, CNPJ do emitente, série, número e tipo de emissão

Depois dessa identificação, verifica a diferença no código numérico ou em outras posições da chave. A regra está classificada como facultativa; sua presença no manual não certifica aplicação idêntica em todos os autorizadores. MOC, regra 2B08-10

Para NFC-e de produtor rural pessoa física, confirme com o suporte o tratamento do leiaute e da UF: a redação histórica dessa linha do MOC não basta para afirmar o alcance atual da identificação por CPF nesse cenário.

Por que isso acontece

Investigue principalmente:

  • A nota original foi recebida, mas o emissor não gravou a resposta e gerou outra chave na tentativa seguinte

  • O código numérico mudou entre transmissões da mesma operação

  • A empresa migrou de sistema e reutilizou série e número de documentos anteriores

  • Uma rotina reiniciou ou retrocedeu a numeração indevidamente

  • A passagem para contingência criou documentos cuja conciliação ainda não foi concluída

A data da chave não funciona como um mecanismo para liberar numeração antiga. Também não basta trocar cNF ou recalcular o dígito verificador. É necessário resolver a relação entre a tentativa nova e o documento existente.

Omie e Mainô descrevem conflitos de numeração em migrações; a Oobj acrescenta cenários de perda de resposta e geração de chave diferente. Essas hipóteses precisam ser confirmadas nos arquivos do caso, não presumidas pelo código isolado.

O que conferir antes de corrigir

  1. Preserve o XML da primeira transmissão, o da tentativa rejeitada e todas as respostas.

  2. Localize a chave informada no retorno 539. Se não estiver disponível, peça ao suporte para recuperá-la nos registros e sistemas anteriores.

  3. Consulte a situação da chave localizada no ambiente e no autorizador corretos.

  4. Compare emitente, modelo, série, número, tipo de emissão e as posições divergentes entre as chaves.

  5. Compare também a operação: destinatário, produtos, quantidades, valores e vínculo com a venda.

  6. Procure eventual EPEC ou outro documento gerado em contingência antes de concluir o diagnóstico.

Não trate o XML da tentativa rejeitada como se fosse o XML autorizado. Duas chaves diferentes exigem identificação precisa de qual documento recebeu cada retorno.

Como resolver em cada cenário

A nota encontrada está autorizada e corresponde à mesma operação

Recupere o XML autorizado e seu protocolo no armazenamento da empresa, no emissor anterior ou pelos recursos disponíveis. O suporte deve reconciliar esse documento com a venda e encerrar a tentativa rejeitada.

Não emita outra nota para compensar uma resposta perdida. Se houver outro XML para a operação, preserve-o no histórico e deixe claro que não recebeu aquela autorização.

A nota preexistente pertence a outra operação

Corrija o controle de série e numeração depois de examinar o histórico. Verifique se outros terminais ou sistemas usam a mesma sequência e se há faixas canceladas ou inutilizadas que também precisam ser consideradas.

Somente depois de confirmar que a operação atual continua sem documento, defina a emissão necessária com numeração válida. O levantamento não deve se limitar à última nota visível no sistema recém-instalado. Mainô, conferência da numeração em sistemas diferentes

Houve mudança de tipo de emissão ou geração de documento em contingência

Reúna os documentos dos dois fluxos. Confirme quais foram autorizados, quais apenas tiveram tentativa de envio e se existe EPEC pendente. Uma resposta 539 não elimina automaticamente as obrigações relacionadas à contingência.

O suporte deve conciliar as chaves e a contabilidade deve avaliar eventual duplicidade ou regularização. Não aplique indistintamente à NFC-e um diagnóstico baseado na NF-e: o tipo de emissão aparece na composição de consulta da regra do modelo 65.

A 539 surgiu na autorização de uma NFC-e ligada a EPEC

A NT NFC-e 2014.003 v1.02 trata dessa verificação na seção 05.1, de autorização da NFC-e. Ela também exige a conciliação dos dados da nota com o EPEC correspondente. Essa ocorrência documental não transforma 539 em rejeição genérica do registro do evento EPEC. NT NFC-e 2014.003 v1.02, página 15

Confirme o serviço que devolveu a mensagem e a disponibilidade desse procedimento na UF. Não descarte o EPEC nem crie outra nota sem esclarecer a situação da operação e do evento.

A consulta mostra cancelamento, outro estado ou não encontra a chave

Siga a situação comprovada, sem presumir autorização apenas pela palavra “duplicidade”. Confira ambiente e autorizador e verifique se a consulta usa a chave devolvida, não somente a chave rejeitada.

Se as respostas permanecerem incompatíveis, encaminhe XMLs, horários e retornos ao suporte. Não tente várias chaves até alguma ser aceita.

Exemplo hipotético

Uma loja de materiais elétricos transmite a NF-e 2.315, série 1. A SEFAZ a autoriza, mas a resposta não chega ao emissor. Ao repetir a operação, uma rotina gera outro código numérico, mantendo série e número. A tentativa recebe 539.

A equipe consulta a chave devolvida pela SEFAZ e confirma que ela corresponde à venda de R$ 748. Recupera o XML original autorizado, corrige o vínculo e ajusta a rotina que gerava outra chave. A venda permanece representada por uma única nota.

Como confirmar que foi resolvido

Confira se o documento correto está associado à operação, se seu XML corresponde à chave e ao protocolo arquivados e se o emissor reflete a situação oficial. Verifique se cessaram os reenvios que geravam novas chaves.

Quando houver contingência, inclua seus documentos e eventos na conferência. A simples retirada da mensagem 539 da tela não confirma que todo o histórico foi regularizado.

Nota técnica para quem integra sistemas

Preserve a chave original entre tentativas e não confunda a identidade usada na busca de duplicidade com a chave de acesso completa. Trate 539, 204 e 218 conforme o retorno efetivo e a consulta posterior, sem converter todos em “autorizado”.

Não torne o recibo um requisito universal de recuperação: a NT 2025.001 determina resposta síncrona para lote com uma NF-e. Use os serviços de recuperação compatíveis com o fluxo que realmente ocorreu. NT 2025.001 v1.03, seção 03.2

Para NFC-e, a NT 2023.002 já eliminou a requisição assíncrona e limitou o lote a uma NFC-e, com implantação em produção prevista para 04/09/2023. Considere recibos de envios históricos quando existirem, sem exigi-los de toda emissão atual. NT 2023.002 v1.01, seção 3.1

Referências

Revisão: 09/10/2026. Material informativo. A aplicação facultativa da regra, o modelo, a UF, o ambiente e o fluxo de contingência devem ser verificados no caso concreto.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.

Baixar teste grátisFalar no WhatsApp