Seu sistema valida CNPJ com regex numérica? Em julho de 2026 isso vai quebrar

Tem um \d{2}\.\d{3}\.\d{3}\/\d{4}-\d{2} em algum lugar do seu sistema. Pode estar no frontend numa máscara de input, no backend numa regex de validação, ou na definição de uma coluna BIGINT no banco. Em julho de 2026, esse padrão vai rejeitar CNPJs perfeitamente válidos — e a Receita Federal não vai avisar você individualmente.

A mudança está documentada na Instrução Normativa RFB nº 2.229/2024 desde outubro de 2024. Mas como a maioria dos artigos sobre o assunto foi escrita para empresários preocupados com "preciso trocar meu CNPJ?", o ângulo técnico ficou de lado. Esse post cobre o que o dev precisa saber: o que exatamente quebra, por que quebra, e o que você precisa mudar antes da virada.

Por que o formato está mudando

O CNPJ atual tem 14 posições numéricas. Com 8 dígitos de raiz, 4 de ordem e 2 verificadores, o número total de combinações válidas é finito — e a Receita Federal identificou que o estoque de números disponíveis estava se esgotando com o crescimento de novos cadastros.

A solução foi expandir o alfabeto: a partir de julho de 2026, as primeiras 12 posições (raiz + ordem) passarão a aceitar letras de A a Z além dos dígitos 0 a 9. Só os dois últimos caracteres — os dígitos verificadores — continuam numéricos.

CNPJs já existentes não mudam. Se sua empresa tem CNPJ, ele continua como está. A mudança se aplica apenas a novas inscrições feitas a partir de julho.

O que muda na estrutura do número

O formato permanece em 14 posições. O que muda é o alfabeto aceito em cada bloco:

Posições 1–8   → raiz         (antes: 0–9 | depois: 0–9, A–Z)
Posições 9–12  → ordem        (antes: 0–9 | depois: 0–9, A–Z)
Posições 13–14 → verificadores (mantém: 0–9)

Um CNPJ alfanumérico válido pode ter a cara de algo como B3.QK7.2A1/0001-89. A máscara visual permanece — pontos, barra e hífen nos mesmos lugares. O que muda é que os blocos que antes eram só dígitos agora podem conter letras maiúsculas.

O que quebra no seu sistema

Não é uma mudança, são três mudanças independentes. Cada uma pode estar em um lugar diferente do seu codebase.

1. Regex de validação e máscara de input

Qualquer regex que use \d para validar as 12 primeiras posições vai falhar silenciosamente — ou pior, vai retornar "CNPJ inválido" para um CNPJ perfeitamente legítimo. Isso inclui máscaras de input no frontend que só aceitam dígitos.

A regex de validação precisa aceitar [A-Z0-9] (maiúsculas, sem acento) nas posições 1 a 12. Os verificadores nas posições 13 e 14 continuam sendo \d.

// antes
/^\d{2}\.\d{3}\.\d{3}\/\d{4}-\d{2}$/

// depois
/^[A-Z0-9]{2}\.[A-Z0-9]{3}\.[A-Z0-9]{3}\/[A-Z0-9]{4}-\d{2}$/i

Isso é só a máscara. A validação do dígito verificador é outra história — ver abaixo.

2. Tipo de coluna no banco de dados

Se você guardou CNPJ como BIGINT, INT ou qualquer tipo numérico, precisa migrar para VARCHAR(14) ou CHAR(14). Não tem como armazenar B3QK72A10001 como número.

Se você já guarda como VARCHAR mas com uma constraint CHECK de \d+ ou similar, a constraint também precisa ser atualizada.

3. Integrações que esperam só dígitos

APIs de terceiros, serviços de consulta à Receita Federal, emissores de NF-e, sistemas de cobrança — qualquer integração que recebe CNPJ como parâmetro precisa ser auditada. Se o contrato da API downstream aceita só [0-9]{14}, a falha vai acontecer em runtime, não no seu código.

O novo algoritmo de dígito verificador

Aqui está a mudança mais sutil. O CNPJ sempre usou módulo 11 para calcular os dois dígitos verificadores. A lógica continua a mesma, mas a conversão de caractere para valor numérico mudou.

No CNPJ numérico, cada caractere já é um dígito — sem conversão necessária. No alfanumérico, a regra é: valor = código ASCII do caractere − 48.

Para dígitos (0–9), isso mantém o valor original (ASCII de '0' é 48, então '0' − 48 = 0). Para letras maiúsculas, 'A' tem ASCII 65, então 'A' − 48 = 17. 'Z' tem ASCII 90, então 'Z' − 48 = 42.

def char_to_value(c: str) -> int:
    return ord(c) - 48

def calcular_dv_cnpj(cnpj_sem_dv: str) -> tuple[int, int]:
    # cnpj_sem_dv: 12 caracteres alfanuméricos, maiúsculos, sem formatação
    pesos1 = [5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2]
    pesos2 = [6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2]

    valores = [char_to_value(c) for c in cnpj_sem_dv.upper()]

    soma1 = sum(v * p for v, p in zip(valores, pesos1))
    dv1 = 0 if soma1 % 11 < 2 else 11 - (soma1 % 11)

    soma2 = sum(v * p for v, p in zip(valores + [dv1], pesos2))
    dv2 = 0 if soma2 % 11 < 2 else 11 - (soma2 % 11)

    return dv1, dv2

A lógica de módulo 11 é idêntica ao CNPJ numérico. O único detalhe que muda é a linha char_to_value — e é exatamente aí que validadores antigos vão dar resultado errado sem lançar nenhuma exceção.

Se você usa uma biblioteca de terceiros para validar CNPJ, verifique se ela já foi atualizada para o formato alfanumérico. A maioria das libs populares em JavaScript e Python ainda estava sendo adaptada no início de 2026.

Como testar antes de julho

Três coisas para fazer agora.

Primeiro, gere CNPJs alfanuméricos de teste. A Receita Federal disponibilizou um simulador oficial. Você também pode usar as fórmulas acima para gerar exemplos válidos manualmente — útil para montar fixtures nos seus testes automatizados.

Segundo, rode sua suíte com um CNPJ alfanumérico como input. Se hoje você passa 12.345.678/0001-95 nos testes, substitua por algo como B3.QK7.2A1/0001-89 e veja o que quebra. A falha vai aparecer no frontend (máscara rejeita), no backend (regex falha) ou no banco (insert falha na constraint) — provavelmente nos três.

Terceiro, audite integrações. Liste todos os pontos do sistema que enviam ou recebem CNPJ para serviços externos. Para cada um, verifique a documentação atualizada do fornecedor. Se não houver documentação atualizada, assuma que vai quebrar e planeje um fallback.

O que não muda

Para fechar sem deixar dúvida: CNPJs emitidos antes de julho de 2026 continuam exatamente como são. Nenhuma empresa precisará trocar de número. Nenhuma migração de dados nos seus clientes existentes.

O problema que você tem é de validação e armazenamento de CNPJs novos que entrarão no sistema a partir de julho. Se o seu produto só lida com empresas brasileiras já cadastradas e não registra novos CNPJs, o risco é menor — mas ainda existe na camada de validação de input. Qualquer formulário que aceita CNPJ e rejeita letras vai frustrar um usuário com CNPJ válido.

A mudança tem data marcada e não vai ser adiada. Julho de 2026 é o prazo — e três camadas para auditar leva mais tempo do que parece.

Nota: o conteúdo editorial acabou aqui. O que vem abaixo é uma indicação de ferramenta relacionada ao tema do post.

Ferramenta relacionada

Para gerar CNPJs alfanuméricos válidos durante o desenvolvimento e os testes, o Gerador de CNPJ já suporta o novo formato — incluindo geração de hierarquia matriz/filiais e o modelo alfanumérico de julho de 2026. Útil para montar fixtures antes da virada sem precisar implementar o gerador do zero.