stackinRejeição 539 na NF-e: o que é e como resolver
Rejeição 539 da NF-e: duplicidade com diferença na chave de acesso. O que a SEFAZ verifica, por que acontece e como resolver sem emitir a mesma venda duas vezes.
A rejeição 539 da NF-e tem, no leiaute oficial, o texto "Rejeição: Duplicidade de NF-e com diferença na Chave de Acesso", seguido de uma chave entre colchetes (chNFe). Pelo Anexo I do Manual de Orientação do Contribuinte, ela significa que a SEFAZ já tem cadastrada uma NF-e com o mesmo modelo, UF, CNPJ/CPF do emitente, série e número — mas a chave de acesso que você enviou é diferente da registrada, seja no código numérico, seja em outras posições da chave.
Para resolver, descubra primeiro o que está cadastrado naquele número. Compare a chave que veio na mensagem com a que você enviou e consulte a situação na SEFAZ: se a NF-e registrada é a mesma venda enviada de novo, ela já existe e emitir outra duplicaria a operação. Se o número pertence a outra nota, emita com um número ainda não usado na série e, se números ficaram para trás sem uso, inutilize-os.
Por que a SEFAZ acusa duplicidade
O motivo de a SEFAZ olhar para número e série, e não só para a chave, está no MOC: a SEFAZ autorizadora mantém o controle da numeração das NF-e autorizadas para evitar duplicidade de autorização para a mesma Chave Natural — modelo, UF, CNPJ ou CPF do emitente, série e número. A chave de acesso carrega mais informação do que isso, então duas chaves diferentes podem apontar para a mesma Chave Natural.
A chave de acesso tem 44 dígitos: código da UF, ano e mês de emissão (AAMM), CNPJ/CPF do emitente, modelo, série, número, forma de emissão (tpEmis), código numérico (cNF) e dígito verificador. Mudar o mês de emissão, a forma de emissão ou o código numérico gera outra chave para o mesmo número — e é exatamente essa diferença que a 539 aponta.
O código numérico merece atenção: o MOC pede que ele seja uma sequência totalmente aleatória, porque é a única parte da chave que não pode ser deduzida por terceiros. Um sistema que sorteia um cNF novo a cada tentativa produz uma chave diferente toda vez que reenvia a mesma nota — e, se a primeira tentativa já tinha sido autorizada, a segunda volta com 539.
Cenários comuns e a rejeição 204
Bases de conhecimento de emissores descrevem os cenários típicos: instabilidade na comunicação durante a emissão normal, em que a SEFAZ autoriza a nota mas o retorno não chega e o sistema reenvia em contingência com outro tpEmis; reenvio da mesma NF-e com outro cNF antes da resposta da primeira; e reaproveitamento de número e série já usados, por exemplo após restaurar um backup antigo, trocar de sistema ou emitir em mais de uma máquina sem numeração centralizada.
A mesma tabela do Anexo I traz a regra vizinha, 204 – Duplicidade de NF-e, para a NF-e já cadastrada e não cancelada nem denegada. A 539 é o caso específico em que a chave difere. Para a NFC-e (modelo 65), a busca pela nota já cadastrada também considera o tipo de emissão. Um número que já foi enviado à SEFAZ não volta a ficar disponível; o caminho é seguir para o próximo e inutilizar a faixa que ficou sem uso pelo serviço de inutilização de numeração.
Como conferir pela API
Na API do stackin, o histórico de envios de cada nota (GET /api/v1/invoices/{invoice_id}/submissions) mostra o código de status, a mensagem da própria SEFAZ e a requisição e a resposta como trafegaram — então a chave da 539 está ali. A consulta por chave de acesso (GET /api/v1/invoices/{access_key}) localiza o documento, o cabeçalho Idempotency-Key na emissão devolve a primeira resposta em vez de emitir um segundo documento quando a mesma requisição é repetida, e POST /api/v1/invoices/invalidations informa à SEFAZ uma faixa de numeração nunca usada.