Worldwide Express encargó las facturas en disputa a agentes de IA y redujo su deuda un 75%

Worldwide Express, un bróker estadounidense de transporte de mercancías con una facturación de unos $5000 millones al año, 130 000 clientes y 75 transportistas de carga fraccionada (LTL, cuando en un mismo camión viajan envíos de varios clientes a la vez), ha encargado la resolución de las facturas en disputa a agentes de IA. El problema era muy terrenal. Alrededor del 14% de las facturas de los transportistas no supera la «conciliación a tres bandas»: la factura debe coincidir con el pedido y con el acuse de recibo de la mercancía.

Cada una de esas facturas se convierte en una disputa, y mientras la disputa sigue abierta, el dinero queda parado. En esas «excepciones» la compañía tenía atascados unos $15 millones de flujo de caja libre. Con la ayuda de AWS y del integrador LTM, construyó un sistema multiagente sobre Amazon Bedrock e integrado en su sistema de gestión de transporte, SpeedShip.

Seis meses después, el volumen de disputas abiertas bajó a $4 millones.

Por qué las facturas de los transportistas no cuadran

Las disputas se dividen en tres tipos:

• Discrepancias por líneas. La cantidad o el código de servicio de la factura no coincide con el registro del envío.
• Desviaciones de precio. El transportista aplicó una tarifa distinta de la pactada en el contrato.
• Cargos adicionales inesperados. Plataforma elevadora, entrega en domicilio residencial, recálculo del peso. Estos cargos no figuraban en el presupuesto inicial.

Antes, cada caso seguía cinco pasos: determinar el tipo, buscar la causa en los registros del proveedor, escribir al transportista o al almacén, esperar la respuesta y registrar la decisión en el sistema. El trabajo lo hacía un departamento externalizado, caso por caso y con llamadas telefónicas. Cada transportista tiene sus propias tarifas y su propio procedimiento de disputas, así que el departamento de operaciones financieras (FinOps) se ahogaba en la rutina.

La automatización robótica de procesos (RPA) no sirve aquí: funciona bien con escenarios rígidos. En este caso hay que leer la política del transportista, contrastar el cargo con lo que ocurrió en la entrega y decidir si es legítimo para ese importe. Es un trabajo de texto y contexto, y por eso se eligieron agentes basados en modelos de lenguaje.

Tres agentes y una base de reglas por cada transportista

Cada disputa llega a uno de tres agentes especializados:

• Invoice Matching Agent localiza el registro del envío al que corresponde la factura y señala qué no cuadra.
• Pricing Variance Agent compara el precio facturado con el contractual y decide si la diferencia está justificada.
• Accessorial Validation Agent comprueba si los cargos adicionales se corresponden con eventos reales de la entrega: si hubo plataforma elevadora, si la dirección era residencial.

Cada agente dispone de una instrucción (rol, límites de decisión, formato de respuesta), de un conjunto de acciones en SpeedShip y de acceso a una base de conocimiento. Esa base contiene las reglas tarifarias, las definiciones de los cargos, el procedimiento de disputas y los umbrales de desviación admisibles de cada transportista. Antes de decidir, el agente recupera los documentos de ese transportista en concreto. Por eso los mismos tres agentes trabajan con los más de 40 transportistas conectados, sin escribir código específico para cada uno.

Las decisiones de ingeniería son sensatas. La compañía montó la orquestación por su cuenta en servidores Amazon EC2 con autoescalado, y usa Bedrock solo para invocar los modelos mediante una API única. La lógica de enrutamiento sigue en manos del equipo, y se pueden usar bibliotecas abiertas para agentes. Los agentes acceden a SpeedShip a través de las mismas API que los analistas, de modo que ven las mismas tarifas contractuales, los mismos datos del envío y las mismas confirmaciones de entrega. Tras cada decisión, el sistema redacta una nota comprensible: qué encontró y qué hizo. En disputas que implican dinero, esta explicabilidad es obligatoria.

No se ha eliminado al humano. Al principio, un empleado confirmaba cada recomendación en su interfaz habitual. Cuando la precisión superó el 99%, la confirmación masiva pasó a ser el modo principal. Los rechazos se registran, y el equipo los usa para corregir las instrucciones y las bases de conocimiento. Las métricas de los paneles son: porcentaje de automatización por transportista, errores por tipo de disputa, tiempo de resolución y frecuencia con que el humano anula la recomendación.

Las cifras y qué conviene verificar

Resultados declarados tras seis meses:

• Los agentes cierran unas 10 000 disputas por semana, aproximadamente la mitad del flujo. Menos de un 1% de errores.
• Las disputas sin resolver bajaron de $15 millones (junio de 2025) a $4 millones.
• El plazo para convertir un pedido en dinero se redujo en 4 semanas.
• El ahorro supera $1 millón al año, el retorno declarado en el primer año es de 60 veces y la entrada única de flujo de caja es de $10 millones.

Se trata de una entrada en el blog del propio AWS, y las cifras no terminan de encajar. El porcentaje de automatización aparece como «alrededor del 50%» y como «más del 40%». Los $10 millones se presentan tanto como una liberación única de dinero como un volumen semanal de facturas procesadas más rápido.

La caída de $15 millones a $4 millones es en realidad del 73%, y no exactamente del 75%. No se indica qué modelo hay bajo el capó ni cuánto cuestan las llamadas, aunque la economía del proyecto depende sobre todo de eso. Por lo visto, se cuenta como error lo que rechaza el revisor; los errores que este deja pasar durante la confirmación masiva no entran en esa cifra.

Aun así, el esquema parece trasladable a la logística y a cualquier empresa con un flujo de facturas. Empiece por el tipo de disputa más frecuente y demuestre la precisión con él. Guarde las reglas de las contrapartes como documentos consultables, sin incrustarlas en el código. Deje que el agente use las mismas API que las personas y reserve la confirmación al humano hasta que las métricas muestren una precisión estable. La compañía ya está trasladando el enfoque a otras partes del ciclo «del pedido al pago».