CASO DE USO
Valide identificadores antes da conciliacao financeira
O processo de conciliacao casa linhas entre sistemas: pagamento vs. fatura vs. customer record. Quando a mesma entidade aparece com tax_id em formatos diferentes entre as tres fontes — '123.456.789-09' em facturacao, '12345678909' em payments, '123456789-09' no CRM — o match falha. A linha fica numa pilha de excecoes que alguem precisa resolver na mao. Normalizar formato antes do match reduz essa pilha.
O PROBLEMA
Variacao de formato gera falsos negativos no match
Um processo de conciliacao saudavel tem taxa baixa de excecoes. Quando a base esta suja de formato, a taxa sobe — nao porque ha erros reais, mas porque o match nao acha linhas que na verdade casam.
Mesma entidade, formatos diferentes por fonte
Sistema A (facturacao) guarda tax_id com mascara. Sistema B (payments) guarda sem separadores. Sistema C (CRM) guarda como veio do formulario. Os tres sao a mesma entidade mas um join SQL cru nao os case.
Excecoes de conciliacao que nao sao excecoes reais
O time financeiro recebe uma pilha de mismatches que vira formato, nao negocio. Resolver manualmente e trabalho desperdicado.
Drift de formato entre integracoes
Cada nova integracao (ERP novo, marketplace novo, billing novo) traz sua convencao de formato. Sem normalizacao central, a base se suja a cada conector.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
Por que SQL cru nao resolve isso
REPLACE/REGEXP em SQL
Remover pontos, hifens e espacos em SQL normaliza visualmente, mas nao detecta tax IDs invalidos. Voce fica com strings homogeneos mas alguns nao sao tax IDs reais (DV invalido).
Match engine do ERP
O matching engine de NetSuite, SAP ou Oracle e bom para regras de negocio mas nao implementa nativamente checksum de CPF/CUIT/RFC. Voce escreve a regra custom — e mantem.
Resolver excecoes manualmente
Aonde a maioria dos times termina: contratar mais analistas de conciliacao. Escala mal e e trabalho enfadonho.
COMO O NORMADATA AJUDA
Como o Normadata ajuda
Antes de qualquer match, passe os tax IDs por verify/tax-id. O campo normalized da a forma canonical — use como chave de join entre as tres fontes.
Linhas com valid=false sao data quality issues reais (nao problemas de formato). Marque a parte para revisar em workflow separado.
Uma API, mesmo schema para CPF, CUIT, RFC, RUT, NIT, RUC. Seu pipeline de normalizacao e um so para LATAM.
VEJA EM ACAO
Veja em acao
# Source A stores tax_id as '20-31456789-0'
# Source B stores it as '20314567890'
# Source C stores it as '20.31456789.0'
# All three normalize to the same canonical string
$ curl -X POST api.normadata.io/v1/verify/tax-id \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"country":"AR","type":"cuit","value":"20-31456789-0"}'
{
"valid": true,
"normalized": "20314567890",
"formatted": "20-31456789-0"
}
# Use 'normalized' as the join key across invoices, payments, customers
# JOIN payments p ON p.tax_id_norm = c.tax_id_norm
# Matching engine + dedup logic stay on your side — we give the canonical keyLIMITACOES
O que o Normadata nao faz aqui
—O Normadata nao e um matching engine. Nao resolve conflitos de negocio, nao aplica regras de match, nao e um rule engine. Da a chave canonical — a logica de match fica no seu sistema.
—O Normadata nao resolve duplicados sozinho. Da o sinal (mesmo normalized = mesma entidade) mas a decisao de merge/dedup e do time que conhece o negocio.
PERGUNTAS FREQUENTES
Perguntas frequentes
Integra com NetSuite, SAP ou Oracle Financials?
Nao temos integracoes nativas. O normal e invocar o Normadata do seu pipeline de ETL ou middleware entre o ERP e o matching engine — voce adiciona uma coluna tax_id_normalized usada nos joins.
Resolve duplicados automaticamente?
Nao. O Normadata da a forma canonical do tax ID. Se duas linhas tem o mesmo normalized, voce sabe que e a mesma entidade. A decisao de mergear, manter separados ou flaguear para revisao e da sua logica de negocio.
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.