CNPJ Alfanumérico em 2026 (IN RFB 2.229 e NT 2025.001): Como Validar, Calcular o DV em TypeScript e Emitir NF-e/NFS-e

Na semana passada, revisando o parser de documentos fiscais e a extração de atributos ICP-Brasil de certificados digitais A1 na engine da Notaas, fizemos uma auditoria completa para a entrega da nossa release v0.56.78. O objetivo era garantir compatibilidade total de ponta a ponta com a mudança mais silenciosa — e potencialmente mais destrutiva — da história recente da engenharia de software no Brasil: o CNPJ Alfanumérico, instituído pela Instrução Normativa RFB nº 2.229/2024 com entrada em produção programada para julho de 2026.

Por décadas, todo programador brasileiro aprendeu uma verdade que parecia imutável: um CNPJ é uma sequência de 14 dígitos numéricos. Essa premissa está espalhada em milhões de linhas de código em produção hoje: em expressões regulares de limpeza como .replace(/\D/g, ''), em máscaras de input no React, em colunas BIGINT ou NUMERIC(14) no banco de dados e no algoritmo clássico de Módulo 11 que faz parseInt(char, 10) caractere por caractere.

Com mais de 60 milhões de estabelecimentos registrados e a expansão acelerada de novas inscrições — impulsionada inclusive pela Reforma Tributária (IBS e CBS) —, a faixa numérica de 8 dígitos da raiz do CNPJ começou a caminhar para a exaustão. Para evitar aumentar o tamanho do documento para 15 ou 16 posições (o que quebraria todos os layouts fixos de arquivos bancários CNAB, SPED e schemas XML da SEFAZ), a Receita Federal e o SERPRO mantiveram as 14 posições, mas passaram a permitir letras maiúsculas de A a Z nas 12 primeiras posições.

Se o seu SaaS, ERP ou e-commerce emite NF-e Modelo 55, NFC-e Modelo 65 ou NFS-e Nacional e municipal, este artigo é o seu guia de trincheira para entender exatamente o que muda nos schemas XSD (NT 2025.001 e NT-009), onde o seu código atual vai falhar e como implementar o novo cálculo de Dígito Verificador pela tabela ASCII em TypeScript.

A Anatomia Técnica do CNPJ Alfanumérico (IN RFB nº 2.229/2024)

A primeira regra fundamental da IN RFB nº 2.229/2024 é a retrocompatibilidade total: todos os CNPJs numéricos atuais continuam existindo e permanecem válidos para sempre. Os novos CNPJs alfanuméricos serão atribuídos apenas às novas inscrições de empresas e filiais abertas a partir de julho de 2026.

O formato continua com exatos 14 caracteres (ou 18 caracteres quando formatado na máscara SS.SSS.SSS/SSSS-NN), dividido em três blocos:

  12 . ABC . 345 / 01DE - 35
 |_____________|   |__|   |_|
    Raiz (8)     Ordem(4) DV(2)
   [A-Z0-9]{8}  [A-Z0-9]{4} [0-9]{2}

1. Raiz (8 primeiras posições — [A-Z0-9]{8}): Identifica a empresa base. Pode conter números de 0 a 9 e letras maiúsculas.
2. Ordem do Estabelecimento / Filial (4 posições seguintes — [A-Z0-9]{4}): Identifica se é matriz (0001) ou filial. Com a mudança, uma empresa com milhares de filiais ou novas inscrições poderá ter ordens alfanuméricas como 000A ou 01DE.
3. Dígito Verificador — DV (2 últimas posições — [0-9]{2}): Continua sendo estritamente numérico. Jamais existirá letra nas duas últimas posições do CNPJ.

O detalhe das letras proibidas (I, O, U, Q e F)

Quem leu apenas resumos superficiais da norma costuma validar apenas [A-Z0-9], mas a especificação técnica da Receita Federal e do SERPRO traz uma restrição importante para geração de novos códigos: as letras I, O, U, Q e F foram excluídas da geração de novos CNPJs pela RFB.

O motivo é engenharia humana e prevenção de erros de leitura óptica (OCR) em DANFEs impressos:

• As letras I e O confundem-se facilmente com os números 1 e 0 em fontes monoespaçadas.
• As letras U e Q geram ambiguidade visual com V e 0/O em impressoras térmicas de baixa resolução.
• A letra F foi reservada pelo fisco para evitar conflitos semânticos internos de controle.

Na hora de validar um CNPJ na entrada da sua API, você pode aceitar o regex geral /^[A-Z0-9]{12}[0-9]{2}$/ (conforme definido no tipo TCnpj da Nota Técnica 2025.001 da SEFAZ) ou aplicar a restrição estrita /^[A-HJ-NP-RT-Z0-9]{12}[0-9]{2}$/ sem as letras excluídas.

Os 3 Bugs Silenciosos que Vão Derrubar ERPs Legados em Julho de 2026

Durante nossos testes de carga e auditoria de integrações de clientes que gerenciam múltiplos CNPJs em uma única API fiscal, mapeamos três armadilhas clássicas que existem em quase todo software brasileiro escrito nos últimos 15 anos.

1. A armadilha mortal do .replace(/\D/g, '')

Em 99% dos projetos JavaScript, TypeScript, Python, PHP e C#, a função de "limpar máscara de CPF/CNPJ" antes de salvar no banco ou enviar para o gateway de pagamento é escrita assim:

// ❌ CÓDIGO LEGADO QUE VAI QUEBRAR EM JULHO DE 2026:
const cleanCnpj = rawInput.replace(/\D/g, '');

Veja o que acontece quando um cliente recém-aberto em julho de 2026 digita o CNPJ 12.ABC.345/01DE-35 nesse código: o atalho \D (tudo que não for dígito numérico de 0 a 9) arranca silenciosamente as letras A, B, C, D e E. A string resultante vira "123450135" (9 dígitos). Seu sistema vai achar que o usuário digitou um CPF incompleto ou um CNPJ truncado, impedindo o cadastro e travando a venda.

A sanitização correta para remover apenas pontuação de máscara (., /, - e espaços) e normalizar para caixa alta deve ser:

// ✅ SANITIZAÇÃO CORRETA PARA CNPJ ALFANUMÉRICO:
export function sanitizeTaxId(rawInput: string): string {
  return rawInput.toUpperCase().replace(/[^A-Z0-9]/g, '');
}

2. Colunas BIGINT / INT8 e remoção de zeros à esquerda

Ainda é surpreendentemente comum encontrar bancos PostgreSQL, MySQL ou SQL Server onde o arquiteto original definiu a coluna cnpj como BIGINT ou NUMERIC(14,0) para "economizar alguns bytes de índice". Além de exigir LPAD constante para recuperar zeros à esquerda, uma coluna numérica vai lançar erro fatal de banco (invalid input syntax for type bigint: "12ABC34501DE35") na primeira tentativa de INSERT. Toda coluna de documento fiscal deve ser VARCHAR(14) ou CHAR(14).

3. O Cálculo da Chave de Acesso de 44 Posições (NF-e/NFC-e) e 50 Posições (NFS-e Nacional)

Esse é o ponto que mais pega desenvolvedores de emissores próprios de surpresa. O CNPJ do emitente faz parte da Chave de Acesso tanto nos documentos estaduais (posições 7 a 20 da chave de 44 caracteres da NF-e, NFC-e, CT-e e MDF-e) quanto na NFS-e Nacional (no Id da DPS de 45 caracteres e na chave chNFSe de 50 caracteres).

Com a Nota TécnicaConjunta 2025.001 (para NF-e/NFC-e/CT-e/MDF-e) e a Nota Técnica SEFIN/ADN NT-009 (para a NFS-e Nacional), a Chave de Acesso deixa de ser puramente numérica e passa a ser uma chave de acesso alfanumérica sempre que o emitente possuir um CNPJ alfanumérico! E o último caractere da chave (o Dígito Verificador da Chave de Acesso na posição 44) também passa a ser calculado convertendo cada caractere pela tabela ASCII (charCodeAt(0) - 48).

Como Funciona a Matemática do Novo Módulo 11 (Tabela ASCII - 48)

A decisão de engenharia do SERPRO e do ENCAT para atualizar o algoritmo de Módulo 11 foi bastante elegante porque preserva 100% do resultado matemático para todos os CNPJs numéricos atuais.

Em vez de converter o caractere usando parseInt(char, 10), a regra oficial determina:

Para cada um dos 12 primeiros caracteres (e para o 13º no cálculo do segundo dígito), o valor numérico atribuído ao caractere é o seu código decimal na tabela ASCII subtraído de 48 (ASCII - 48).

Veja por que isso preserva a compatibilidade com os números atuais:

• Na tabela ASCII, o caractere '0' tem código decimal 48. Logo: 48 - 48 = 0.
• O caractere '9' tem código decimal 57. Logo: 57 - 48 = 9.
• Para todos os dígitos de '0' a '9', charCodeAt(0) - 48 produz exatamente o mesmo número inteiro de antes!
• Já para as letras maiúsculas, 'A' tem código decimal 65 na tabela ASCII. Logo: 65 - 48 = 17.
• 'B' é 66 - 48 = 18, 'C' é 67 - 48 = 19, e assim sucessivamente até 'Z', que tem código 90 (90 - 48 = 42).

Após converter cada caractere pelo seu valor ASCII - 48, os pesos multiplicadores do Módulo 11 continuam exatamente os mesmos de sempre (de 2 a 9, aplicados da direita para a esquerda):

• Para o 1º Dígito Verificador (posição 13): multiplicam-se as 12 primeiras posições pelos pesos [5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2].
• Para o 2º Dígito Verificador (posição 14): multiplicam-se as 13 primeiras posições pelos pesos [6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2].
• Calcula-se o resto da divisão da somatória por 11 (soma % 11). Se o resto for 0 ou 1, o dígito verificador é 0; caso contrário, é 11 - resto.

Implementação Completa em TypeScript: Validador de CNPJ Alfanumérico e Chave de Acesso

Abaixo está a implementação limpa, sem dependências externas e pronta para produção que utilizamos como base em nossos validadores TypeScript. Você pode copiar este módulo diretamente para o seu projeto Next.js, Node.js ou Bun:

/**
 * Validador e Calculador de CNPJ Alfanumérico (IN RFB nº 2.229/2024)
 * e Chave de Acesso de 44 posições (NT 2025.001)
 */

const WEIGHTS_DV1 = [5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2] as const;
const WEIGHTS_DV2 = [6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2] as const;

// Regex compatível com TCnpj da NT 2025.001 (12 alfanuméricos + 2 dígitos numéricos)
const ALPHANUMERIC_CNPJ_REGEX = /^[A-Z0-9]{12}[0-9]{2}$/;

// Regex opcional estrito bloqueando as letras I, O, U, Q e F conforme regra de geração da RFB
const STRICT_RFB_CNPJ_REGEX = /^[A-HJ-NP-RT-Z0-9]{12}[0-9]{2}$/;

/**
 * Remove pontuação de máscara mantendo apenas letras maiúsculas e números
 */
export function cleanAlphanumericCnpj(input: string): string {
  return input.trim().toUpperCase().replace(/[^A-Z0-9]/g, '');
}

/**
 * Converte um caractere [0-9A-Z] para seu valor no cálculo Módulo 11 (ASCII - 48)
 */
function charToAsciiValue(char: string): number {
  return char.charCodeAt(0) - 48;
}

/**
 * Calcula um dígito verificador Módulo 11 usando valores ASCII - 48
 */
function calculateMod11Digit(base: string, weights: readonly number[]): number {
  let sum = 0;
  for (let i = 0; i < weights.length; i++) {
    sum += charToAsciiValue(base[i]) * weights[i];
  }
  const remainder = sum % 11;
  return remainder < 2 ? 0 : 11 - remainder;
}

/**
 * Calcula os 2 dígitos verificadores (numéricos) a partir das 12 posições base do CNPJ
 */
export function calculateCnpjCheckDigits(base12: string): string {
  const cleaned = cleanAlphanumericCnpj(base12);
  if (!/^[A-Z0-9]{12}$/.test(cleaned)) {
    throw new Error('A base do CNPJ deve conter exatamente 12 caracteres alfanuméricos [A-Z0-9].');
  }

  const dv1 = calculateMod11Digit(cleaned, WEIGHTS_DV1);
  const dv2 = calculateMod11Digit(`${cleaned}${dv1}`, WEIGHTS_DV2);

  return `${dv1}${dv2}`;
}

/**
 * Valida se um CNPJ (numérico tradicional ou alfanumérico 2026) é válido
 */
export function isValidCnpj(
  rawCnpj: string,
  options: { enforceForbiddenLetters?: boolean } = {}
): boolean {
  const cnpj = cleanAlphanumericCnpj(rawCnpj);

  const pattern = options.enforceForbiddenLetters
    ? STRICT_RFB_CNPJ_REGEX
    : ALPHANUMERIC_CNPJ_REGEX;

  if (!pattern.test(cnpj)) {
    return false;
  }

  // Rejeita sequências repetidas óbvias como "00000000000000" ou "AAAAAAAAAAAA00"
  if (/^([A-Z0-9])\1{11}[0-9]{2}$/.test(cnpj)) {
    return false;
  }

  const base12 = cnpj.slice(0, 12);
  const informedDv = cnpj.slice(12, 14);
  const expectedDv = calculateCnpjCheckDigits(base12);

  return informedDv === expectedDv;
}

/**
 * Calcula o Dígito Verificador (44ª posição) da Chave de Acesso de NF-e/NFC-e/CT-e/MDF-e
 * conforme Nota Técnica 2025.001 (suporta CNPJ alfanumérico nas posições 7 a 20)
 */
export function calculateAccessKeyDv(key43: string): number {
  const cleaned = key43.trim().toUpperCase();
  if (!/^[0-9]{6}[A-Z0-9]{14}[0-9]{23}$/.test(cleaned)) {
    throw new Error('A base da Chave de Acesso deve ter 43 caracteres válidos.');
  }

  let weight = 2;
  let sum = 0;

  for (let i = cleaned.length - 1; i >= 0; i--) {
    sum += charToAsciiValue(cleaned[i]) * weight;
    weight = weight === 9 ? 2 : weight + 1;
  }

  const remainder = sum % 11;
  return remainder < 2 ? 0 : 11 - remainder;
}

Se você testar calculateCnpjCheckDigits("12ABC34501DE") no código acima, verá que ele retorna exatamente "35" — o caso de teste oficial publicado pela Receita Federal no manual de perguntas e respostas do CNPJ Alfanumérico (12.ABC.345/01DE-35).

Como a Notaas Resolve o CNPJ Alfanumérico Nativamente (Release v0.56.78)

Se você constrói seu produto seguindo práticas modernas de Vibe Coding com Cursor, Lovable, v0 e Next.js ou mantém um ERP de grande porte, a última coisa que você quer fazer é reescrever geradores de XML, parsers ASN.1 de certificados digitais e montadores de chave de acesso de 44 e 50 posições para cada prefeitura e SEFAZ estadual.

Na release v0.56.78 da plataforma Notaas (e no @notaas/mcp v0.2.1), nós atualizamos toda a cadeia de validação e transmissão para suportar CNPJs numéricos e alfanuméricos de forma transparente:

⚡ Fluxo Arquitetural: Processamento de CNPJ Alfanumérico na Engine Notaas (v0.56.78):

• 1. Entrada REST JSON ou MCP Tool: Os endpoints POST /api/v1/emitir, POST /api/v1/nfe/emitir, POST /api/v1/nfce/emitir e POST /api/v1/org/projects aceitam tanto CNPJs numéricos quanto alfanuméricos (com ou sem máscara) para emitente, tomador/destinatário, transportadora e intermediador.
• 2. Sanitização e Validação Módulo 11 ASCII: Nosso motor de entrada aplica sanitização alfanumérica ([^A-Z0-9]), verifica restrições da RFB e valida o DV via tabela ASCII (-48) antes de enfileirar o documento.
• 3. Parser ASN.1 de Certificado A1 ICP-Brasil (OID 2.16.76.1.3.3): Atualizamos o extrator criptográfico de certificados .pfx/.p12 para ler o atributo otherName (OID 2.16.76.1.3.3 — CNPJ do titular ICP-Brasil) como string alfanumérica PrintableString/UTF8String, garantindo o vínculo perfeito entre o certificado e o projeto.
• 4. Geração de Chaves TSIdDPS (45 pos), chNFSe (50 pos) e chNFe (44 pos): Os builders XML da Notaas montam as chaves de acesso com suporte nativo à NT 2025.001 e NT-009, incluindo renderização de QR Code e código de barras Code128C/Code128B nos PDFs locais do DANFE e DANFSe v2.0.

Veja como é simples cadastrar um novo cliente com CNPJ alfanumérico na nossa Org API (POST /api/v1/org/projects) ou emitir uma nota para um tomador com o novo formato:

{
  "ambiente": "homologacao",
  "referencia": "fatura_2026_07_9981",
  "tomador": {
    "cnpj": "12.ABC.345/01DE-35",
    "razaoSocial": "ACME AI INFRASTRUCTURE LTDA",
    "email": "fiscal@acme.ai",
    "endereco": {
      "logradouro": "Avenida Paulista",
      "numero": "1000",
      "bairro": "Bela Vista",
      "codigoMunicipio": "3550308",
      "uf": "SP",
      "cep": "01310100"
    }
  },
  "servico": {
    "codigo": "010701",
    "descricao": "Licenciamento de plataforma SaaS — Competência 07/2026",
    "valorServicos": 490.00
  }
}

Você envia o JSON limpo e a Notaas cuida de toda a negociação com a SEFAZ ou SNNFSE, devolvendo o XML assinado e o PDF pronto via Webhook.

Prepare sua Stack Hoje sem Custo Fixo

Julho de 2026 parece distante até o dia em que o primeiro cliente recém-constituído tentar assinar o seu SaaS e o formulário de checkout recusar o CNPJ dele. Audite hoje mesmo suas expressões regulares .replace(/\D/g, ''), migre colunas numéricas de documento para VARCHAR(14) e delegue a complexidade de schemas XSD da SEFAZ para uma infraestrutura que já nasceu pronta para a nova norma.

• Comece Grátis em Produção Real: A Notaas oferece 20 notas fiscais gratuitas por mês em produção (1 CNPJ) + até 5 projetos simultâneos grátis em homologação via Org API, sem necessidade de cartão de crédito. Crie sua conta em platform.notaas.com.br/sign-up.
• Documentação Técnica Completa: Confira os schemas de NF-e, NFC-e, NFS-e e Org API em docs.notaas.com.br.