NFe Key Generator

How is the key generated?

Each part of the key follows the official layout. The cNF (random code) and DV fields are computed here. The result is structurally valid and passes checksum checks, yet it does not correspond to any real NFe authorized by SEFAZ.

For the check digit, modulo 11 is applied with cyclic weights from 2 to 9 over the first 43 digits.

Generation happens in your browser. Use it only in homologation and test environments.

The Brazilian NF-e access key explained

The chave de acesso ("access key") is a 44-digit numeric identifier that uniquely tags every electronic fiscal document issued in Brazil — most prominently the NF-e (Nota Fiscal Eletronica, model 55), the NFC-e (consumer-facing model 65), and related documents such as CT-e (transport, model 57) and MDF-e (manifesto, model 58). The key is generated by the issuer, embedded in the XML signed with an ICP-Brasil certificate, sent to the SEFAZ (state tax authority) for authorization, and printed as both numbers and a barcode (Code 128) in the DANFE — the printable representation of the electronic invoice.

The layout is defined by Ajuste SINIEF 07/2005 and its successors, published by CONFAZ (the Brazilian fiscal council). It is what enables the public verification portal at portalnfe.fazenda.gov.br to retrieve any invoice by key alone — a feature that has no direct equivalent in most other tax systems and makes Brazilian B2B reconciliation considerably stricter than, say, EU VAT invoicing.

Because the key is partly derived from the issuer's CNPJ, the SEFAZ environment, the invoice number and a check digit, simply having a syntactically valid key does not mean an invoice exists. Tax software always verifies authorization status by querying the SEFAZ web service before trusting an invoice. This generator is for development, testing and documentation purposes only.

Structure of the 44 digits

The key is read left-to-right, with no separators, in the following fields:

cUF  AAMM  CNPJ           mod  serie  nNF        tpEmis  cNF       cDV
 2    4    14              2    3      9          1       8         1   = 44

• cUF (2) — IBGE code of the state of the issuer. SP = 35, RJ = 33, MG = 31, RS = 43, etc.
• AAMM (4) — two digits of the year + two digits of the month of issuance (e.g. 2605 for May 2026).
• CNPJ (14) — CNPJ of the issuer, left-padded with zeros, no formatting.
• mod (2) — document model: 55 NF-e, 65 NFC-e, 57 CT-e, 58 MDF-e.
• serie (3) — fiscal series of the document, 0-999.
• nNF (9) — sequential invoice number assigned by the issuer within each series, 1-999.999.999.
• tpEmis (1) — emission type: 1 normal, 2 contingency in writing, 3 SCAN, 4 DPEC, 5 contingency FS-DA, 6 SVC-AN, 7 SVC-RS, 9 offline NFC-e.
• cNF (8) — numeric code, free random number chosen by the issuer (used to prevent enumeration attacks).
• cDV (1) — check digit, computed with the modulo-11 algorithm over the previous 43 digits.

Check digit (modulo 11)

The check digit (cDV) is computed by multiplying each of the 43 leftmost digits by a cyclical weight in the sequence 2, 3, 4, 5, 6, 7, 8, 9, 2, 3, ... (right to left), summing the products, taking the remainder modulo 11, and applying:

function chaveNfeDV(key43) {
  let sum = 0;
  let weight = 2;
  for (let i = 42; i >= 0; i--) {
    sum += parseInt(key43[i]) * weight;
    weight = weight === 9 ? 2 : weight + 1;
  }
  const mod = sum % 11;
  return (mod === 0 || mod === 1) ? 0 : (11 - mod);
}

NF-e (model 55) vs NFC-e (model 65)

NF-e model 55 is the general-purpose electronic invoice for B2B operations (industry to retailer, retailer to retailer) and substitutes the old paper Nota Fiscal Mod. 1/1A. It must be authorized before goods leave the issuer's premises. NF-e model 65 is the consumer-facing variant introduced by Ajuste SINIEF 19/2016: it replaces the paper Cupom Fiscal (formerly issued by ECF machines) and is used by retailers, restaurants and supermarkets to document sales to end consumers. Its DANFE is the small ticket printed by thermal printers, with a QR code that lets the consumer query the document on the state portal in seconds.

From the access-key standpoint, the difference between 55 and 65 is just the mod field. From the operational standpoint, however, the two regimes differ significantly: NFC-e supports offline emission (tpEmis = 9), has a separate contingency flow, and uses a per-state authorization environment.

Public consultation and verification

Anyone holding a valid access key can verify the document by visiting https://www.nfe.fazenda.gov.br/portal/consulta.aspx (NF-e) or the equivalent state portal for NFC-e. The portal returns the authorization protocol, the date of authorization, the cancellation status (if any) and a summary of the invoice. Automated systems consult the SEFAZ NfeConsultaProtocolo web service, which requires a digital certificate.

An invoice may be in one of several states: autorizada, cancelada (cancellation within the legal window, usually 24h for NF-e and 30 minutes for NFC-e), denegada (refused — e.g. issuer fiscally irregular), inutilizada (skipped number range), or rejeitada (validation failed). Only autorizada generates a tradeable document.

Common pitfalls

• Reusing a (cUF, CNPJ, mod, serie, nNF) tuple produces a duplicate-key rejection. The combination must be unique forever.
• Wrong cUF — using the destination state instead of the issuer's. The key always carries the issuer state.
• Missing zero padding on the CNPJ, series or invoice number — all fields are strict fixed-length numeric strings.
• Forgetting to compute cDV after editing any of the other 43 digits invalidates the entire key.
• Mixing test (homologacao) and production keys: homologation invoices typically use tpAmb = 2 and the recipient name "NF-E EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL", but the access-key layout is identical.

Frequently asked questions

Is a generated key valid for tax purposes? No. This tool produces a syntactically correct 44-digit string for testing and integration scenarios. A real, enforceable key only exists after SEFAZ authorizes the corresponding XML document.

Can two issuers ever produce the same key? Practically no — the key embeds the issuer CNPJ. The only collision risk would require both issuers to share CNPJ, model, series, number and emission month, which would already be a much larger fiscal problem.

What state codes does the cUF field use? The IBGE state codes: AC=12, AL=27, AM=13, AP=16, BA=29, CE=23, DF=53, ES=32, GO=52, MA=21, MG=31, MS=50, MT=51, PA=15, PB=25, PE=26, PI=22, PR=41, RJ=33, RN=24, RO=11, RR=14, RS=43, SC=42, SE=28, SP=35, TO=17.

Why does the key include a random cNF field? It prevents guessing-based enumeration attacks against the public consultation portal and gives extra entropy when invoices are issued in bursts.

How is the QR-code on a NFC-e DANFE related to the key? The QR encodes a URL that contains the access key and a hash signed with the CSC (Codigo de Seguranca do Contribuinte). Scanning it takes the consumer to the state's public portal and immediately validates the receipt.