Rejeição 204 NF-e: duplicidade de NF-e, o que é e como resolver

A rejeição 204 da NF-e tem o texto oficial Rejeição: Duplicidade de NF-e [nRec:999999999999999]. Pelo Anexo I do Manual de Orientação do Contribuinte, ela é devolvida quando a SEFAZ já tem cadastrada uma NF-e com o mesmo modelo, UF, CNPJ ou CPF do emitente, série e número, e essa nota não está cancelada nem denegada. Em outras palavras: aquela numeração já foi usada por uma nota que continua valendo.

A correção começa por consultar a chave de acesso antes de qualquer reenvio. Se a nota consta como autorizada, ela é o documento fiscal da operação: o caminho é recuperar o XML autorizado e imprimir o DANFE a partir dele, e não emitir outra. O guia de procedimentos da SEFAZ-PE descreve exatamente isso para a 204: consultar a situação da nota na SEFAZ e, se preciso, baixar o XML pela consulta completa do Portal Nacional da NF-e, com o certificado digital da empresa.

Por que a rejeição 204 acontece

A regra existe por causa da chave natural. O MOC 7.0 define que a identificação única de uma NF-e para efeitos tributários é o conjunto de UF, CNPJ ou CPF do emitente, série, número, modelo e ambiente de autorização, e que o sistema de autorização rejeita novos pedidos quando encontra duplicidade dessa chave. Mudar outros dados da nota não resolve: se modelo, UF, emitente, série e número forem os mesmos de uma nota autorizada, a SEFAZ recusa.

O caso mais comum é o reenvio. A SEFAZ-PE resume: o contribuinte transmitiu a nota, ela foi autorizada com a mesma chave de acesso, e ele está tentando transmitir de novo. O documento Consumo Indevido do Ambiente de Autorização, publicado no Portal da NF-e, relata as duas origens típicas: empresas sem controle efetivo da numeração, que enviam notas novas com um número já autorizado, e aplicações que, por erro de programação, ficam em loop reenviando o mesmo lote e recebem sempre o erro de nota duplicada.

Por isso a 204 costuma aparecer depois de uma falha de comunicação: a nota foi autorizada, mas a resposta não chegou ao sistema emissor, que tenta de novo. O mesmo documento orienta que, se o número do recibo do lote se perder, a empresa deve consultar individualmente a chave de acesso de cada NF-e do lote e decidir, pelo resultado da consulta, se a nota foi autorizada ou não. A consulta da situação atual da NF-e na base da SEFAZ é um serviço síncrono que recebe a chave de acesso.

Detalhes do Anexo I e rejeições vizinhas

O Anexo I traz ainda duas observações úteis. Na resposta assíncrona, a SEFAZ pode devolver o número do recibo do lote (nRec) junto da mensagem. E, a critério da UF, quando o DigestValue da nota enviada é igual ao da NF-e já autorizada, a SEFAZ pode retornar o próprio protocolo de autorização em vez de apenas rejeitar.

Vale não confundir a 204 com duas rejeições vizinhas da mesma regra. A 539 (Duplicidade de NF-e com diferença na Chave de Acesso) aparece quando a nota já está cadastrada com a mesma numeração, mas com outra chave de acesso, por exemplo com outro código numérico. A 218 (NF-e já está cancelada na base de dados da SEFAZ) aparece quando a nota com aquela numeração já foi cancelada.

Como evitar a rejeição 204

Para não voltar a cair na 204, o Portal da NF-e recomenda que a aplicação controle a numeração, para não gerar uma NF-e com número já usado; as chaves de acesso que compõem cada lote; se o lote já foi enviado ao ambiente de autorização; e o tratamento de erro de transmissão e de timeout na resposta. Se a venda realmente precisa de uma nota nova, ela usa um número novo; se a nota autorizada não deveria existir, o caminho é o cancelamento, não uma segunda emissão.

No stackin, a consulta pela chave de acesso é a rota GET /api/v1/invoices/{access_key}, e o histórico de envios de cada nota (/api/v1/invoices/{invoice_id}/submissions) mostra o código e a mensagem que a SEFAZ devolveu em cada tentativa. A emissão aceita o cabeçalho Idempotency-Key: repetir a requisição com a mesma chave e o mesmo corpo devolve a primeira resposta em vez de emitir um segundo documento, o que cobre justamente o reenvio após um timeout.