CASO DE USO
ERP master data: um formato canonical para tax IDs entre países
Seu ERP guarda o mesmo CPF como 111.444.777-35, 11144477735, 111 444 777 35 e 111-444-777-35 dependendo de quem preencheu. Joins quebrados. Duplicados. Reports inflados. A Normadata devolve a forma canonical determinística — sempre a mesma string para o mesmo registro.
O PROBLEMA
O mesmo identifier em 5 formatos quebra o master data
Sem normalização, o master data cresce com drift. Joins SQL falham, dedup pipelines não matcheiam, BI dashboards contam double, KPIs saem tortos.
Joins entre tabelas legacy falham por formato
tabela_clientes.cnpj = '11.222.333/0001-81', tabela_pagos.cnpj = '11222333000181'. Mesmo cliente, duas strings. O join devolve zero rows.
Dedup pipelines não encontram duplicados
Seu pipeline de Master Data Management busca duplicados por cnpj exato. Não encontra nenhum porque cada source guardou o CNPJ em um formato diferente. Enquanto isso, há 14 duplicados reais na base.
BI dashboards reportam números inflados
O dashboard de "clientes únicos por mês" conta 1.247 quando na verdade são 1.103 — os duplicados por formato contam double. O CFO pergunta por que os números não batem com os reports oficiais.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
Por que o ERP não normaliza por default
Validação manual no data entry
O analista de master data corrige os formatos na mão. Funciona a 100 records/dia. Não funciona a 100.000.
UDF de SQL para normalizar
Uma função SQL strip-non-numeric pega o caso simples mas não entende DV nem regras LATAM. Se o input já tem typo, a "normalização" perpetua o erro.
ETL custom no data warehouse
Seu time de data eng escreve a normalização em dbt ou Airflow. Funciona mas exige manutenção permanente quando os formatos mudam ou é adicionado um país.
COMO O NORMADATA AJUDA
Como o Normadata ajuda
POST /v1/validate/tax-ids no insert path do ERP. O response.value.normalized sempre devolve a mesma string para o mesmo CPF/CNPJ/CUIT — independente do formato do input.
Para auditorias batch do master existente: rode um job noturno sobre sua tabela principal, mande cada row para /v1/validate/tax-ids, escreva response.normalized em uma shadow table _canonical. Depois você promove para canonical.
Para países novos: você adiciona o country no request, não adiciona lógica. O envelope de response é o mesmo para todos os países cobertos — os joins downstream não mudam.
VEJA EM ACAO
Veja em acao
# Collapse format variants to one canonical form — batch your master records
$ curl -X POST api.normadata.io/v1/validate/tax-ids \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"items":[
{"id":"a","country":"BR","type":"cpf","value":"111.444.777-35"},
{"id":"b","country":"BR","type":"cpf","value":"111 444 777 35"}
]}'
{
"results": [
{ "id": "a", "valid": true, "normalized": "11144477735" },
{ "id": "b", "valid": true, "normalized": "11144477735" }
]
}
# Both inputs normalize to 11144477735 → use it as the master-data primary keyLIMITACOES
O que a Normadata não faz em ERP master data
—Não escreve no seu ERP. Você faz o upsert com o valor normalized — a Normadata só devolve o canonical.
—Não é um MDM completo. Não deduplica registros automaticamente. Dá strings consistentes para que seu rule engine de dedup matcheie corretamente.
PERGUNTAS FREQUENTES
Perguntas frequentes
Quantas rows posso processar num batch?
Sua paginação, não a nossa. A API processa 1 row por chamada — paralelize client-side com sua batch tool (Airflow, dbt, n8n, custom).
Suporta NetSuite/SAP S/4/Sage?
Qualquer ERP que possa chamar uma REST API. Não há conector nativo — mas todos os ERPs modernos têm integração HTTP.
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.