CASO DE USO
ERP master data: un formato canonical para tax IDs entre países
Tu ERP guarda el mismo CPF como 111.444.777-35, 11144477735, 111 444 777 35 y 111-444-777-35 dependiendo de quién lo cargó. Joins rotos. Duplicados. Reports inflados. Normadata devuelve la forma canonical determinística — siempre la misma string para el mismo registro.
O PROBLEMA
El mismo identifier en 5 formatos rompe master data
Sin normalización, el master data crece con drift. Joins SQL fallan, dedup pipelines no matchean, BI dashboards cuentan double, KPIs salen torcidos.
Joins entre tablas legacy fallan por formato
tabla_clientes.cnpj = '11.222.333/0001-81', tabla_pagos.cnpj = '11222333000181'. Mismo cliente, dos strings. El join devuelve cero rows.
Dedup pipelines no encuentran duplicados
Tu pipeline de Master Data Management busca duplicados por cnpj exacto. No encuentra ninguno porque cada source guardó el CNPJ en un formato distinto. Mientras tanto, hay 14 duplicados reales en la base.
BI dashboards reportan números inflados
El dashboard de "clientes únicos por mes" cuenta 1.247 cuando realmente son 1.103 — los duplicados por formato cuentan double. CFO pregunta por qué los números no matchean los reports oficiales.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
Por qué el ERP no normaliza por default
Validación manual en data entry
El analista de master data corrige los formatos a mano. Funciona a 100 records/día. No funciona a 100.000.
UDF de SQL para normalizar
Una función SQL strip-non-numeric atrapa el caso simple pero no entiende DV ni reglas LATAM. Si el input ya tiene typo, la "normalización" perpetúa el error.
ETL custom en el data warehouse
Tu team de data eng escribe la normalización en dbt o Airflow. Funciona pero requiere mantenimiento permanente cuando los formatos cambian o se agrega un país.
COMO O NORMADATA AJUDA
Como o Normadata ajuda
POST /v1/verify/tax-id en el insert path del ERP. El response.value.normalized siempre devuelve la misma string para el mismo CPF/CNPJ/CUIT — independiente del formato de input.
Para auditorías batch del master existente: corré un job nocturno sobre tu tabla principal, mandá cada row a /v1/verify/tax-id, escribí response.normalized a una shadow table _canonical. Después promoves a canonical.
Para nuevos países: agregás el country al request, no agregás lógica. El envelope de response es el mismo para los 10 países LATAM — los joins downstream no cambian.
VEJA EM ACAO
Veja em acao
# One canonical form per tax ID, regardless of input format
$ 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"
}
# Variants that all map to the same canonical value:
# "111.444.777-35" → "11144477735"
# "11144477735" → "11144477735"
# "111 444 777 35" → "11144477735"
# "111444777-35" → "11144477735"
# Use normalized as the master-data primary key for tax ID columnLIMITACOES
Lo que Normadata no hace en ERP master data
—No escribe en tu ERP. Vos hacés el upsert con el valor normalized — Normadata solo devuelve el canonical.
—No es un MDM completo. No deduplica registros automáticamente. Te da strings consistentes para que tu rule engine de dedup matchee correctamente.
PERGUNTAS FREQUENTES
Perguntas frequentes
¿Cuántos rows puedo procesar en un batch?
Tu paginación, no la nuestra. La API procesa 1 row por llamada — paralelizá client-side con tu batch tool (Airflow, dbt, n8n, custom).
¿Soporta NetSuite/SAP S/4/Sage?
Cualquier ERP que pueda llamar una REST API. No hay conector nativo — pero todos los ERPs modernos tienen integración HTTP.
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.