A matemática do CPF: módulo 11, dígito verificador e casos de teste

Todo formulário que pede CPF acaba, cedo ou tarde, tendo que validar se aquele número é estruturalmente possível — não se a pessoa existe, mas se os 11 dígitos são matematicamente consistentes entre si. É uma validação que parece trivial de implementar e, por isso mesmo, é reimplementada do zero em quase todo projeto, geralmente errada de um jeito sutil o suficiente para passar despercebida até alguém digitar um CPF real que a lógica rejeita, ou pior, um CPF inválido que a lógica aceita.

O que cada posição do CPF representa

O CPF tem 11 dígitos, divididos em três blocos com papéis diferentes:

• Posições 1 a 8: número de identificação do contribuinte, atribuído sequencialmente pela Receita Federal.
• Posição 9: indica a região fiscal em que o CPF foi emitido (0 a 9, cada valor corresponde a um estado ou grupo de estados). É por isso que uma ferramenta que gera CPF "sintonizado" com um estado específico consegue escolher esse dígito de forma consistente com o restante dos dados gerados.
• Posições 10 e 11: os dois dígitos verificadores, calculados a partir dos nove anteriores. São eles que permitem detectar erro de digitação ou transcrição sem precisar consultar nenhuma base de dados.

Como o algoritmo de módulo 11 funciona

O cálculo de cada dígito verificador segue o mesmo padrão em duas etapas:

1. Multiplica-se cada um dos dígitos anteriores por um peso decrescente, começando do maior peso para o primeiro dígito da sequência. Para o primeiro dígito verificador, os pesos vão de 10 a 2 sobre os 9 primeiros dígitos; para o segundo dígito verificador, os pesos vão de 11 a 2 sobre os 10 dígitos já existentes (os 9 originais mais o primeiro dígito verificador recém-calculado).
2. Soma-se todos os produtos e calcula-se o resto da divisão dessa soma por 11.

E aqui está o ponto que mais gera implementação errada: o dígito verificador não é simplesmente 11 − resto. Existe uma regra de exceção:

• Se o resto da divisão for 0 ou 1, o dígito verificador é 0.
• Caso contrário, o dígito verificador é 11 − resto.

Sem essa exceção, um resto igual a 1 geraria um dígito verificador "10" — um valor de dois algarismos que não cabe em uma única posição decimal. É exatamente esse detalhe que separa uma implementação correta de uma que funciona para a maioria dos CPFs testados manualmente, mas falha silenciosamente para uma fração específica de combinações, porque quem implementou nunca gerou um caso de teste onde o resto desse exatamente 0 ou 1.

Um exemplo passo a passo

Para os 9 primeiros dígitos 1 1 1 4 4 4 7 7 7:

Primeiro dígito verificador — multiplicando cada posição pelos pesos 10, 9, 8, 7, 6, 5, 4, 3, 2 e somando: (1×10)+(1×9)+(1×8)+(4×7)+(4×6)+(4×5)+(7×4)+(7×3)+(7×2) = 10+9+8+28+24+20+28+21+14 = 162. O resto de 162 ÷ 11 é 8, que não é 0 nem 1, então o primeiro dígito verificador é 11 − 8 = 3.

O segundo dígito verificador repete o processo sobre os 10 dígitos agora existentes (1 1 1 4 4 4 7 7 7 3), com pesos de 11 a 2. Esse encadeamento — o segundo dígito depende do primeiro, que depende dos nove originais — é outro detalhe que precisa estar certo na ordem de implementação: calcular os dois dígitos em paralelo a partir dos 9 dígitos originais, em vez de calcular o segundo a partir dos 10 (incluindo o primeiro já calculado), é um erro comum que produz um dígito verificador plausível, mas errado.

O buraco que o módulo 11 sozinho não cobre

O algoritmo de módulo 11 detecta a maioria dos erros de digitação, mas tem uma cegueira estrutural conhecida: qualquer sequência de 11 dígitos repetidos — 111.111.111-11, 222.222.222-22, e assim por diante até 999.999.999-99 — passa matematicamente no cálculo do dígito verificador. Nenhuma dessas sequências é um CPF real emitido pela Receita Federal, mas o algoritmo, isolado, não tem como saber disso. Por isso toda implementação de validação precisa de uma checagem explícita adicional que rejeite os 10 casos de dígito repetido antes mesmo de rodar o cálculo do módulo 11 — pular essa checagem é o erro mais comum em implementações "from scratch" copiadas de algum lugar sem entender essa ressalva.

Onde isso costuma quebrar em testes

• Entrada com e sem máscara. Uma validação que espera 123.456.789-09 e recebe 12345678909 sem pontuação (ou vice-versa) precisa normalizar antes de calcular — normalmente removendo tudo que não é dígito — senão rejeita entradas válidas por motivo de formatação, não de matemática.
• Transposição de dígitos. Trocar a ordem de dois dígitos adjacentes (erro de digitação clássico) quase sempre muda o resultado do módulo 11 o suficiente para invalidar o CPF — é um bom caso de teste para confirmar que a validação realmente está calculando, e não só checando o formato com regex.
• Zero à esquerda. CPFs que começam com 0 são comuns e totalmente válidos; qualquer lógica que converta a string para número antes de processar corre o risco de perder esse zero à esquerda e desalinhar todo o cálculo de peso por posição.
• Resto exatamente 0 ou 1. Como descrito acima, esse é o caso que mais frequentemente expõe uma implementação que esqueceu a regra de exceção — vale ter pelo menos um CPF de teste que force essa condição.
• As 10 sequências de dígito repetido. Testar explicitamente que 000.000.000-00 até 999.999.999-99 são todos rejeitados, mesmo passando na matemática do módulo 11.

O Gerador de CPF deste site já aplica esse algoritmo completo — incluindo a regra de exceção do resto 0/1 — para produzir números estruturalmente válidos com ou sem máscara, prontos para virar massa de teste. O Validador de CPF serve para conferir rapidamente se um número específico é matematicamente consistente antes de usá-lo num caso de teste, e o Gerador de Pessoas gera CPF já sintonizado com o estado e a região fiscal de um perfil completo, para quando o teste precisa de mais do que um número isolado.