CASO DE USO
Vendor onboarding: validar tax IDs y cuentas antes de AP
Los proveedores se cargan solos en tu portal con tax ID + cuenta bancaria. Un typo y el primer pago de factura rebota — AP abre ticket, procurement re-contacta al supplier, conciliación se rompe. Normadata corre en el form de alta para que el master de AP solo acepte records limpios.
O PROBLEMA
El primer pago al proveedor rebota por datos mal cargados al onboarding
Self-service onboarding mueve la responsabilidad de captura al supplier. Sin validación, errores estructurales sobreviven hasta el primer pago — el momento más caro para descubrirlos.
CNPJ con sufijo de sucursal omitido
Posiciones 9-12 codifican la sucursal (0001 matriz, 0002+ filiales). Sin las 4, NF-e y AP no pueden rutear correctamente. El proveedor cargó 11 dígitos en lugar de 14 — el form lo aceptó, el sistema lo rechaza tres días después.
CBU pegado con espacios cada 4 dígitos
Los proveedores copian su CBU desde la app del banco con espacios. Sin normalización, el master guarda 22 chars + 4 espacios = 26 — la transferencia falla por longitud incorrecta al llegar al rail BCRA.
CBU vs CVU confundidos
Misma estructura de 22 dígitos, pero CBU es bancario y CVU es fintech (Mercado Pago, Ualá, Brubank). El proveedor pone su CVU en el campo CBU. El rail bancario lo rechaza porque el prefijo de entidad no existe en la tabla BCRA.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
Por qué los validadores genéricos no atrapan estos errores
Validación visual del form
El form acepta cualquier string. La validación es solo "no vacío" — sin estructura, sin DV, sin matriz/filial.
Validación de tu ERP al insert
SAP/NetSuite/Oracle hacen format check básico pero no entienden DV mod-11 ni prefijos LATAM. Para eso instalás 10 librerías o vivís con basura.
Revisión manual
Funciona a 10 proveedores nuevos por semana. No funciona a 200. Y los errores aparecen días después, no en el form.
COMO O NORMADATA AJUDA
Como o Normadata ajuda
POST /v1/verify/tax-id en el form de onboarding del proveedor. Antes del submit, Normadata valida CUIT/CPF/CNPJ/RFC con DV correcto y devuelve normalized + branch/is_headquarters cuando aplica.
POST /v1/verify/bank en el mismo form para CBU/CVU/Pix/CLABE. Normaliza espacios, valida DV, distingue CBU vs CVU por prefijo de entidad.
Para auditorías del padrón existente: corré batch sobre tu tabla de suppliers con POST /v1/verify (smart parse) — flag rows con tax_id o bank malformado para limpieza dirigida.
VEJA EM ACAO
Veja em acao
# Validate supplier CNPJ before writing to AP master
$ curl -X POST api.normadata.io/v1/verify/tax-id \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"country":"BR","type":"cnpj","value":"11.222.333/0001-81"}'
{
"valid": true,
"normalized": "11222333000181",
"formatted": "11.222.333/0001-81",
"identifier": {
"type": "CNPJ",
"category": "tax_id"
}
}
# Then validate the bank account format (CBU for AR supplier)
$ curl -X POST api.normadata.io/v1/verify/bank \
-H "X-API-Key: nd_..." \
-d '{"country":"AR","type":"cbu","value":"0170099220000067802779"}'LIMITACOES
Lo que Normadata no hace en vendor onboarding
—No verifica titularidad bancaria del proveedor. Format-only — el banco confirma titular al primer pago.
—No hace screening de sanciones ni PEP. Eso es tu vendor de compliance — Normadata corre antes, para que ese vendor reciba solo inputs limpios.
PERGUNTAS FREQUENTES
Perguntas frequentes
¿Integra con SAP/Oracle/NetSuite?
Es una REST API. Tu middleware (Boomi, Mulesoft, integración casera) la llama antes de escribir al master de AP. No hay conector nativo — pero no lo necesitás, son ~10 líneas de código.
¿Devuelve la razón social del proveedor?
No. Format-only. Para razón social usá un proveedor de enriquecimiento (Serasa, Veraz, Equifax) o los servicios oficiales de Receita/AFIP/SAT.
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.