Validação CPF CNPJ é uma das primeiras tarefas de quem trabalha com formulários no Brasil, e também uma das mais mal compreendidas. Os dois números seguem uma lógica semelhante — uma parte de identificação seguida de dígitos calculados —, mas respondem a perguntas diferentes e circulam em contextos diferentes. Neste texto, tratamos do que cada um representa, de como a conferência aritmética funciona e, principalmente, do que ela não responde.
O que são CPF e CNPJ?
O CPF é o número brasileiro associado a uma pessoa natural; o CNPJ é o número associado a uma pessoa jurídica. Um acompanha indivíduos, o outro acompanha organizações, e essa diferença de sujeito é a razão de existirem duas numerações em vez de uma.
Apesar do propósito distinto, os dois compartilham o essencial da mecânica: cada número é formado por uma parte identificadora e por dois dígitos verificadores calculados a partir dela. Nenhum dos dois carrega significado próprio nos dígitos verificadores — eles não dizem região, tipo, data nem categoria. Servem para conferir se o restante da sequência está consistente.
Essa é a razão pela qual qualquer validação séria começa dizendo o que ela verifica. Conferir CPF ou CNPJ, na prática, é conferir estrutura e aritmética — nada além disso.
Como a estrutura dos dois números se diferencia
As diferenças entre os dois aparecem mais na forma de uso do que na lógica interna. Uma máscara de exibição, por exemplo, insere separadores para facilitar a leitura; esses separadores fazem parte da apresentação, não do número.
| Aspecto | CPF | CNPJ |
|---|---|---|
| Quem representa | Pessoa natural | Pessoa jurídica |
| Dígitos verificadores | Dois, calculados sobre a parte anterior | Dois, calculados sobre a parte anterior |
| Ideia do cálculo | Soma ponderada, resto e conversão em algarismo | Soma ponderada, resto e conversão em algarismo |
| Separadores | Apenas exibição | Apenas exibição |
O ponto prático dessa tabela é que qualquer rotina de limpeza funciona igual para os dois: descartar separadores, manter apenas algarismos e preservar zeros à esquerda. Zeros à esquerda são um detalhe traiçoeiro — quem armazena o número como número inteiro perde a posição inicial e passa a conferir uma sequência diferente da que foi digitada.
A ideia do cálculo: somar com pesos e usar o resto
O cálculo dos dígitos verificadores segue o esqueleto clássico descrito em algoritmos de dígito verificador: multiplicar cada posição por um peso, somar os produtos, dividir a soma por um módulo e transformar o resto em um algarismo final. Cada um dos dois números brasileiros calcula dois dígitos verificadores por esse caminho, e o segundo costuma considerar o primeiro como parte da entrada.
Em linguagem corrente, o processo tem quatro etapas:
- Limpar a sequência, mantendo somente os algarismos que compõem o número.
- Multiplicar cada posição pelo peso correspondente à sua colocação.
- Somar os produtos e obter o resto da divisão pelo módulo do esquema.
- Converter o resto no algarismo verificador e repetir o procedimento para o segundo dígito.
Como a soma final depende de todas as posições, uma troca de algarismos costuma mudar o resto — e é exatamente essa a função dos dígitos. Erros de digitação que alteram um caractere, ou que trocam dois vizinhos de lugar, tendem a produzir uma sequência que não fecha.
Vale lembrar que a aritmética não é uma invenção de cada sistema: ela é publicada e estável, e o trabalho de quem implementa é reproduzi-la fielmente, não criar variações. Implementações divergentes surgem quando alguém tenta “melhorar” a regra ou copia um trecho sem entender qual posição recebe qual peso.
Por que sequências de dígitos iguais são descartadas?
Uma sequência composta por um mesmo algarismo repetido — como tudo zeros ou tudo uns — costuma ser excluída pelas próprias regras formais de validação. Não se trata de um capricho: essas sequências são o que aparece quando alguém preenche um campo sem pensar, e aceitá-las produziria muitos falsos positivos.
Ao implementar, esse caso precisa de tratamento explícito. Se a rotina apenas aplica os pesos e compara o resultado, algumas dessas sequências fecham a conta por construção, e o sistema passa a considerar aceitável uma entrada claramente artificial. A verificação precisa, portanto, de duas etapas: a checagem formal da aritmética e a rejeição das sequências triviais.
A mensagem exibida ao usuário deve refletir essa distinção. Dizer que a sequência é inválida sem explicar o motivo gera tentativas repetidas de corrigir algo que não tem correção. Quando o problema é a própria composição da entrada, vale dizer isso de forma direta.
Formato válido e situação cadastral são coisas distintas
Aqui está o ponto que mais causa confusão em projetos reais. Um número pode passar em todas as verificações de formato e aritmética e, ainda assim, não estar registrado em lugar nenhum. O inverso também acontece: um número em situação regular pode ser digitado com um erro e ser reprovado pela conferência.
Os dois resultados vivem em camadas diferentes. A conferência local responde a uma pergunta estreita: esta sequência foi construída segundo as regras? A consulta a um cadastro responde a outra: este número existe e está em que condição? A primeira é instantânea, offline e determinística; a segunda depende de terceiros, pode falhar e traz informação que muda com o tempo.
Confundir as camadas produz frases erradas na interface — por exemplo, dizer que um número “não existe” quando a única coisa observada foi uma soma ponderada que não fechou. A redação correta é sempre a mais fraca: o formato não corresponde, ou o formato corresponde e os dígitos se confirmam.
Para quem desenvolve: limpeza, máscara e mensagem de erro
Na prática, a maior parte dos problemas não está na aritmética, mas no tratamento da entrada. Um roteiro que costuma funcionar:
- Normalizar antes de validar: remover separadores, preservar zeros à esquerda e tratar a entrada como texto, nunca como número.
- Rejeitar sequências triviais com mensagem própria, separada da mensagem de erro aritmético.
- Distinguir os três estados possíveis para o usuário — formato aceitável, formato reprovado e não reconhecido — em vez de reduzir tudo a um único “inválido”.
- Manter a máscara restrita à exibição, aplicando-a depois da limpeza e nunca durante a conferência.
- Registrar qual regra foi aplicada e em que versão, para poder explicar decisões antigas quando o esquema mudar.
Vale também evitar validar enquanto a pessoa ainda está digitando. Reprovar uma entrada parcial produz erro falso e ruído visual; a conferência faz sentido quando a sequência está completa.
Nenhum dos números usados como ilustração neste texto foi emitido por ninguém: são montagens didáticas, e o resultado da conferência não informa nada sobre a situação cadastral de uma pessoa ou de uma empresa.
Próximos passos
Se você precisa aplicar a mesma rotina a documentos de outros países, o texto sobre regras de validação de documento nacional mostra por que isso quase nunca é uma cópia direta. Para a matemática por trás da conta, volte ao panorama de algoritmos de dígito verificador. E para testar uma sequência agora, use a ferramenta de validação de número, que exibe cada dígito verificador conferido e o resultado por camada.