Validación de formato vs. consulta a registros oficiales
¿Cuándo alcanza validar el formato y cuándo necesitás consultar la fuente oficial?
Uno de los malentendidos más comunes al integrar APIs de calidad de datos: confundir "validar el CUIT" con "verificar que el CUIT existe en AFIP". Son dos operaciones completamente distintas, con distintos costos, latencias, casos de uso y garantías. Esta comparativa te explica cuándo cada enfoque es el correcto.
Comparación rápida
| Aspecto | Validación de formato (Normadata) | Consulta a registro oficial |
|---|---|---|
| ¿Qué verifica? | Estructura, dígito verificador, prefijos válidos | Existencia y estado actual en el padrón oficial |
| Latencia típica | <50 ms (sin red externa) | 200 ms – 3 s (depende del organismo) |
| Costo por consulta | Bajo (procesamiento local de algoritmo) | Mayor (llamadas a APIs externas o scraping) |
| ¿Garantiza que el número está activo? | No | Sí (si el organismo lo expone) |
| ¿Requiere conexión al organismo? | No | Sí (AFIP, SAT, Receita Federal, etc.) |
| ¿Detecta typos? | Sí — el dígito verificador falla ante la mayoría de errores de tipeo | Sí, pero a mayor costo y latencia |
| ¿Apto para validar en tiempo real (pre-submit)? | Sí | A veces (depende de SLA del organismo) |
| ¿Normadata lo hace? | Sí | No — Normadata no consulta registros oficiales |
¿Cuándo usar cada uno?
- Pre-checkout: evitar que un usuario avance con un CUIT/RFC/CPF con typo antes de procesar el pago.
- Pre-KYC: filtrar formatos inválidos antes de enviar datos a un proveedor de identidad externo (reduce llamadas fallidas y costos).
- Pre-payout: validar que el tax ID del beneficiario es estructuralmente correcto antes de iniciar una transferencia.
- Limpieza de CRM: normalizar y filtrar registros históricos con datos sucios en batch.
- Defensa contra typos en formularios: retroalimentación inmediata al usuario sin latencia de red.
- Multi-país en una sola API: validar CUIT, CPF, RFC, RUT, NIT con un endpoint unificado.
- KYC final: confirmar que una persona o empresa existe y tiene estado activo ante el organismo fiscal.
- Prevención de fraude: verificar que el número no está dado de baja, suspendido o corresponde a una entidad fantasma.
- Estado fiscal real: saber si una empresa está en concurso de acreedores, inhabilitada o tiene deudas.
- Reporting de compliance: auditorías que requieren evidencia de consulta a fuente primaria.
La confusión más frecuente: 'validar CUIT' no es 'verificar identidad'
Cuando un desarrollador dice 'necesito validar el CUIT del usuario', puede querer decir tres cosas muy distintas: (1) verificar que el formato sea correcto (11 dígitos, prefijo válido, dígito verificador OK), (2) verificar que ese CUIT existe en el padrón de AFIP, o (3) verificar que ese CUIT le pertenece a la persona que lo está ingresando. Normadata hace (1). Nadie hace (3) sin documentación física o biometría. Muchos proveedores ofrecen (2), pero acceder al padrón de AFIP en producción requiere un convenio o scraping que tiene sus propias implicaciones legales y de disponibilidad.
Cómo lo hace Normadata: ejemplo real de /v1/validate/tax-ids
Normadata ejecuta el algoritmo de validación localmente — módulo 11 con pesos específicos por país, verificación de prefijo, longitud y formato. La respuesta incluye el resultado booleano, el tipo inferido y, si falló, el campo específico que causó el error. No hay llamada externa al organismo.
Cuándo combinar ambos enfoques
El patrón más eficiente en producción: usar Normadata en el frontend (formato, typos, feedback inmediato) y el registry lookup solo cuando el usuario supera el formulario y pasa al proceso de onboarding formal. Esto reduce entre 60-80% las llamadas al organismo, porque filtrás los errores de formato antes. El costo y la latencia del registry lookup solo se paga para números que ya son estructuralmente válidos.
Ejemplos de código
curl -X POST https://api.normadata.io/v1/validate/tax-ids \
-H "X-API-Key: nd_your_key" \
-H "Content-Type: application/json" \
-d '{
"items": [
{ "id": "1", "value": "111.444.777-35", "country": "BR" }
]
}'
# Response — one result per item, correlated by id
{
"results": [
{
"id": "1",
"country": "BR",
"type": "cpf",
"valid": true,
"normalized": "11144477735",
"formatted": "111.444.777-35"
}
]
}Normadata valida formato y estructura — no consulta AFIP, SAT, Receita Federal ni ningún organismo oficial. Un número que pasa la validación de Normadata es estructuralmente correcto pero puede no estar registrado o puede estar dado de baja. Para confirmación de estado fiscal activo, necesitás una consulta directa al organismo o un proveedor especializado en registry lookup.
Preguntas frecuentes
¿Normadata consulta a AFIP o SAT?
No. Normadata ejecuta algoritmos de validación localmente. No hay llamada a organismos oficiales. El resultado de Normadata es sobre estructura y formato, no sobre estado registral.
¿Puedo usar Normadata para KYC?
Como paso de pre-filtrado sí: eliminar formatos inválidos antes de enviar datos a tu proveedor de KYC reduce costos. Como reemplazo de KYC, no — KYC requiere verificación de identidad que implica consulta a fuentes primarias y procesos regulatorios que Normadata no cubre.
¿Qué pasa si un CUIT pasa el formato pero el contribuyente está dado de baja en AFIP?
Normadata retornará valid: true porque el formato es correcto. El estado de actividad ante AFIP es información que solo AFIP puede entregar. Para casos donde necesitás estado activo, agregá una consulta al organismo como segundo paso en tu flujo de onboarding.
¿Cuánto reduce los costos usar Normadata antes de un registry lookup?
Depende de la calidad de tus datos de entrada. En formularios con usuarios finales, los errores de formato típicamente representan 15-40% de los inputs. Filtrarlos antes del registry lookup reduce ese porcentaje de llamadas costosas. En procesos de limpieza de CRM legacy, el ahorro puede ser mayor.
¿El dígito verificador garantiza que el número es real?
No. El dígito verificador es un mecanismo de detección de errores de tipeo, no una garantía de existencia. Cualquiera puede construir un CUIT con formato válido que nunca fue asignado por AFIP. Lo que el dígito verificador sí garantiza: si alguien tipea un número al azar o comete un error de un dígito, el algoritmo lo detecta con alta probabilidad.