NF-e rejection 539: what it means and how to fix it

NF-e rejection 539 reads, in the official layout, "Rejeição: Duplicidade de NF-e com diferença na Chave de Acesso" (duplicate NF-e with a difference in the access key), followed by a key in brackets (chNFe). According to Annex I of the Taxpayer Guidance Manual (MOC), it means SEFAZ already has an NF-e registered with the same model, state, issuer CNPJ/CPF, series and number — but the access key you sent differs from the registered one, either in the numeric code or in other positions of the key.

To fix it, first find out what is registered under that number. Compare the key in the message with the one you sent and check its status at SEFAZ: if the registered NF-e is the same sale sent again, it already exists and issuing another would duplicate the transaction. If the number belongs to a different invoice, issue with a number not yet used in the series and, if numbers were left behind unused, invalidate them.

Why the SEFAZ flags a duplicate

Why SEFAZ looks at number and series rather than just the key is explained in the MOC: the authorizing SEFAZ keeps control of the numbering of authorized NF-e to prevent duplicate authorization for the same Natural Key — model, state, issuer CNPJ or CPF, series and number. The access key carries more information than that, so two different keys can point to the same Natural Key.

The access key has 44 digits: state code, year and month of issue (AAMM), issuer CNPJ/CPF, model, series, number, issue type (tpEmis), numeric code (cNF) and check digit. Changing the month of issue, the issue type or the numeric code produces a different key for the same number — and that difference is exactly what 539 points at.

The numeric code deserves attention: the MOC asks for it to be a fully random sequence, because it is the only part of the key a third party cannot deduce. A system that draws a new cNF on every attempt produces a different key each time it resends the same invoice — and if the first attempt had already been authorized, the second one comes back with 539.

Common scenarios and rejection 204

Issuer knowledge bases describe the typical scenarios: unstable communication during normal issuance, where SEFAZ authorizes the invoice but the response never arrives and the system resends in contingency with another tpEmis; resending the same NF-e with another cNF before the first one is answered; and reusing a number and series already used, for instance after restoring an old backup, switching systems or issuing from more than one machine without centralized numbering.

The same Annex I table has the neighbouring rule, 204 – Duplicidade de NF-e, for an NF-e already registered and neither cancelled nor denied. 539 is the specific case where the key differs. For NFC-e (model 65), the lookup of the already-registered invoice also considers the issue type. A number already sent to SEFAZ does not become available again; the way forward is to move on to the next one and invalidate the unused range through the numbering invalidation service.

How to check through the API

In the stackin API, each invoice's submission history (GET /api/v1/invoices/{invoice_id}/submissions) shows the status code, SEFAZ's own message and the request and response exactly as they went over the wire — so the key from the 539 is right there. Consulting by access key (GET /api/v1/invoices/{access_key}) finds the document, the Idempotency-Key header on issuance replays the first response instead of issuing a second document when the same request is repeated, and POST /api/v1/invoices/invalidations reports a never-used numbering range to SEFAZ.