NFe Key Validator

How does the access key work?

An NF-e key holds 44 digits, laid out in a fixed structure: UF (2) + YYMM (4) + issuer CNPJ (14) + model (2) + series (3) + number (9) + emission type (1) + cNF (8) + check digit (1).

The check digit comes out of the modulo 11 algorithm, with cyclic weights 2-9 applied over the first 43 digits. Beyond the DV, we verify the UF code (against the IBGE list) and the model (55, 65, 57, 58, 67).

100% local validation; no key is transmitted.

NF-e access key: the 44-digit fiscal identifier of Brazilian electronic invoices

The chave de acesso (access key) is the 44-digit numeric string that uniquely identifies any document under the Brazilian electronic fiscal documents umbrella: NF-e (model 55), NFC-e (model 65), CT-e (model 57) and MDF-e (model 58). It is generated by the issuer ERP at the moment of emission, transmitted to SEFAZ for authorization, printed as a Code 128 barcode on the DANFE and embedded in the XML signed with ICP-Brasil certificate.

Validating an access key is the first sanity check before consuming any NF-e XML: a corrupted key implies a corrupted document. The key carries the issuer CNPJ, the issuance month, the document number, the series and the SEFAZ state of origin — meaning that most of the document metadata can be decoded offline, without any HTTP request.

Decomposed layout of the 44 digits

The official layout published by ENCAT and consolidated in the SEFAZ Manual de Orientação do Contribuinte splits the key as:

cUF (2) + AAMM (4) + CNPJ (14) + mod (2) + serie (3) + nNF (9) + tpEmis (1) + cNF (8) + cDV (1)

• cUF: IBGE code of the issuing state — 35 SP, 33 RJ, 31 MG, 43 RS, 41 PR, 29 BA, 52 GO.
• AAMM: year and month of issuance (e.g. 2605 = May 2026).
• CNPJ: 14-digit CNPJ of the issuer (the emitter, never the recipient).
• mod: document model — 55 NF-e, 65 NFC-e, 57 CT-e, 58 MDF-e.
• serie: 3 digits, series of the invoice (range 0 to 999).
• nNF: 9 digits, sequential invoice number per series.
• tpEmis: emission type — 1 normal, 2 contingência FS, 4 EPEC, 9 offline NFC-e.
• cNF: 8 random digits, anti-collision component.
• cDV: 1-digit check digit, modulo 11.

The check digit algorithm step by step

The 44th digit is computed from the first 43 digits using a modulo 11 with cyclic weights. Pseudo-code:

weights = [2,3,4,5,6,7,8,9]
sum = 0
for i, digit in enumerate(reversed(first43)):
    sum += int(digit) * weights[i % 8]
rest = sum % 11
dv = 0 if rest in (0, 1) else 11 - rest

The weights cycle as 2,3,4,5,6,7,8,9,2,3,4,... applied to the 43 digits in reverse order. If the result of 11 - rest is 10 or 11, the DV is forced to 0. A mismatch between the computed DV and the 44th digit is enough to reject the key as malformed.

Offline validation versus SEFAZ consultation

Offline validation answers two questions: (i) is the key syntactically valid (length, digits, layout) and (ii) is the cDV consistent. It does not answer whether the document was authorized, whether it was cancelled, whether a Carta de Correção (CCe) was registered or whether the recipient acknowledged it (manifesto do destinatário). For that, your system must call the SEFAZ web service NfeConsultaProtocolo via SOAP, sending an envSinc envelope signed with the corporate ICP-Brasil certificate.

For read-only consultations there is a free public proxy: BrasilAPI exposes GET /api/nfe/v1/{chave} that returns the protocol status without requiring a certificate. Sefaz also publishes a status dashboard at nfe.fazenda.gov.br — a key validated locally may still fail to be queried if the SEFAZ environment is offline, which happens regularly during deploys at midnight.

Validation pipeline for ERP integrations

A robust validation pipeline runs four sequential checks:

• Length and charset: exactly 44 numeric digits, no letters, no spaces. Reject masks like 3526.0123.4567... at the parser level.
• Decompose components: extract cUF, AAMM, CNPJ, mod, série, nNF, tpEmis, cNF, cDV. Reject if cUF is not in the IBGE table or if mod is not 55, 65, 57 or 58.
• Recalculate the DV: apply the modulo 11 algorithm and compare.
• Optional SEFAZ consult: query NfeConsultaProtocolo or BrasilAPI to confirm authorization status (cStat=100 = autorizada, 101 = cancelada, 110 = uso denegado).

Sandbox versus production, CCe and cancellation

Every SEFAZ web service exposes two environments controlled by tpAmb: 1 = produção and 2 = homologação (sandbox). Keys generated in sandbox have cNF values fixed by Sefaz and should never be processed by accounting software. The Carta de Correção Eletrônica (CCe), regulated by Ajuste SINIEF 7/2005, lets the issuer correct minor errors within 720 hours of issuance; it does not change the access key. Cancellation requires an event call to RecepcaoEvento within 24 h for NF-e (some states extend the window), and only succeeds before the document circulates physically.

Use cases and ecosystem

Offline validation is the foundation of every Brazilian ERP integration. Major systems that rely on access-key validation include TOTVS Protheus, SAP Business One, Bling, Conta Azul, Omie, eGestor and Sankhya. On the developer side, libraries such as node-nfe, nfephp-org and brazilian-utils ship key validators ready to plug. Fiscal monitoring tools (Receita, SPED, Sintegra) also rely on the key as the primary join across the XML, the DANFE, the contábil ledger and the bank statement.

Common pitfalls and antipatterns

A surprising number of bugs in fiscal integrations boil down to parsing the SEFAZ SOAP response carelessly. The web service returns an XML envelope with retConsSitNFe; nested attributes can be empty or absent depending on the document state — never assume a field exists. Other recurring traps:

• Trusting the key prefix to identify the document type — always check mod, not the URL it came from.
• Concatenating the key with hyphens or dots before validation; strip non-digits first.
• Validating the key but skipping the XML signature check — the digital signature is what binds the key to the document.
• Caching SEFAZ responses indefinitely; a NF-e can be cancelled days later, invalidating cached status.

FAQ

Can I validate an NF-e key fully offline?

Yes — syntax, layout and the modulo 11 check digit are pure arithmetic. Offline validation does not confirm SEFAZ authorization or cancellation status, but it is the mandatory first filter.

Is there a free way to check the SEFAZ status?

Yes. BrasilAPI proxies the NfeConsultaProtocolo endpoint with no authentication required, returning the protocol code (cStat) and the SEFAZ message. For high-volume scenarios, prefer a direct SOAP call signed with your own ICP-Brasil certificate.

Does an NFC-e key use the same format?

Yes. NFC-e is model 65 and uses exactly the same 44-digit layout and DV algorithm. Only the mod field changes; everything else is identical to NF-e.

What does a check digit failure mean in practice?

It means the key was tampered with, mis-typed or corrupted during transmission. Any document presenting a key whose DV does not match must be rejected at the gateway: SEFAZ itself will return cStat=236 (chave de acesso com dígito verificador inválido).

How do I find the issuer state from the key alone?

Look at the first 2 digits (cUF) and match them against the IBGE state codes. This tool decodes the cUF automatically into the corresponding state name.