CNPJ alfanumérico na NF-e: o que muda na chave de acesso, no dígito verificador e no seu código

Em 31 de julho de 2026, a Receita Federal emitiu o primeiro CNPJ alfanumérico do país: 00.000.000/E08G-12, uma filial do Banco do Brasil. Não foi um teste, não foi um piloto em ambiente de homologação. É um CNPJ real, válido, que pode aparecer como emitente ou destinatário em qualquer NF-e a partir de agora.

Se o seu sistema lê, grava, valida ou imprime nota fiscal eletrônica, essa mudança importa mais do que parece. E não é pelo motivo óbvio.

O motivo óbvio é que o CNPJ passou a ter letras. Isso todo mundo já leu. O motivo menos comentado, e bem mais perigoso, é que a chave de acesso da NF-e deixou de ser uma sequência de 44 números. Ela continua com 44 posições, mas agora pode conter letras no meio. Toda validação, máscara, coluna de banco e código de barras que assume "44 dígitos numéricos" está tecnicamente errado desde 1º de julho de 2026.

Este artigo cobre o que mudou, o algoritmo exato do dígito verificador (com código testado contra casos reais), e um checklist do que costuma quebrar. É um texto técnico, mas escrito para ser útil também para quem não programa.

O que é o CNPJ alfanumérico, em uma tela

O CNPJ alfanumérico foi criado pela Instrução Normativa RFB nº 2.229, de 15 de outubro de 2024, que alterou a IN RFB nº 2.119/2022. A motivação declarada pela Receita é simples e nada polêmica: a demanda por novos números de CNPJ vem crescendo e o espaço de combinações puramente numéricas tem limite. Adicionar letras multiplica as combinações possíveis e evita o esgotamento.

O formato continua com 14 posições e a mesma máscara visual de sempre:

AA.AAA.AAA/AAAA-DV

Onde:

• Posições 1 a 8 (raiz): podem ser números de 0 a 9 ou letras maiúsculas de A a Z
• Posições 9 a 12 (ordem do estabelecimento): também podem ser números ou letras
• Posições 13 e 14 (dígitos verificadores): continuam sempre numéricas

Quatro pontos que evitam a maior parte da confusão:

1. Nenhum CNPJ existente muda. Quem já tem inscrição continua com o mesmo número e o mesmo dígito verificador, sem precisar fazer absolutamente nada.
2. Os dois formatos coexistem, e ambos são plenamente válidos para todos os fins. Não existe data de corte em que o numérico deixa de valer.
3. As letras são aleatórias. Não codificam UF, natureza jurídica nem qualquer outro atributo. Não tente extrair significado delas.
4. Só letras maiúsculas A a Z. Não há acentuação, cedilha, minúscula ou caractere especial.

Um detalhe que passa batido e que já vi gerar discussão em equipe: a Receita afirma no material oficial de perguntas e respostas que o sufixo 0001, tradicionalmente associado à matriz, continua indicando a matriz no momento da geração, mas deixa de ser um identificador definitivo. Com o tempo, uma filial pode se tornar o estabelecimento principal mantendo um número de ordem diferente. Se o seu sistema decide "é matriz" olhando para 0001, essa regra já estava frágil e agora está oficialmente obsoleta.

A parte que quebra sistemas: a chave de acesso

Aqui está o ponto central deste artigo.

A chave de acesso da NF-e tem 44 posições, e as posições 7 a 20 são exatamente o CNPJ do emitente. Se o CNPJ pode ter letras, a chave também pode.

A composição campo a campo continua idêntica:

Como os dois últimos caracteres do CNPJ são sempre numéricos, o padrão da chave passou de [0-9]{44} para:

[0-9]{6}[A-Z0-9]{12}[0-9]{26}

Ou seja: 6 numéricos, 12 possivelmente alfanuméricos, 26 numéricos. Total de 44.

Um exemplo concreto, montado e validado para este artigo a partir do CNPJ de exemplo da própria Receita (12.ABC.345/01DE-35), nota modelo 55, série 001, número 1234, emitida em São Paulo em setembro de 2026:

35260912ABC34501DE35550010000012341123456788

Repare no que acontece se você jogar essa chave nas validações tradicionais:

const chave = "35260912ABC34501DE35550010000012341123456788";

console.log(/^[0-9]{44}$/.test(chave));                     // false, rejeita chave válida
console.log(/^[0-9]{6}[A-Z0-9]{12}[0-9]{26}$/.test(chave)); // true
console.log(chave.replace(/\D/g, "").length);               // 39, silenciosamente

A primeira linha é um problema visível: a nota é rejeitada e alguém abre chamado. A terceira linha é o problema de verdade. replace(/\D/g, "") é o idioma mais comum do mundo para "limpar" um documento antes de gravar, e com CNPJ alfanumérico ele não lança erro, não avisa nada: apenas apaga as letras e devolve uma string de 39 caracteres que o sistema vai gravar, comparar e provavelmente exibir como se fosse legítima. É corrupção silenciosa de dado fiscal, o pior tipo de bug para descobrir seis meses depois.

Vale dizer que encontrei exatamente esse padrão no código deste próprio projeto ao pesquisar para escrever o artigo. Não estou apontando dedo para ninguém: é um idioma tão automático que ninguém revisa.

O dígito verificador: um algoritmo só para os dois formatos

Essa é a melhor notícia técnica da mudança, e é a parte que mais vejo sendo explicada de forma desnecessariamente complicada.

A regra de conversão definida pela Receita é: cada caractere vale o seu código ASCII menos 48.

Isso significa que:

• '0' tem ASCII 48, então vale 48 - 48 = 0
• '9' tem ASCII 57, então vale 57 - 48 = 9
• 'A' tem ASCII 65, então vale 65 - 48 = 17
• 'Z' tem ASCII 90, então vale 90 - 48 = 42

Perceba a elegância: para os dígitos de 0 a 9, ASCII menos 48 devolve exatamente o próprio valor numérico. O algoritmo antigo é um caso particular do novo. Você não precisa de duas funções, nem de um if para detectar se o CNPJ tem letras. Precisa de uma função só, e ela valida corretamente tanto os CNPJs legados quanto os novos.

O resto do cálculo é o módulo 11 de sempre:

1. Converta cada caractere para seu valor (ASCII menos 48)
2. Aplique pesos de 2 a 9, da direita para a esquerda, voltando para 2 depois do 9
3. Some todos os produtos
4. Calcule o resto da divisão por 11
5. Se o resto for 0 ou 1, o dígito é 0. Caso contrário, o dígito é 11 - resto
6. Para o segundo dígito, repita tudo com o primeiro dígito já anexado ao final

Em JavaScript:

function digitosVerificadoresCnpj(base12) {
  const base = base12.toUpperCase()
  const valor = (c) => c.charCodeAt(0) - 48

  const calcular = (str) => {
    let soma = 0
    let peso = 2
    for (let i = str.length - 1; i >= 0; i--) {
      soma += valor(str[i]) * peso
      peso = peso === 9 ? 2 : peso + 1
    }
    const resto = soma % 11
    return resto < 2 ? 0 : 11 - resto
  }

  const dv1 = calcular(base)
  const dv2 = calcular(base + String(dv1))
  return `${dv1}${dv2}`
}

E para o dígito verificador da chave de acesso, que fica na posição 44, a lógica é a mesma sobre os 43 primeiros caracteres:

function dvChaveAcesso(chave43) {
  const s = chave43.toUpperCase()
  let soma = 0
  let peso = 2
  for (let i = s.length - 1; i >= 0; i--) {
    soma += (s.charCodeAt(i) - 48) * peso
    peso = peso === 9 ? 2 : peso + 1
  }
  const resto = soma % 11
  return resto < 2 ? 0 : 11 - resto
}

Antes de publicar, rodei essas funções contra casos reais para não propagar código errado pela internet. Os resultados:

Os dois últimos casos numéricos são o ponto importante: confirmam na prática que a mesma função atende o formato antigo, sem ramificação condicional. Se a sua implementação nova quebrar CNPJs legados, tem erro nela, não na especificação.

Um detalhe de implementação: normalize para maiúsculas antes de calcular. A especificação só prevê letras maiúsculas, mas dados chegam de formulário, planilha e integração de terceiro. Um 'a' tem ASCII 97, o que daria valor 49 e um dígito verificador silenciosamente errado.

Checklist do que costuma quebrar

Com base na especificação e no que já apareceu em código real, esta é a lista que uso para revisar um sistema:

Validação e formatação

• Expressões regulares com ^\d{14}$, ^[0-9]{14}$, ^\d{44}$ para CNPJ e chave
• Qualquer replace(/\D/g, "") ou replace(/[^0-9]/g, "") aplicado a CNPJ ou chave
• Máscaras de input que aceitam apenas teclas numéricas
• Funções de formatação que quebram a máscara usando grupos (\d{2})(\d{3}) e similares
• Normalização para maiúsculas na entrada

Banco de dados

• Colunas de CNPJ e chave declaradas como INTEGER, BIGINT, NUMERIC ou DECIMAL
• Índices, chaves estrangeiras e views que dependem desse tipo numérico
• Ordenação: comparação numérica vira comparação de string, e a ordem muda
• Arquivos de carga, ETL e integrações que fazem cast para número no meio do caminho

Documentos e impressão

• Código de barras do DANFE: o padrão CODE-128C aceita apenas caracteres numéricos. A orientação técnica é migrar para um modelo híbrido, alternando dinamicamente entre CODE-128C nos trechos numéricos e CODE-128A nos trechos com letras, usando o código de controle 100 para trocar de conjunto e manter a densidade do código. Vale conferir se a biblioteca que você usa já faz essa alternância sozinha
• Leitores de código de barras configurados para aceitar apenas numérico
• Layout impresso: a máscara ocupa o mesmo espaço, mas fontes de largura variável podem render diferente com letras

Regras de negócio

• Qualquer lógica que deduz "é matriz" a partir do sufixo 0001
• Deduplicação e comparação de CNPJ que hoje compara números
• Relatórios e filtros que ordenam ou agrupam por faixa de CNPJ

O cronograma, em datas

A NT Conjunta 2025.001 não vale só para a NF-e. Ela padroniza o CNPJ alfanumérico em praticamente todo o ecossistema de documentos fiscais eletrônicos: NF-e, NFC-e, CT-e, CT-e OS, GTV-e, MDF-e, BP-e, BP-e TM, NF3-e e NFCom, além dos novos documentos que a Reforma Tributária está criando. Se você integra com mais de um tipo de DF-e, a mudança é transversal.

A adoção, segundo a própria Receita, é progressiva e controlada: poucas empresas recebem CNPJ com letras no início. Na prática, isso significa que o seu sistema pode passar meses sem encontrar um único CNPJ alfanumérico e, quando encontrar, falhar em produção sem aviso. É o pior cenário possível para bugs desse tipo, porque a ausência de erro hoje não é evidência de que está funcionando.

Como isso conversa com a Reforma Tributária

São duas mudanças independentes que caíram quase juntas, e é comum ver as duas misturadas na mesma conversa. Vale separar:

• O CNPJ alfanumérico vem da Receita Federal, por Instrução Normativa, e muda a identificação das empresas
• A Reforma Tributária do Consumo vem da EC 132/2023 e da LC 214/2025, e muda a tributação, criando IBS, CBS e o Imposto Seletivo

Uma não depende da outra. Mas elas se encontram no mesmo lugar: o XML da sua nota fiscal. Se você vai mexer no parser mesmo assim, faz sentido tratar as duas frentes na mesma janela de trabalho.

Se a segunda frente ainda não está clara para você, temos material dedicado:

• IBS e CBS na NF-e: como ler os novos campos do XML, para entender os grupos que passaram a aparecer no XML
• Calendário da Reforma Tributária: o que muda em cada data, com a linha do tempo completa até 2033
• Split Payment para desenvolvedores, com o fluxo técnico e a API do governo
• Os novos documentos fiscais eletrônicos da Reforma Tributária, que também nascem já com suporte a CNPJ alfanumérico
• Simples Nacional e MEI na Reforma Tributária, se a sua empresa está nesse regime
• Reforma Tributária: o que é boato e o que é real, para filtrar o que circula em grupo de WhatsApp

Como testar hoje, sem esperar aparecer um CNPJ com letras

Três caminhos práticos, do mais simples ao mais completo:

1. Use o CNPJ de exemplo da Receita, 12.ABC.345/01DE-35, como dado de teste fixo na sua suíte. Ele tem dígito verificador oficialmente correto, então serve como caso de referência confiável.
2. Monte uma chave de acesso sintética com esse CNPJ, calcule o dígito da posição 44 com a função acima e passe essa chave por todo o seu fluxo: validação, gravação, consulta, geração de PDF e código de barras. Foi exatamente assim que produzi o exemplo deste artigo.
3. Rode o simulador de inscrição da Receita Federal, disponível na página oficial do CNPJ alfanumérico, para gerar mais casos válidos.

Se você quiser só conferir como uma DANFE se comporta com um XML real em mãos, dá para gerar o documento aqui mesmo, sem instalar nada: a DANFE Completa monta o PDF a partir do XML direto no navegador, e a página de consulta de NF-e pela chave de acesso ajuda a recuperar o XML quando você só tem a chave em mãos.

Opnião do autor:

Vou ser direto sobre o que acho dessa mudança, separando o que é técnico do que é opinião.

Tecnicamente, a especificação é boa. A escolha de ASCII menos 48 como regra de conversão é a decisão mais inteligente do desenho todo, e acho que ela não recebeu o crédito que merece. Ela faz o algoritmo novo conter o antigo como caso particular, o que significa que ninguém precisa manter dois validadores, nem escrever lógica condicional para detectar formato, nem migrar base histórica. Quem implementa direito escreve uma função e ela atende os dois mundos. Muita especificação pública brasileira não tem esse cuidado, e essa tem.

Na prática, minha preocupação é outra: o modo de falha. A adoção gradual significa que a maioria dos sistemas vai passar meses sem ver um CNPJ alfanumérico. Equipe nenhuma prioriza uma correção para um cenário que nunca aconteceu. Aí, num dia qualquer, chega a primeira nota de um fornecedor novo e o sistema quebra, ou pior, não quebra: apenas grava uma string truncada porque alguém escreveu replace(/\D/g, "") em 2019 e ninguém revisou desde então. Quando esse bug aparecer, ele vai aparecer em dado fiscal já gravado, não em tela de erro.

A parte que eu chamo de mal calibrada é a comunicação, não a norma. A maior parte do conteúdo que encontrei sobre o tema para em "o CNPJ vai ter letras" e no cronograma. Pouquíssimo material diz com todas as letras que a chave de acesso da NF-e deixou de ser numérica, que existe um problema específico de código de barras porque CODE-128C não aceita letra, ou que a regra do sufixo 0001 como identificador de matriz caiu. Esses três pontos estão nos documentos oficiais, mas exigem ler a nota técnica e o material de perguntas e respostas até o fim. Quem depende de resumo de portal vai descobrir em produção.

Minha recomendação concreta, na ordem em que eu faria: primeiro, adicione o CNPJ de exemplo da Receita como caso fixo na suíte de testes, porque isso transforma um risco invisível em um teste que passa ou falha. Segundo, faça um grep no projeto inteiro por \d{14}, \d{44} e replace(/\D/g e revise cada ocorrência relacionada a documento fiscal. Terceiro, confira o tipo das colunas de CNPJ e chave no banco, porque essa é a correção mais cara de fazer depois que tem volume gravado. As três primeiras coisas cabem numa tarde e cobrem a maior parte do risco real.

E uma observação honesta para fechar: ao pesquisar para escrever este artigo, encontrei esse mesmo padrão de código no projeto que mantenho. A formatação do CNPJ degrada de forma inofensiva, mostra o número sem máscara, mas o agrupamento visual da chave de acesso quebra de verdade com letras. Se aconteceu aqui, num projeto cujo assunto é literalmente documento fiscal eletrônico, provavelmente está acontecendo no seu também. Vale os quinze minutos de grep.

Perguntas frequentes

Meu CNPJ atual vai mudar? Não. CNPJs já emitidos permanecem exatamente os mesmos, com os mesmos dígitos verificadores, e continuam válidos indefinidamente. Não há nenhuma providência a tomar junto à Receita Federal.

O CNPJ alfanumérico tem quantos caracteres? Catorze, exatamente como o numérico, e com a mesma máscara AA.AAA.AAA/AAAA-DV. O que muda é que as 12 primeiras posições aceitam letras, enquanto as duas últimas seguem numéricas.

A chave de acesso da NF-e continua com 44 posições? Sim, o tamanho não mudou. O que mudou é que ela deixou de ser exclusivamente numérica: as posições 7 a 20 carregam o CNPJ do emitente e podem conter letras.

Preciso de dois algoritmos de validação, um para cada formato? Não. Com a regra de converter cada caractere para ASCII menos 48, o mesmo cálculo de módulo 11 atende os dois formatos. Validei isso contra CNPJs legados reais e contra o exemplo oficial da Receita.

O CNPJ alfanumérico pode ter letras minúsculas? Não. A especificação prevê apenas letras maiúsculas de A a Z. Normalize a entrada para maiúsculas antes de validar, porque o cálculo do dígito verificador dá resultado errado com minúsculas.

As letras do CNPJ significam alguma coisa? Não. A Receita Federal afirma que a atribuição é completamente aleatória e que não há relação com UF, natureza jurídica ou qualquer outro atributo da empresa.

Fontes

• Receita Federal: CNPJ Alfanumérico (página oficial do programa)
• Receita Federal: CNPJ Alfanumérico, Perguntas e Respostas (PDF oficial)
• Receita Federal: CNPJ terá letras e números a partir de julho de 2026
• Serpro: Cálculo dos dígitos verificadores de CNPJ alfanumérico (PDF)
• Portal da NF-e: Nota Técnica Conjunta 2025.001, CNPJ Alfanumérico
• CRC-MA: Primeiro CNPJ alfanumérico é emitido pela Receita Federal
• Tecnospeed: Layout CNPJ alfanumérico na NF-e, mudanças da NT 2026.004
• Tecnospeed: CNPJ Alfanumérico, tudo o que você precisa saber
• Dynamicca: CNPJ Alfanumérico em Documentos Fiscais Eletrônicos, NT 2025.001
• Conselho Federal de Contabilidade: CNPJ Alfanumérico será implementado em julho de 2026

Os exemplos de código e a chave de acesso usada neste artigo foram executados e conferidos contra o exemplo oficial da Receita Federal e do Serpro, contra o primeiro CNPJ alfanumérico realmente emitido e contra chaves de NF-e numéricas reais, antes da publicação.