CNPJ alfanumérico: o que muda e como adaptar validação, banco de dados e integrações

Desde 31 de julho de 2026, a Receita Federal gera CNPJs com letras. A mudança foi definida pela Instrução Normativa RFB nº 2.229/2024 e tem uma razão simples: o estoque de números de 8 dígitos para a raiz está acabando.

A boa notícia é que nenhum CNPJ existente muda. A má notícia é que todo sistema que assume "CNPJ = 14 dígitos numéricos" vai rejeitar, truncar ou corromper os novos números assim que eles chegarem. Este artigo mostra o que mudou, onde os sistemas costumam quebrar e como adaptar cada camada com segurança.

O que muda no formato

O CNPJ continua com 14 posições e a mesma estrutura de raiz, ordem e dígitos verificadores. A diferença está no alfabeto:

A máscara também se mantém: 12.ABC.345/01DE-35 é um CNPJ alfanumérico válido, usado como exemplo pela própria Receita na documentação oficial.

Os dois formatos vão conviver por muito tempo. A emissão é gradual, e novos registros ainda podem receber números puramente numéricos. Ou seja: o seu sistema precisa aceitar os dois, não trocar um pelo outro.

O novo cálculo do dígito verificador

O algoritmo continua sendo o módulo 11 com pesos de 2 a 9, aplicados da direita para a esquerda. O que muda é o valor de cada caractere: ele passa a ser o código ASCII menos 48.

• 0 a 9 continuam valendo 0 a 9 (o código ASCII de 0 é 48);
• A vale 17 (65 − 48), B vale 18, e assim por diante até Z, que vale 42.

Essa escolha é elegante: para CNPJs numéricos, o resultado é idêntico ao do algoritmo antigo. Uma única função atende os dois formatos.

Em TypeScript:

const CNPJ_RE = /^[A-Z0-9]{12}[0-9]{2}$/

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

/** Remove a máscara e normaliza para maiúsculas. */
export function limparCnpj(valor: string): string {
  return valor.replace(/[.\/\-\s]/g, '').toUpperCase()
}

export function cnpjValido(valor: string): boolean {
  const cnpj = limparCnpj(valor)
  if (!CNPJ_RE.test(cnpj) || /^(\d)\1{13}$/.test(cnpj)) return false
  const d1 = digito(cnpj.slice(0, 12))
  const d2 = digito(cnpj.slice(0, 12) + d1)
  return cnpj.endsWith(`${d1}${d2}`)
}

E o equivalente em Python:

import re

CNPJ_RE = re.compile(r"^[A-Z0-9]{12}[0-9]{2}$")

def _digito(base: str) -> int:
    soma, peso = 0, 2
    for ch in reversed(base):
        soma += (ord(ch) - 48) * peso
        peso = 2 if peso == 9 else peso + 1
    resto = soma % 11
    return 0 if resto < 2 else 11 - resto

def cnpj_valido(valor: str) -> bool:
    cnpj = re.sub(r"[.\-/\s]", "", valor).upper()
    if not CNPJ_RE.match(cnpj) or re.fullmatch(r"(\d)\1{13}", cnpj):
        return False
    d1 = _digito(cnpj[:12])
    d2 = _digito(cnpj[:12] + str(d1))
    return cnpj.endswith(f"{d1}{d2}")

Onde os sistemas quebram

Na prática, o problema raramente está no validador. Ele está nas premissas espalhadas pelo código e pelos dados.

1. Colunas numéricas no banco

Guardar CNPJ como BIGINT ou NUMERIC sempre foi um erro (o zero à esquerda some), mas funcionava. Agora não funciona mais. A coluna precisa ser texto de tamanho fixo. Um exemplo de migração no PostgreSQL:

-- 1) converte preservando os zeros à esquerda
ALTER TABLE clientes
  ALTER COLUMN cnpj TYPE char(14)
  USING lpad(cnpj::text, 14, '0');

-- 2) garante o formato canônico (sem máscara, maiúsculo)
ALTER TABLE clientes
  ADD CONSTRAINT clientes_cnpj_formato
  CHECK (cnpj ~ '^[A-Z0-9]{12}[0-9]{2}$');

Atenção às tabelas derivadas: chaves estrangeiras, índices, partições por faixa numérica de raiz e colunas de raiz (cnpj_basico) também precisam virar texto.

2. Formulários e máscaras de entrada

• Campos com inputmode="numeric" ou type="number" impedem o usuário de digitar letras no celular.
• Máscaras que só aceitam 9 (dígito) precisam aceitar letra nas 12 primeiras posições.
• Converta para maiúsculas antes de validar: o usuário vai digitar 12.abc.345/01de-35.

3. Regex e validações espalhadas

Procure no código por padrões como \d{14}, [0-9]{14}, isdigit(), Number(cnpj), parseInt(cnpj) e int(cnpj). Cada ocorrência é um ponto de falha. O mesmo vale para validações em gateways de pagamento, emissores de nota e ferramentas de no-code.

4. Planilhas e BI

O Excel converte sequências numéricas longas em notação científica e remove zeros. Com letras, a coluna vira texto em algumas linhas e número em outras, o que quebra procuras e junções. Importe a coluna explicitamente como texto e trate o CNPJ como identificador, nunca como número.

5. Integrações e contratos de API

Se a sua API documenta o CNPJ como integer ou valida com regex numérica, os parceiros vão receber erros. Atualize o contrato (OpenAPI, JSON Schema), avise quem consome e aceite os dois formatos na entrada, sempre normalizando para a forma canônica.

6. Ordenação e faixas

Rotinas que fazem "pegue os CNPJs entre X e Y" ou que ordenam numericamente vão se comportar de forma diferente com texto. Ordenação lexicográfica funciona para o formato canônico, mas qualquer lógica que dependa de aritmética sobre a raiz precisa ser revista.

Uma bateria de testes mínima

Inclua estes casos nos testes automatizados de qualquer componente que receba CNPJ:

Os mesmos casos servem para testar a API, o formulário e o importador de planilhas, ponta a ponta.

Um plano de adaptação em cinco passos

1. Inventário. Liste onde o CNPJ entra (formulários, importações, APIs), onde é guardado (tabelas, caches, data warehouse) e para onde sai (relatórios, integrações, notas).
2. Normalização única. Crie uma função de limpeza e validação compartilhada e substitua as regex locais por ela.
3. Esquema. Migre as colunas para texto de 14 posições, com restrição de formato. Faça isso antes de mexer nas telas.
4. Interfaces. Ajuste máscaras, teclado do celular e mensagens de erro ("use letras e números").
5. Contratos. Atualize a documentação da sua API, avise parceiros e monitore erros de validação nos logs nas primeiras semanas.

Perguntas frequentes

Preciso converter os CNPJs que já tenho? Não. Os CNPJs existentes continuam válidos e não ganham letras. O que muda é a capacidade do sistema de aceitar os novos números ao lado dos antigos.

Uma empresa antiga pode passar a ter CNPJ com letras? A empresa mantém a sua raiz. Mas, quando o espaço numérico de um campo se esgota, novos estabelecimentos podem receber identificadores alfanuméricos. Na prática, uma filial nova de uma empresa antiga pode chegar com letras na ordem, e o seu sistema precisa tratar a raiz e a ordem como texto.

Quanto tempo tenho para me adaptar? O formato já está valendo, e a emissão é gradual. Não há como prever quando um cliente, fornecedor ou parceiro com CNPJ alfanumérico vai aparecer na sua base. O risco de esperar é descobrir o problema por meio de um cadastro recusado ou de uma integração quebrada em produção.

Posso continuar guardando só a raiz como número para fazer junções? Não. A raiz também passa a aceitar letras. Toda chave derivada do CNPJ, inclusive a raiz de 8 posições usada para ligar estabelecimentos, sócios e empresas, precisa ser texto.

E os documentos fiscais e as integrações com órgãos públicos? Cada sistema público publica as próprias especificações técnicas. Acompanhe as notas técnicas dos documentos e serviços que a sua empresa usa e teste os campos de CNPJ com os casos da tabela acima assim que os ambientes de homologação permitirem.

Conclusão

O CNPJ alfanumérico é uma mudança pequena no papel e grande no código legado. Como os CNPJs antigos continuam valendo e os novos chegam aos poucos, é fácil adiar a adaptação até o primeiro cliente não conseguir se cadastrar. Uma função de validação única, colunas de texto e uma bateria de testes com os casos acima resolvem a maior parte do problema.

Para consultar empresas por CNPJ, com ou sem máscara, nos dois formatos, experimente a busca da CNPJpedia.