CASO DE USO

Limpia y deduplica registros de CRM con tax IDs de LATAM

Estudios del sector sobre calidad de datos B2B en CRM encuentran consistentemente tasas de duplicados del 5-30% en bases de datos maduras. En LATAM, el problema se agrava: el mismo CPF aparece como '12345678909', '123.456.789-09' y '123456789-09' en tres filas diferentes. La variacion de formato hace que las claves de deduplicacion estandar sean poco confiables. Normadata normaliza los identificadores a una forma canonica para que tu logica de dedup funcione con datos consistentes.

EL PROBLEMA

Los formatos de identificador inconsistentes rompen la deduplicacion

Una importacion de CRM desde un formulario captura '123.456.789-09'. El ERP guarda '12345678909'. Una exportacion de planilla tiene '123456789-09'. Las tres cadenas se refieren al mismo CPF pero una comparacion basica de strings las trata como tres registros diferentes.

La variacion de formato es invisible para las herramientas de dedup estandar
La mayoria de las herramientas de deduplicacion comparan distancia de strings o igualdad de hash. Ninguna detecta representaciones del mismo tax ID que son diferentes en formato pero identicas en valor. Terminas con registros de clientes duplicados que parecen distintos.
Importaciones masivas de multiples fuentes
Cuando unificais un CRM con un ERP legado o importais un CSV de un equipo regional, cada fuente usa su propia convencion de formato. Sin normalizacion previa a la importacion, los duplicados se multiplican con cada batch.
IDs invalidos que pasaron la carga de datos
Algunos registros en tu CRM tienen tax IDs ingresados sin validacion — longitud incorrecta, checksum fallido, formato de pais incorrecto. Son datos muertos: no se pueden matchear con nada porque nunca fueron validos.
POR QUE LAS SOLUCIONES ESTANDAR NO ALCANZAN

Por que las herramientas existentes se lo pierden

Fuzzy matching
El fuzzy matching en nombre + email detecta duplicados donde el formato es consistente. No detecta el caso donde la misma entidad aparece con diferentes emails pero el mismo tax ID en diferentes formatos.
Dedup nativo del CRM
Salesforce, HubSpot y Pipedrive dedupen por email o telefono. No tienen conciencia nativa de los formatos de tax ID de LATAM, por lo que '123.456.789-09' y '12345678909' se tratan como dos valores diferentes.
Scripts de normalizacion manuales
Un regex para quitar puntuacion funciona para CPF pero falla para CUIT (que usa guiones semanticamente) o RFC (que tiene una estructura especifica de homoclave). Los casos borde por pais hacen que un script de limpieza universal sea poco confiable.
COMO NORMADATA AYUDA

Como Normadata te ayuda

Envia cada tax ID por Normadata validate antes de importar o antes de correr dedup. El campo normalized en la respuesta es la clave canonica — usala como identificador de dedup independientemente de como estaba formateado el valor original.
Normadata devuelve valid=false para los IDs que fallan checksum. Marca esos registros como irresolubles antes de que contaminen tu CRM con duplicados que no se pueden arreglar.
Funciona para CPF, CNPJ, CUIT, CUIL, RFC, RUT, NIT, RUC. Un endpoint, misma logica de normalizacion para todos los paises en los que opera tu CRM.
MIRALO EN ACCION

Miralo en accion

# Clean a batch of CRM contacts in one request — validate the whole record
$ curl -X POST api.normadata.io/v1/validate/records \
  -H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
  -d '{"items":[
    {"reference_id":"crm-8841","country":"BR",
     "tax_id":"123.456.789-09","email":"  ANA@Empresa.com ","name":"Ana Souza"}
  ]}'

{
  "results": [
    {
      "reference_id": "crm-8841",
      "country": "BR",
      "fields": {
        "tax_id": { "valid": true, "normalized": "12345678909" },
        "email": { "valid": true, "normalized": "ana@empresa.com" }
      }
    }
  ]
}

# Use the normalized tax_id as the dedup key across CRM rows:
#   "123.456.789-09", "12345678909", "123456789-09" → 12345678909
LIMITACIONES

Que no hace Normadata aqui

Normadata normaliza el formato de un tax ID pero no confirma que la entidad detras de el siga activa, fusionada o disuelta. La consulta a registros requiere una fuente de datos gubernamental.
Normadata no deduplica registros por si mismo — provee la clave canonica normalizada que usas como senal de dedup en tu propia logica de matching o herramienta de CRM.
PREGUNTAS FRECUENTES

Preguntas frecuentes

Cual es la forma normalizada canonica de un CPF?
Normadata devuelve el CPF como una cadena de 11 digitos sin separadores (ej. '12345678909'). El campo formatted devuelve la forma de visualizacion ('123.456.789-09'). Usa el valor normalized como clave de dedup.
Normadata puede manejar normalizacion en lote para una importacion de CRM?
Sí. El endpoint es batch: mandás un array items con hasta 1.000 piezas por request. Integra el paso de validacion en tu pipeline de ETL — un lote por request antes de escribir en tu CRM. Los rate limits aplican por cuenta.

Integra Normadata en tu stack

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