CASO DE USO
Limpieza masiva de bases de datos con tax IDs LATAM malformados
La base de clientes tiene 100k filas. El CPF aparece en cinco formatos: con puntos, con guion, sin separadores, con espacios, con la mascara de la planilla original. Los joins entre tablas estan rotos porque la fila '123.456.789-09' no matchea '12345678909'. Hay duplicados porque el mismo cliente entro tres veces con tres formatos distintos. Un script de cleanup que normalice formato y detecte invalidos arregla la base — pero requiere un validador por pais que funcione bien y barato.
EL PROBLEMA
La variacion de formato rompe joins y crea duplicados
Antes de cualquier proyecto de data quality, BI o migracion, la base de clientes LATAM necesita una pasada de normalizacion. Las herramientas estandar de ETL no traen validadores por pais.
Los mismos datos en formatos distintos por fila
Un cliente B2C entro tres veces: una desde el checkout (con mascara), una desde el CRM importado por planilla (sin mascara), una desde una integracion legacy (con espacios). Las tres filas son la misma persona pero ninguna herramienta de dedup las matchea sin normalizar primero.
Joins entre tablas se rompen silenciosamente
La tabla customers tiene CPF con puntos. La tabla payments tiene CPF sin separadores. El JOIN customers.cpf = payments.cpf devuelve cero matches. El reporte de BI sale mal. Nadie lo nota hasta que el director de finanzas pregunta por que las ventas no cierran.
Tax IDs invalidos que nunca debieron entrar
Algunas filas tienen valores que simplemente no son tax IDs validos — longitud incorrecta, checksum fallido, caracteres extranos. Esos datos no son recuperables: hay que marcarlos como invalidos antes de hacer dedup.
POR QUE LAS SOLUCIONES ESTANDAR NO ALCANZAN
Por que un script de limpieza casero falla
Regex para quitar puntuacion
Quitar puntos y guiones normaliza formato pero no detecta tax IDs invalidos (CPF con DV incorrecto, CUIT con prefijo malo). Te queda una base de strings limpios pero algunos no son tax IDs reales.
pandas + libreria por pais
Funciona para un pais, dos a lo sumo. Cuando tu base tiene CPF, CUIT, RFC, RUT y NIT mezclados, mantener una stack de validadores por pais en el notebook se vuelve fragil.
Tools de data quality enterprise
Talend, Informatica y similares cubren bien IDs de EU/US (VAT, SSN, IBAN) pero los modelos out-of-the-box no traen CUIT, CPF, RFC con checksum correctamente implementado.
COMO NORMADATA AYUDA
Como Normadata te ayuda
Loop sobre el CSV con verify/tax-id en paralelo (10-20 workers, ~30ms p95 por llamada). El campo normalized te da la clave canonica para todas las filas — joins arreglados, dedup limpio.
Si tu input es ambiguo (no sabes el pais o el tipo), usa /v1/verify (smart parse) que detecta el tipo automaticamente segun la heuristica del valor.
Las filas con valid=false quedan flaggeadas en una columna aparte — son datos no recuperables que el equipo de data quality decide si manda a re-captura o si los marca como cerrados.
MIRALO EN ACCION
Miralo en accion
# Loop over CSV rows — single endpoint, parallelize client-side
# Python pseudocode (requests, no SDK)
# import csv, requests
# for row in csv.reader(open('customers.csv')):
# r = requests.post(url, headers=H, json={...})
# write_to(out, r.json()['valid'], r.json()['normalized'])
# Each row → one verify call
$ curl -X POST api.normadata.io/v1/verify/tax-id \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"country":"BR","type":"cpf","value":"111.444.777-35"}'
{
"valid": true,
"normalized": "11144477735",
"formatted": "111.444.777-35"
}
# Write normalized to canonical column; mark valid=false for review
# ~30ms p95 → 100k rows in minutes with 10 parallel workersLIMITACIONES
Que no hace Normadata aqui
—Normadata no hace enrichment. No devuelve razon social, no devuelve nombre, no devuelve estado del contribuyente. Solo valida formato y devuelve la forma canonical.
—Normadata no tiene endpoint batch. Cada tax ID es una llamada. Para limpiar 100k filas, paralelizas client-side respetando tus rate limits.
PREGUNTAS FRECUENTES
Preguntas frecuentes
Hay un endpoint batch para mandar 10k filas de una?
No. La API procesa un tax ID por llamada. Para volumenes grandes, recomendamos paralelizar client-side (10-50 workers segun plan) y respetar el rate limit. A ~30ms p95, 100k filas se procesan en minutos.
Que velocidad tiene la API?
La latencia interna p95 esta cerca de 30ms para verify/tax-id. La latencia end-to-end depende de tu red y region. Para batch cleanup desde la misma region cloud, el throughput dominado por la paralelizacion client-side.
Integra Normadata en tu stack
El acceso se otorga manualmente. Unite a la lista de espera y te damos acceso a la API.