Fuzzy matching pedidos y facturas: cómo funciona

ininvoice — El fuzzy matching cruza factura, pedido y albarán cuando los datos no coinciden exactamente: número de PO mal copiado, nombre del proveedor variante, fecha distinta o importe ligeramente desviado. Combina algoritmos clásicos como distancia de Levenshtein, n-grams y weighted fields sobre proveedor, fecha, importe y descripción de línea. Si la confianza supera un umbral (típicamente 90%) confirma automático; entre 70-90% pide humano; por debajo, descarta. Así conviertes en touchless facturas que el matching exacto rechaza.

El matching exacto es fácil de explicar y fácil de fallar. Si la factura trae el número de PO bien escrito, el proveedor exactamente como aparece en tu maestro y la fecha que esperabas, todo cuadra. En cuanto un dato baila, el sistema rechaza la factura y un humano la mete a mano.

El fuzzy matching es lo que separa un AP que captura el 30% de facturas en automático de uno que llega al 80%. Este artículo explica cómo funciona, qué algoritmos clásicos hay detrás y dónde poner el umbral entre confirmar automático y pedir humano.

Qué es el fuzzy matching

Fuzzy matching (o "matching difuso", o "matching aproximado") es la técnica que decide si dos registros se refieren al mismo objeto cuando los campos no coinciden carácter por carácter. Nace en bibliotecnomia y record linkage en los años 60 y hoy es estándar en cualquier sistema que cruce datos sucios.

En cuentas a pagar lo aplicamos a tres preguntas:

¿Esta factura corresponde a este pedido aunque el número de PO no aparezca o aparezca mal?
¿Este albarán corresponde a esta línea de pedido aunque la descripción varíe?
¿Este proveedor del email es el mismo "Distribuciones García SL" del maestro aunque venga como "DISTRIB GARCIA, S.L."?

El sistema no decide solo. Calcula una puntuación de similitud entre 0 y 1 (o 0% y 100%) y compara contra umbrales. Por encima del umbral alto, confirma. Por debajo del bajo, descarta. En medio, escala a humano.

Por qué importa en AP

El matching exacto asume que tus datos son perfectos. La realidad es que recibes facturas en PDF escaneado, proveedores que escriben tu nombre de tres maneras distintas, comerciales que copian el número de PO con un dígito cambiado y fechas de factura que no son la fecha real del servicio.

Las cifras de Ardent Partners y otras encuestas de mid-market apuntan a que más del 30% de facturas tienen alguna discrepancia menor con el pedido o el albarán. Si las rechazas todas, tu equipo nunca sale del modo manual. Si las pagas a ciegas, dejas la puerta abierta a errores y fraude. El fuzzy matching es el camino del medio.

Casos típicos donde el fuzzy salva el día

Los cinco escenarios que copan las excepciones reales:

Factura sin número de PO. El proveedor no lo incluye o el comercial nunca lo solicitó. Hay que reconstruir el vínculo a través de proveedor + fecha + importe + descripción de línea.
Número de PO mal copiado. "PO-2026-001847" en factura, "PO-2026-001874" en pedido. Una transposición. Distancia de edición pequeña, similitud alta.
Nombre de proveedor variante. "Distribuciones García SL" vs "DISTRIB GARCIA SL" vs "García Distribuciones". El humano ve que es el mismo en un segundo; el matching exacto no.
Fecha distinta. Pedido emitido el 5 de marzo, factura con fecha 28 de marzo correspondiente al servicio. Dentro de una ventana razonable, el match debería sostenerse.
Importe ligeramente distinto. Pedido 1.200€, factura 1.215€. La diferencia está dentro de tolerancia y la combinación proveedor + fecha + descripción confirma el vínculo.

Ninguno de estos casos es excepcional. En conjunto suelen ser la mayoría de las facturas que un sistema rígido marca como "no match".

Algoritmos detrás del fuzzy matching

No hay un algoritmo único. Lo habitual es combinar varios clásicos según el tipo de campo:

Distancia de Levenshtein. Cuenta el mínimo de inserciones, borrados y sustituciones de caracteres para convertir una cadena en otra. Buena para números de PO, códigos de artículo y errores tipográficos cortos. Una distancia de 1 en un PO de 12 caracteres es similitud altisíma.
N-grams (bigrams, trigrams). Trocea cadenas en secuencias de 2 o 3 caracteres y calcula el solapamiento. Muy útil para nombres de proveedor con palabras reordenadas o abreviadas. "DISTRIB GARCIA" y "Distribuciones García" comparten muchos trigramas.
Jaro-Winkler. Variante orientada a nombres propios cortos que penaliza menos cuando el inicio coincide. Buena para apellidos y razones sociales.
Cosine similarity sobre embeddings o TF-IDF. Para descripciones de línea ("Toner HP CF410A negro" vs "HP 410A Tóner"). Convierte texto en vectores numéricos y mide el ángulo entre ellos.
Fuzzy hashing. Genera hashes resistentes a pequeñas modificaciones, útil para detectar documentos casi idénticos en deduplicación.
Weighted fields. No es un algoritmo individual, es la combinación: cada campo aporta su similitud parcial multiplicada por un peso. Proveedor pesa más que fecha, fecha más que un campo opcional.

La biblioteca thefuzz (antiguo fuzzywuzzy) en Python o Elasticsearch fuzzy queries son referencias estándar para implementar estos algoritmos sin reinventarlos.

Campos clave en una factura: proveedor, fecha, importe, descripción

El fuzzy match real combina varios campos. Cada uno aporta evidencia parcial y el resultado es la puntuación agregada:

Campo	Algoritmo típico	Peso sugerido
Proveedor (razón social, NIF/VAT)	N-grams + normalización	40%
Fecha (con ventana)	Distancia en días ± tolerancia	15%
Importe total	Diferencia absoluta ± tolerancia	20%
Descripción línea	Cosine / n-grams	25%

El NIF o VAT del proveedor es oro: si coincide exactamente, te ahorras dudas sobre la razón social. Por eso muchos sistemas dan peso máximo al identificador fiscal cuando está presente y caen al fuzzy del nombre solo si falta. Los pesos no son sagrados: hay que calibrarlos con tu mix de proveedores.

Umbral de confianza: cuándo confirma automático vs pide humano

Tres tramos. Una decisión por cada uno:

Score > 90%. Match automático. La factura entra al flujo touchless y se pasa a three-way matching línea a línea contra ese pedido y albarán.
Score 70-90%. Match con revisión humana. El sistema propone el pedido más probable y un humano confirma con un clic. Suele ser el 20-30% de facturas en empresas con datos sucios.
Score < 70%. Sin match. La factura va al inbox de excepciones para investigación: posiblemente no hay pedido, está mal codificado o es un proveedor nuevo.

Los umbrales no son universales. Para compras críticas conviene subirlos (95% para auto). Para gasto recurrente y de bajo riesgo, el 85% es razonable. Lo importante es que el rango medio (revisión humana) sea estrecho: si el grueso de tus facturas cae en zona gris, tu equipo sigue trabajando a mano.

Falsos positivos y falsos negativos

Cualquier sistema fuzzy se equivoca. La pregunta es en qué dirección.

Falso positivo. El sistema declara match cuando no lo hay. La factura se asocia al pedido equivocado y, si pasa todos los filtros, puede aprobar un pago indebido. Coste alto.
Falso negativo. El sistema dice "no hay match" cuando sí lo hay. La factura va a excepción y un humano la cuadra. Coste bajo.

En AP siempre se prefiere falsear hacia el lado conservador: más falsos negativos, más revisiones humanas, menos pagos erróneos. Por eso los umbrales de auto-match se ponen altos (90%+) y la zona de duda se gestiona con humano. El three-way matching línea a línea posterior actúa como red de seguridad: aunque el vínculo factura-pedido sea correcto, las cantidades y precios tienen que cuadrar para autorizar pago.

¿Cuántas de tus facturas pasarían touchless con fuzzy matching hoy?

ininvoice cruza proveedor, fecha, importe y descripción con umbrales calibrables y separa la zona gris para revisión humana. Reserva tu plaza y mide el lift sobre tu volumen real.

Cómo ininvoice aplica el fuzzy matching

El cálculo de similitud es la parte fácil. Lo difícil es tener proveedor, fecha, importe y descripciones limpias en factura, pedido y albarán a la vez. ininvoice lo resuelve en cadena:

Ingesta automática desde Gmail u Outlook sin reenvíos manuales.
Lectura estructurada de PDF, XML y FacturaE: prioriza el dato firmado sobre el reconocimiento de píxeles.
Normalización de nombres de proveedor (mayúsculas, sufijos legales, acentos) antes de aplicar n-grams.
Fuzzy match factura ↔ pedido con weighted fields y umbrales configurables.
Three-way matching línea a línea una vez confirmado el vínculo, con tolerancia 2% / 1,50€ OR-mode.
Inbox de excepciones ordenado por probabilidad: el humano resuelve los casos dudosos en orden de mayor a menor confianza.

Flujo completo en three-way matching, touchless accounts payable y conciliación de facturas y albaranes.

Checklist para mejorar tu matching rate

Limpia el maestro de proveedores. Una razón social por NIF, sufijos legales normalizados, alias agrupados.
Exige NIF/VAT en facturas. El identificador fiscal acaba con la mitad del fuzzy de proveedor.
Pide número de PO al proveedor. Aunque tengas fuzzy, un PO bien copiado es match exacto y no consume revisión humana.
Calibra los umbrales con tu histórico. Mira un mes de facturas, etiqueta match real / no match y ajusta hasta que la zona gris sea mínima.
Mide tasa de auto-match. Es el indicador real de touchless. Si está por debajo del 60%, hay margen.
Revisa falsos positivos cada mes. Si aparecen, sube umbrales o reajusta pesos. Mejor revisar de más que pagar de menos.

Preguntas frecuentes

¿El fuzzy matching es lo mismo que IA?: No. Los algoritmos clásicos (Levenshtein, n-grams, Jaro-Winkler) llevan décadas funcionando sin redes neuronales. Hoy se complementan con embeddings semánticos para descripciones de línea, pero el núcleo del fuzzy en AP sigue siendo aritmética de cadenas.
¿Qué pasa si el proveedor cambia su razón social?: El maestro debe registrar el cambio con efecto desde una fecha. Mientras se cruza, las dos versiones cuentan como alias del mismo NIF.
¿Sirve el fuzzy si no tengo pedido formal?: Sin pedido no hay contra qué cruzar para three-way matching. El fuzzy aún sirve para vincular facturas con presupuestos, contratos o histórico de pagos al mismo proveedor, pero el control es más débil.
¿Qué tolerancia de fecha es razonable?: Depende del tipo de compra. Bienes físicos: ventana de 30-60 días entre PO y factura. Servicios recurrentes: el periodo facturado más un margen. Servicios profesionales largos: hasta 90 días o más.
¿Y si dos pedidos abiertos del mismo proveedor compiten por la misma factura?: El sistema escala a humano aunque la mejor opción supere el umbral. Empate o casi empate de candidatos = revisión humana obligatoria. Es un caso donde el fuzzy debe ser conservador por diseño.
¿Funciona el fuzzy en facturas FacturaE o XML estructurados?: Sí, y mejor: los campos llegan ya parseados. La normalización cuesta menos y los umbrales pueden ser más estrictos. El fuzzy se reserva para resolver el vínculo factura-pedido cuando el FacturaE no incluye número de PO.
¿Cuál es una tasa de auto-match decente para empresa mid-market?: Por debajo del 50%, hay datos sucios o umbrales mal calibrados. Entre 60-75% es lo habitual al empezar. Por encima del 80% es objetivo realista tras 2-3 meses de calibración y limpieza de maestros.

Conecta tu correo y mide tu tasa real de auto-match.

30 días de facturas tuyas, fuzzy matching aplicado, línea por línea cuadrada. Reservar plaza.

Tres cosas para recordar

El fuzzy matching combina Levenshtein, n-grams y weighted fields sobre proveedor, fecha, importe y descripción. No es magia: es aritmética de cadenas con umbrales calibrados.
Tres tramos: >90% auto, 70-90% humano, <70% descartar. La zona gris debe ser estrecha. Si no, tu equipo sigue trabajando a mano.
Falsos positivos cuestan caro, falsos negativos cuestan poco. Calibrar conservador y dejar que el three-way matching línea a línea sea la red de seguridad.

Si quieres ver cómo queda esto sobre tus propias facturas, prueba ininvoice. También puedes mirar el precio y las funcionalidades en detalle.

Fuzzy matching en cuentas a pagar: cómo encontrar el pedido sin número exacto