¿Puede la IA comparar ofertas de proveedores sin confundir referencias y unidades?

Un proveedor responde con un PDF que ofrece precio por caja. Otro propone precio por mil unidades y cambia la referencia por un equivalente. Un tercero incluye portes en el total y los otros los dejan fuera. Si se copian tres importes a una tabla, la comparación parece terminada, pero puede llevar a una compra equivocada.

La IA puede acelerar la lectura de ofertas heterogéneas. La decisión fiable exige normalizar lo que se compara y dejar visibles las dudas. El objetivo no es elegir al proveedor con un modelo, sino entregar a compras una comparativa que pueda comprobar y corregir.

Este artículo trata la comparación de ofertas recibidas. Si el problema es preparar presupuestos para clientes, lo desarrollamos en automatizar presupuestos industriales. Si las diferencias aparecen al recibir y facturar, la guía de cotejo de facturas, albaranes y pedidos aborda esa fase posterior.

Antes de extraer datos: definir qué es comparable

Compras debe fijar la solicitud original y los criterios de evaluación. No basta con pedir «el mejor precio». Conviene registrar referencia solicitada, descripción, cantidad, unidad, requisitos técnicos, fecha de entrega, destino, moneda y condiciones obligatorias. Esa base permite distinguir una oferta incompleta de una alternativa válida.

La comparación suele mezclar tres tipos de información:

Tipo	Ejemplo	Tratamiento
Dato literal	Precio de 240 € por caja de 100 unidades	Extraerlo y conservar la página o línea de origen
Dato calculado	2,40 € por unidad antes de portes	Calcularlo con una regla y un factor explícito
Juicio de equivalencia	Referencia alternativa con otra tolerancia	Revisarlo con el responsable técnico o de compras

La IA aporta sobre todo en el primer y el tercer tipo: localizar información en formatos variables y proponer posibles correspondencias. Las conversiones y los criterios de aceptación deben expresarse en reglas comprobables. Microsoft Document Intelligence documenta extracción de campos y tablas de documentos. Esa capacidad no decide por sí sola si dos productos son técnicamente equivalentes.

Un ejemplo de comparación que debe detenerse

Imaginemos una solicitud ficticia de 1.000 piezas de una referencia industrial R-40. El proveedor A ofrece cajas de 100 piezas a 240 € por caja. El proveedor B ofrece 1.000 piezas a 2.250 €, pero indica una aleación alternativa. El proveedor C ofrece 2,30 € por pieza y cobra el transporte por separado. Son cifras inventadas para mostrar el proceso, no precios de mercado.

La tabla no debería destacar a B como ganador por 2.250 € frente a 2.400 €. Primero hay que verificar la aleación alternativa. Tampoco puede declarar que C es más barato que A si faltan los portes y el destino. Un buen resultado inicial mostraría a A con 2,40 €/pieza, a B con 2,25 €/pieza y la equivalencia técnica pendiente, y a C con 2,30 €/pieza y el coste puesto en destino pendiente.

La diferencia entre un sistema útil y una tabla vistosa está en mostrar qué dato falta para decidir. El revisor debe abrir el párrafo o la línea original de cada oferta, no confiar en un resumen sin procedencia.

Del correo a una comparativa revisable

El flujo puede empezar en un buzón o en una carpeta de licitación, pero necesita asociar cada respuesta a una solicitud concreta. El asunto de un correo no siempre identifica el expediente. Pueden llegar revisiones, anexos y ofertas para varias líneas. Hay que conservar remitente, fecha, adjuntos y versión.

Después se clasifica el documento y se extraen las líneas relevantes: descripción, referencia del proveedor, cantidad, unidad, precio, moneda, descuentos, plazo, portes y validez. Cada valor debe guardar su fuente. Si hay tablas partidas entre páginas o condiciones en notas al pie, la muestra de prueba debe incluirlas. La documentación de modelos de extracción de Microsoft explica que se pueden recuperar tablas y puntuaciones por fila y celda. Esas puntuaciones ayudan a dirigir la revisión, pero no sustituyen las comprobaciones comerciales.

La normalización viene después. Una regla calcula precios comparables solo cuando conoce el factor de conversión, la moneda y el alcance del coste. Un catálogo maestro ayuda a vincular referencias. Una similitud de texto puede proponer candidatos, pero no debe cambiar silenciosamente una pieza por otra.

Por último, la herramienta presenta una matriz con tres estados posibles por criterio: comparable, discrepante o pendiente. Compras valida las alternativas, registra por qué descarta una oferta y aprueba la decisión. La adjudicación y el pedido se realizan en los sistemas y permisos definidos por la empresa.

Qué debe quedar fuera de la decisión automática

Los plazos prometidos, certificaciones, condiciones de pago, garantías y riesgo de suministro pueden pesar más que una diferencia pequeña de precio. Si el equipo no ha definido una ponderación, el modelo no debería inventarla. Un campo «precio total» tampoco demuestra que incluya impuestos, embalaje o transporte.

El sistema debe resistir cambios de versión: si el proveedor manda una corrección, la comparación anterior pasa a estar pendiente y se resaltan las filas afectadas. Si una oferta llega después del cierre, el equipo decide si entra en el proceso. La IA puede detectar el cambio. Las reglas de compras gobiernan su efecto.

Aclarar antes de puntuar

Una comparativa puede generar una lista de aclaraciones por proveedor. Debe evitar preguntas que ya estén respondidas en un anexo y agrupar las pendientes por oferta: equivalencia de referencia, plazo, embalaje, condición de entrega y vigencia. El comprador revisa el borrador y decide qué enviar. No todas las preguntas tienen la misma prioridad ni conviene pedir información que el proveedor no necesita aportar para esta compra.

Cuando llega una contestación, el flujo la vincula a la oferta y marca qué celdas pueden actualizarse. No se debe aceptar una nueva cifra por aparecer en un correo si contradice el PDF formal y el equipo exige una oferta revisada. Esa política es propia de compras. La automatización debe reflejarla, no inventarla.

Antes de introducir una puntuación compuesta, comprobaría que cada requisito excluyente se evalúa por separado. Un plazo incumplido no queda compensado por un precio excelente si el material debe entrar en producción antes de una fecha fija. La IA puede redactar una explicación de la matriz. La lógica de selección debe ser visible y reproducible.

La solicitud de oferta también necesita estructura

La comparación empieza antes de que el proveedor responda. Si cada comprador pide los datos de una forma distinta, el sistema tendrá que adivinar qué significa «entrega rápida» o si el precio debe incluir transporte. Una solicitud estructurada reduce ese margen de interpretación: identifica las piezas, cantidades, destinos, fecha necesaria, requisitos técnicos y condiciones que el proveedor debe confirmar. Se puede seguir admitiendo un PDF libre, pero se sabe qué información habrá que buscar en él.

No convertiría la solicitud en un formulario interminable. El criterio práctico es pedir lo necesario para una decisión y distinguirlo de lo deseable. Por ejemplo, una tolerancia dimensional puede ser obligatoria para que la pieza entre en máquina. Un plazo más corto puede ser una ventaja, pero no invalida automáticamente una oferta. Esta distinción permite que la comparativa marque incumplimientos reales en vez de tratar cada celda vacía como un fracaso.

La solicitud también debería tener un identificador estable y una versión. Si compras cambia la cantidad de 500 a 800 unidades después de recibir la primera oferta, comparar la respuesta inicial con las nuevas sin avisar al proveedor sería injusto y confuso. El expediente debe mostrar qué versión de la solicitud contestó cada uno y si necesita una actualización. La IA puede reconocer la referencia en el correo. El control de versiones debe vivir en el proceso de compras.

En compras repetidas, los datos maestros son una ventaja. Una tabla de referencias propias, equivalencias aprobadas y unidades habituales evita revisar desde cero cada línea. Pero las equivalencias deben tener fecha y alcance: una sustitución admitida para un prototipo no tiene por qué servir en producción. Cuando no exista una relación aprobada, la propuesta del modelo queda como candidato, no como sustitución definitiva.

Comprobar el coste comparable sin esconder condiciones

Un cálculo útil necesita una fórmula explícita. Para cada oferta, compras puede querer coste puesto en planta por unidad aceptada, no solo precio de línea. El cálculo puede incluir embalaje, transporte y descuentos aplicables a esa cantidad. Debe quedar claro si impuestos, seguros u otros costes quedan dentro o fuera. Dos importes son comparables únicamente cuando cubren el mismo alcance.

En el ejemplo anterior, si A cuesta 2,40 € por pieza y B cuesta 2,25 €, la diferencia parece de 0,15 €. Pero si B exige un pedido mínimo de 2.000 piezas, la necesidad de 1.000 no puede representarse con la misma columna sin mostrar el sobrestock. La comparativa debe mostrar cantidad comprada, cantidad requerida y coste de las unidades adicionales. No corresponde al modelo decidir que ese inventario compensa.

El plazo merece un tratamiento parecido. «Tres semanas» puede empezar desde la recepción del pedido, la aprobación de planos o el pago de un anticipo. Compararlo con «entrega el 15 de octubre» requiere aclarar el punto de partida. Una fecha calculada a partir de una suposición debería etiquetarse como estimación. Si afecta una parada de producción, la pregunta al proveedor vale más que una cifra aparentemente precisa.

El sistema debe permitir comparar por escenarios sin reescribir los datos de origen: compra completa a A, reparto entre A y C, aceptación de la alternativa de B si técnica la valida. Cada escenario utiliza las mismas ofertas, con decisiones visibles. Esto ayuda a compras a explorar opciones sin presentar el resultado de una simulación como adjudicación aprobada.

Diseñar una revisión que el comprador pueda terminar

Una pantalla de revisión no debería pedir que se abran tres PDFs y se vuelva a hacer el trabajo manual. Presentaría una línea normalizada junto al fragmento original, el cálculo y la razón del estado. Si la conversión de caja a unidad se apoya en «100 unidades por caja», el revisor debe ver ese factor, su origen y la operación aplicada. Corregirlo una vez debería recalcular solo las celdas dependientes.

Conviene ordenar las excepciones por efecto. Una moneda ilegible o una referencia no equivalente puede cambiar toda la adjudicación. Una observación menor del embalaje quizá solo deba registrarse. La prioridad no se basa únicamente en la confianza declarada por el modelo. Se combina la incertidumbre con el impacto de equivocarse. Esta es una regla del flujo, no una afirmación estadística sobre el modelo.

Las correcciones humanas son información valiosa para el proceso. Si un proveedor utiliza siempre «paquete» para una unidad comercial concreta, puede añadirse una regla o un mapeo aprobado. Si el formato cambia, esa regla debe revisarse. La automatización madura cuando reduce excepciones repetidas sin ocultar nuevas. No necesita entrenar de nuevo un modelo cada vez que se corrige una línea. A menudo basta con mantener los datos maestros.

La salida final debe identificar quién revisó cada excepción y cuándo. No basta con guardar un PDF exportado de la tabla. Si se adjudica y después cambia una oferta, interesa saber con qué versión se tomó la decisión y qué condiciones se aceptaron. Esa trazabilidad facilita el siguiente paso: emitir el pedido y comprobar luego su cumplimiento.

Evaluar alternativas de implementación

Si las ofertas llegan en un formato acordado y el equipo compara pocas líneas, puede bastar una hoja compartida bien diseñada. Si el volumen es alto y los PDFs cambian, una herramienta de extracción documental puede ahorrar lectura. Si hay que cruzar catálogo, precios, aprobaciones y ERP, la integración del flujo completo suele importar más que la precisión aislada del extractor.

Compararía estas alternativas con una misma muestra de ofertas y un resultado correcto marcado por compras. Una demostración con documentos fáciles puede mostrar una lectura convincente sin probar las excepciones que consumen tiempo. Por eso la evaluación debería incluir ofertas parciales, condiciones en notas, monedas distintas y al menos una referencia alternativa. La herramienta elegida tiene que permitir corregir y auditar, no solo producir una tabla.

Antes de ampliar el alcance, acordaría una regla de aceptación: ningún dato crítico se incorpora al pedido sin procedencia, ninguna equivalencia no aprobada aparece como válida y las conversiones pueden reconstruirse. El rendimiento del piloto se mide después de cumplir esas condiciones. Reducir minutos a costa de una compra equivocada sería una falsa mejora.

Cómo probarlo sin automatizar una mala decisión

Elegiría una familia de compras repetidas con un número manejable de proveedores. Reuniría ofertas anteriores, incluidas las que tenían anexos, unidades distintas, alternativas y correcciones. Compras marcaría el resultado correcto antes de probar el sistema.

Mediría por separado la exactitud de extracción, las conversiones correctas, las equivalencias que requirieron revisión y el tiempo completo hasta una comparativa aprobada. Un piloto que ahorra lectura pero añade más tiempo de verificación puede necesitar un alcance menor o mejores datos maestros. La meta es que el comprador llegue antes a una decisión respaldada, no que desaparezca de ella.

Si hoy la tabla se construye a mano, el primer avance puede ser definir una comparativa con estados, fuentes y excepciones visibles. Eso permite comprobar que la salida ayuda a decidir antes de automatizar toda la lectura de ofertas.