Validación de Tax IDs en Sudamérica, una sola API.
Cada país corre un checksum diferente. CUIT usa Mod-11 con pesos custom, CPF corre dos rondas seguidas de Mod-11, RFC carga una homoclave alfanumérica, RUT tiene un dígito verificador que puede ser la letra K. Normadata implementa todos detrás de un único endpoint.
10 países, 10 algoritmos de checksum
Un CUIT argentino y un CPF brasileño no comparten ninguna regla. La RFC mexicana incluye una homoclave alfanumérica que pocas librerías open-source resuelven bien. El RUT chileno es Mod-11 derecha a izquierda con un dígito verificador que puede ser K. El RUT uruguayo (el otro) usa un vector de pesos distinto. Cada equipo que escribe sus propios validadores copia un snippet de Stack Overflow que falla en algún edge case o paga una licencia enterprise para correr un regex. Normadata centraliza la lógica por país — formato, checksum y normalización — en un endpoint con un único schema JSON.
Cada checksum, cada formato
Doce tipos de tax ID validados en producción, cada uno con su algoritmo.
Argentina · CUIT, CUIL
Mod-11 con pesos custom, 11 dígitos, verificador al final con la regla especial de 10 → swap.
Brasil · CPF, CNPJ
Dos rondas seguidas de Mod-11, 11 dígitos para CPF, 14 para CNPJ. Formato con puntos y guiones en la salida.
México · RFC
12 chars para moral, 13 para físico. Homoclave alfanumérica contra la tabla oficial del SAT.
Chile, Uruguay · RUT
Mod-11 derecha a izquierda. Chile permite la letra K como verificador. Uruguay usa otro vector de pesos.
Colombia, Bolivia · NIT, Cédula
NIT con checksum ponderado estilo DIAN. Cédula validada contra longitud y perfil del país.
Perú, Ecuador, Paraguay · RUC
Variantes de RUC por país — 11 dígitos en Perú, 13 en Ecuador con el tercer dígito indicando tipo de contribuyente.
10 países · 12 tax IDs
Cada mercado sudamericano vivo tiene al menos un validador de tax ID en producción. La tabla completa — tipo, categoría, ejemplo y algoritmo — está en la página de cobertura.
Una request, un resultado normalizado
Mandá value con country y type explícitos para validación rápida, u omitilos para que Smart Parse rankee candidatos. En ambos casos el shape de la respuesta es idéntico.
$ curl -X POST https://api.normadata.io/v1/verify/tax-id \
-H "X-API-Key: nd_your_key_here_22_random_bytes" \
-d '{"value":"20-12345678-9","country":"AR","type":"cuit"}'{
"contains_pii": true,
"processed_at": "2026-05-15T01: 00: 00Z",
"value": {
"source": "20-12345678-9",
"normalized": "20123456789",
"formatted": "20-12345678-9",
"country": "AR",
"type": "cuit",
"valid": true,
"confidence": 0.98
}
}¿Cómo se compara Normadata?
Comparaciones honestas contra las alternativas que más nos preguntan.
Normadata vs. validator.js
La librería NPM open-source de facto para strings genéricos — y dónde se queda corta con tax IDs LATAM.
Normadata vs. AFIP scraper
El sitio de AFIP expone datos reales del contribuyente — cuando no se rompe antes.
Normadata vs. Receita Federal scraper
El padrón de Receita Federal expone datos reales del contribuyente — cuando el WS está arriba.
Dejá de mantener validadores de tax ID por país
Gratis durante acceso anticipado. Escribinos un email y respondemos en 24 horas.