CASO DE USO

Limpieza de bases de datos con tax IDs LATAM malformados

La base de clientes tiene formatos mezclados. El CPF aparece 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 proceso 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

Mandá tus tax IDs a POST /v1/validate/tax-ids en lotes de hasta 1.000 ítems por request. El campo normalized te da la clave canonica para todas las filas — joins arreglados, dedup limpio. El mismo endpoint valida 1 o N.
Cada item lleva su country y type. Lotes mas grandes que el limite se paginan — partís el dataset en requests de hasta 1.000 piezas.
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

# Send CSV rows in batches — one request, many items
# Python pseudocode (requests, no SDK)
#   import csv, requests
#   rows = list(csv.reader(open('customers.csv')))
#   for chunk in chunks(rows, 1000):    # up to 1,000 items per request
#     items = [{'id': r.id, 'country': r.cc, 'value': r.tax_id} for r in chunk]
#     resp = requests.post(url, headers=H, json={'items': items})

$ curl -X POST api.normadata.io/v1/validate/tax-ids \
  -H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
  -d '{"items":[{"id":"42","country":"BR","type":"cpf","value":"111.444.777-35"}]}'

{
  "results": [
    { "id": "42", "valid": true, "normalized": "11144477735", "formatted": "111.444.777-35" }
  ]
}

# Correlate each result by the id you sent; write normalized to the canonical column
# Mark valid=false rows for manual review
LIMITACIONES

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.
El lote tiene un tope por request (1.000 piezas, 500 records). Para datasets mas grandes, paginás client-side respetando tus rate limits.
PREGUNTAS FRECUENTES

Preguntas frecuentes

¿Puedo mandar varias filas en una sola request?
Sí. El endpoint es batch: mandás un array items con hasta 1.000 piezas por request y recibís un results por ítem, correlacionado por el id que vos proveés. Para datasets mas grandes, paginás en lotes.
Que velocidad tiene la API?
La latencia end-to-end depende de tu red y region. El modelo batch reduce el round-trip por ítem al validar hasta 1.000 piezas por request.

Integra Normadata en tu stack

El acceso se otorga manualmente. Unite a la lista de espera y te damos acceso a la API.