METODOLOGÍA · BRASIL
Dígito verificador del CPF
El CPF brasileño tiene dos dígitos verificadores calculados secuencialmente con el algoritmo Mod-11. Esta página explica ambas pasadas del algoritmo, incluye un ejemplo numérico completo, y detalla 15 edge cases de producción — incluyendo por qué los CPFs de dígitos repetidos son inválidos aunque el algoritmo pase.
El algoritmo
El CPF (Cadastro de Pessoas Físicas) es el número de identificación fiscal brasileño para personas físicas, emitido por la Receita Federal do Brasil. Tiene 11 dígitos en el formato XXX.XXX.XXX-VV, donde VV son dos dígitos verificadores calculados secuencialmente con dos pasadas de Mod-11.
Pasada 1 — primer dígito: multiplica los 9 primeros dígitos por los pesos [10, 9, 8, 7, 6, 5, 4, 3, 2], suma los productos, calcula resto = suma mod 11. Si resto < 2, dígito = 0; si no, dígito = 11 − resto.
Pasada 2 — segundo dígito: repite el proceso con los 9 dígitos base más el primer dígito verificador ya calculado, usando pesos [11, 10, 9, 8, 7, 6, 5, 4, 3, 2]. Misma regla para el resultado.
Ejemplo numérico paso a paso
Calculamos los dígitos verificadores para los 9 dígitos base 529.982.247.
Paso 1 — primer dígito
Paso 2 — segundo dígito
Pseudocódigo
digits = strip_non_numeric(input) // 11 chars if all_same_digit(digits) → INVALID pass1_weights = [10, 9, 8, 7, 6, 5, 4, 3, 2] d1 = compute_check(digits[0..8], pass1_weights) pass2_weights = [11, 10, 9, 8, 7, 6, 5, 4, 3, 2] d2 = compute_check(digits[0..9], pass2_weights) return d1 == digits[9] AND d2 == digits[10] // compute_check(d, w): sum = Σ d[i]×w[i]; rem = sum mod 11; return rem < 2 ? 0 : 11−rem
Edge cases que una implementación simple no maneja
- CPFs de dígitos repetidos (000.000.000-00 a 999.999.999-99): pasan el algoritmo matemáticamente pero son inválidos. La Receita Federal los rechaza explícitamente. Son 10 patrones que cualquier implementación debe filtrar.
- Resto < 2 → dígito = 0, no 11 − resto: diferencia crítica del Mod-11 clásico. Implementaciones que aplican la fórmula estándar sin esta corrección rechazan CPFs válidos con dígitos verificadores 0.
- CPF con cero inicial perdido: sistemas que tratan el CPF como entero pierden el cero inicial (ej.: 012.345.678-90 se convierte en 12345678-90). La validación pasa a tener 10 dígitos y falla.
- CPF de menores de edad: los niños tienen CPF desde el nacimiento. No hay ningún campo extra — el CPF tiene el mismo formato para cualquier franja etaria.
- CPF en NF-e vs CPF en PIX: para emitir NF-e basta validar el formato. Para PIX, el CPF necesita estar activo en la Receita Federal y vinculado a una clave PIX — validar el formato es condición necesaria pero no suficiente.
- Formatos de entrada: 529.982.247-24, 52998224724, 529 982 247 24 — todos válidos como input. Puntos, guiones y espacios deben eliminarse antes de validar.
- CPF cancelado por la Receita: CPFs suspendidos o cancelados pasan la validación de formato. Solo una consulta a la Receita confirma el estado activo.
- Cambio de nombre no altera el CPF: el CPF es vitalicio y no cambia con matrimonio, divorcio o cambio legal de nombre. Sistemas que recalculan el CPF desde el nombre cometen un error conceptual.
- CPF de personas fallecidas: sigue siendo matemáticamente válido. Sin consulta a la Receita no es posible detectar que el titular falleció.
- Validación en batch: 100k CPFs en un loop Python con regex recompilada en cada iteración es 3-5x más lento que precompilar. Operaciones vectorizadas reducen aún más el overhead.
- Caracteres Unicode invisibles: zero-width spaces y marcas RTL en inputs copiados de PDFs o WhatsApp rompen strips de caracteres no numéricos basados en regex simple.
- Integración con sistemas legacy: CPFs provenientes de COBOL o mainframe llegan frecuentemente en campos de ancho fijo con padding de espacios a la izquierda o derecha.
- Patrones secuenciales no emitidos: CPFs como 123.456.789-09 pasan el algoritmo pero la Receita Federal nunca emite secuencias completamente ordenadas.
- CPF vs CNPJ en el mismo campo: sistemas genéricos de documento fiscal aceptan CPF o CNPJ en el mismo campo. La discriminación requiere verificar la longitud después del strip: 11 = CPF, 14 = CNPJ.
- Encoding en XML de NF-e: CPFs con caracteres de control insertados por sistemas de RRHH pueden corromper el XML antes de que la validación de formato llegue a ejecutarse.
¿Querés saltarte todo esto?
Manejar todos estos edge cases en producción cuesta semanas de testing y mantenimiento permanente conforme cambian las reglas regulatorias. La API de Normadata maneja todo lo de arriba — incluyendo los casos que ni listamos aquí — con una sola llamada REST.
Fuentes
Receita Federal do Brasil — especificación pública del algoritmo de validación del CPF. El algoritmo es de dominio público desde hace décadas.