NF-e rejection 204: duplicate NF-e, what it means and how to fix it

NF-e rejection 204 carries the official text Rejeição: Duplicidade de NF-e [nRec:999999999999999] ("Duplicate NF-e"). According to Annex I of the Taxpayer Guidance Manual (MOC), it is returned when the SEFAZ already has an NF-e registered with the same model, state (UF), issuer CNPJ or CPF, series and number, and that invoice is neither cancelled nor denied. In other words: that number has already been used by an invoice that is still valid.

The fix starts by consulting the access key before any resend. If the invoice shows as authorized, it is the tax document for the transaction: the way forward is to retrieve the authorized XML and print the DANFE from it, not to issue another one. The SEFAZ-PE procedures guide describes exactly this for rejection 204: check the invoice status at the SEFAZ and, if needed, download the XML through the full consultation on the National NF-e Portal, using the company's digital certificate.

Why rejection 204 happens

The rule exists because of the natural key. MOC 7.0 defines the unique identification of an NF-e for tax purposes as the set of UF, issuer CNPJ or CPF, series, number, model and authorization environment, and states that the authorization system rejects new requests when it finds a duplicate of that key. Changing other data on the invoice does not help: if model, UF, issuer, series and number match an authorized invoice, the SEFAZ refuses it.

The most common case is a resend. SEFAZ-PE sums it up: the taxpayer transmitted the invoice, it was authorized with the same access key, and they are trying to transmit it again. The document Consumo Indevido do Ambiente de Autorização (improper use of the authorization environment), published on the NF-e Portal, reports the two typical origins: companies without effective control over numbering, which send new invoices with a number already authorized, and applications that, through a programming error, loop resending the same batch and always get the duplicate-invoice error.

That is why 204 tends to show up after a communication failure: the invoice was authorized, but the response never reached the issuing system, which tries again. The same document says that if the batch receipt number is lost, the company must consult the access key of each NF-e in the batch individually and decide, from the result, whether the invoice was authorized or not. Consulting the current status of an NF-e in the SEFAZ database is a synchronous service that takes the access key.

Annex I details and neighbouring rejections

Annex I adds two useful notes. In the asynchronous response, the SEFAZ may return the batch receipt number (nRec) along with the message. And, at the state's discretion, when the DigestValue of the submitted invoice equals that of the already authorized NF-e, the SEFAZ may return the authorization protocol itself instead of just rejecting.

Do not confuse 204 with two neighbouring rejections from the same rule. 539 (Duplicidade de NF-e com diferença na Chave de Acesso, duplicate with a different access key) appears when the invoice is already registered with the same number but a different access key, for example a different numeric code. 218 (NF-e já está cancelada na base de dados da SEFAZ, already cancelled) appears when the invoice with that number has already been cancelled.

How to avoid rejection 204

To avoid hitting 204 again, the NF-e Portal recommends that the application control numbering, so it never generates an NF-e with a number already used; the access keys that make up each batch; whether the batch has already been sent to the authorization environment; and the handling of transmission errors and response timeouts. If the sale really needs a new invoice, it gets a new number; if the authorized invoice should not exist, the way out is cancellation, not a second issuance.

In stackin, consulting by access key is the GET /api/v1/invoices/{access_key} route, and each invoice's submission history (/api/v1/invoices/{invoice_id}/submissions) shows the code and message the SEFAZ returned on every attempt. Issuance accepts the Idempotency-Key header: repeating the request with the same key and the same body replays the first response instead of issuing a second document, which covers exactly the resend after a timeout.