Los Pagos Duplicados Son un Problema de Datos Antes de Ser un Problema de IA

Un pago duplicado casi nunca parece un duplicado.

El 3 de marzo, cuentas por pagar liquida la factura F-00412 de Distribuidora del Norte, S.A. Tres semanas después llega la factura 412 de Distribuidora Del Norte SA, registrada bajo otro número de proveedor que alguien de compras dio de alta porque no encontró el original en el buscador del ERP. Mismo monto, mismo concepto. El sistema no ve nada raro: para él son dos proveedores distintos con dos facturas distintas. Se pagan las dos.

Hoy casi cualquier proveedor de software de cuentas por pagar ofrece "detección de duplicados con IA". Antes de evaluar esa promesa, conviene hacerse una pregunta mucho menos glamorosa: ¿cuántas veces existe cada uno de tus proveedores en tu maestro? La respuesta a esa pregunta determina, más que cualquier modelo, cuántos duplicados vas a detectar.

1. Cómo ocurren realmente los pagos duplicados

La mayoría de los pagos duplicados no son fraude. Son fallas de proceso y de datos que se repiten con patrones muy reconocibles:

• La misma factura capturada dos veces con formato distinto: F-00412, F412 y 412 son tres textos diferentes para el ERP.
• El proveedor existe dos o tres veces en el maestro: variantes de razón social, altas hechas por áreas distintas, migraciones de sistema que nunca se depuraron.
• Reenvíos tratados como facturas nuevas: el proveedor manda un recordatorio, un estado de cuenta o una copia "por si no les llegó", y alguien lo registra.
• Dos canales de pago: una transferencia desde CxP y, en paralelo, un cargo a tarjeta corporativa o un reembolso de gastos por el mismo servicio.
• Operación multiempresa: la factura llega a la subsidiaria A y también a la B, y cada una la paga.
• Factura cancelada y sustituida: la sustitución genera un UUID nuevo para la misma operación comercial. Si no se vincula la relación entre comprobantes, el sistema ve dos facturas válidas.
• Pagos urgentes fuera del flujo: el proveedor amenaza con detener entregas, se paga por fuera "y luego lo registramos", y la factura original sigue su curso normal.

Fíjate en algo: casi todos estos patrones rompen el mismo supuesto. El supuesto de que el sistema sabe cuándo dos registros son el mismo proveedor.

2. Cómo funciona la detección, capa por capa

Una detección de duplicados bien diseñada no es una sola regla ni un solo modelo. Es una pila de capas, cada una más costosa y más ruidosa que la anterior, que intenta capturar lo que se escapó de la de arriba:

Prevención antes del pago vs. recuperación después

Todas estas capas pueden correr en dos momentos: antes de liberar el pago o en una revisión posterior. La diferencia operativa es enorme. Detener un duplicado antes de pagar cuesta minutos de revisión. Recuperarlo después implica pedirle al proveedor que devuelva dinero, esperar una nota de crédito y, a veces, tensionar una relación comercial. Las auditorías de recuperación tienen su lugar, pero son la red de seguridad, no el control principal.

Qué capa detecta qué

3. Por qué todo depende del maestro de proveedores

Hay una razón técnica por la que la columna de la derecha dice "sí" casi siempre. Comparar cada factura contra todas las demás genera una cantidad inmanejable de coincidencias falsas: miles de proveedores cobran montos redondos parecidos. Por eso prácticamente todos los motores de detección usan el proveedor como llave de partición: comparan facturas dentro del mismo proveedor, o dentro de un grupo de proveedores que el sistema sabe que están relacionados.

Si tu proveedor existe tres veces, esa comparación nunca ocurre. No porque el algoritmo sea malo, sino porque le dijiste que eran tres empresas distintas.

Los defectos típicos de un maestro de proveedores en una empresa mediana son siempre los mismos:

• Registros duplicados con variantes de razón social, abreviaturas o tipo de sociedad.
• ID fiscal vacío, mal registrado o genérico (el ID Fiscal genérico XAXX010101000 usado para "proveedores de una sola vez" que se vuelven recurrentes).
• La misma cuenta bancaria registrada en dos proveedores "distintos": una señal de duplicado o, peor, de fraude.
• Proveedores inactivos que nunca se bloquearon y siguen disponibles para recibir facturas.
• Cuentas comodín tipo "Proveedores varios" donde nadie puede comparar nada.
• Altas que cualquiera puede hacer, sin verificación de existencia previa.

"Un sistema de detección de duplicados es tan bueno como su definición de 'el mismo proveedor'. Y esa definición vive en tu maestro, no en el modelo."

4. Qué pasa cuando apuntas IA a un maestro sucio

Aquí es donde la promesa de la IA se vuelve peligrosa, no porque los modelos sean malos, sino porque son buenos para sonar razonables. Con datos maestros defectuosos aparecen tres modos de falla:

Falsos negativos con justificación incluida

El modelo analiza las dos facturas de nuestro ejemplo y concluye: "No se trata de un duplicado: las facturas pertenecen a proveedores distintos (ID 20418 e ID 31877) y tienen números de folio diferentes." El razonamiento es impecable. La premisa es falsa. El modelo heredó la premisa de tus datos, y la presentó con una seguridad que desalienta a cualquiera a cuestionarla.

Falsos positivos en masa

Para compensar, se relajan los umbrales: "marca cualquier monto igual en un rango de 30 días". De inmediato aparecen la renta mensual, las igualas de servicios profesionales y los fletes recurrentes de tarifa fija. El equipo recibe doscientas alertas, descubre que casi todas son ruido y aprende a liberarlas en bloque. El duplicado real sale junto con las demás.

El mismo error, a otra velocidad

Un analista de cuentas por pagar procesa unas decenas de facturas al día y, de vez en cuando, tiene esa intuición de "¿no le pagamos esto mismo a este proveedor la semana pasada?". Un modelo procesa miles en minutos y no tiene más memoria que la que le dan los datos. El error de fondo no desaparece: escala, y llega con una explicación bien redactada. Por eso la pregunta de quién define los umbrales y quién revisa las excepciones es tan importante, como desarrollamos en quién responde cuando un agente de IA se equivoca en finanzas.

5. El orden correcto: datos, luego reglas, luego IA

Esta es la secuencia que recomendamos, en este orden y sin saltarse pasos:

1. Perfila tu maestro antes de comprar nada. Cuatro consultas sencillas te dicen casi todo: proveedores que comparten ID Fiscal; proveedores que comparten cuenta bancaria; razones sociales que coinciden después de normalizarlas (sin "S.A. o S.R.L.", sin puntuación, en mayúsculas); y proveedores activos sin movimientos en los últimos 18 meses.
2. Consolida y bloquea. Define un registro maestro por entidad, reasigna el historial y bloquea los duplicados en lugar de borrarlos, para conservar la trazabilidad. Asigna un dueño del maestro con nombre y apellido.
3. Gobierna el alta de proveedores. ID Fiscal obligatorio y validado, búsqueda por identificación fiscal y cuenta bancaria antes de crear un registro, segregación de funciones (quien da de alta proveedores no aprueba pagos) y verificación independiente de cualquier cambio de cuenta bancaria. Estos son los controles que un auditor espera ver, como explicamos en lo que el cumplimiento SOX exige a un proceso automatizado.
4. Normaliza en la captura. Extrae el número de factura de forma consistente y guarda el UUID del CFDI como campo clave. En México, el UUID es probablemente la mejor llave antiduplicados que existe, siempre que se capture y se respete la relación de sustitución.
5. Reglas deterministas primero, IA para el residuo. Las capas 01 y 02 son baratas, explicables y auditables. La coincidencia difusa con IA debe trabajar sobre lo que queda, con una persona revisando cada alerta y una bitácora de por qué se liberó o se detuvo.
6. Mide lo que importa. Tasa de proveedores duplicados en el maestro, precisión de las alertas (qué porcentaje resultó ser un duplicado real), montos detenidos antes del pago frente a montos recuperados después, y tiempo promedio de resolución.

6. Dónde la IA sí se gana su lugar

Nada de lo anterior significa que la IA sobre. Significa que tiene un trabajo específico, y es valioso:

• Extraer datos de documentos heterogéneos —PDF, XML, correos— para que el número de factura y el UUID lleguen siempre en el mismo formato. Lo detallamos en qué puede y qué no puede reemplazar un agente de IA en la captura de datos.
• Proponer candidatos de fusión de proveedores comparando nombres, domicilios y cuentas, para que una persona confirme. Es decir: usar la IA para limpiar el maestro, no para ignorarlo.
• Reconocer documentos que no son facturas: recordatorios, estados de cuenta, proformas y reenvíos.
• Explicar cada alerta con evidencia —las dos facturas, la cuenta bancaria compartida, el historial— para que quien revisa decida en un minuto en lugar de en quince.

La IA es un amplificador. Sobre un maestro limpio, amplifica la capacidad de tu equipo para detectar lo que las reglas no ven. Sobre un maestro sucio, amplifica el error y le pone una narrativa convincente encima.

Antes de la próxima demostración

Si estás evaluando una herramienta de detección de duplicados, corre primero las cuatro consultas del paso 1 sobre tu maestro de proveedores. Si encuentras proveedores que comparten ID Fiscal o cuenta bancaria, ya sabes dónde está tu exposición real, y ya sabes que ningún modelo la va a cerrar por sí solo. Empieza por ahí: es un proyecto acotado, con dueño claro y resultado medible, exactamente el tipo de primer paso que defendemos en cómo empezar en pequeño con automatización.

Si quieres comparar notas sobre lo que encuentres, escríbeme.