/

Procurement y supply chain.

Requisición desde el celular, factura conciliada sin intervención manual.

El proceso de compras toca seis o siete sistemas: requisitor, e-procurement, ERP, portales de proveedores, recepciones, facturación, pagos. La fragmentación genera demoras, errores y “maverick spending”. Con MuleSoft orquestás el ciclo end-to-end: requisición móvil con aprobación según monto, conversión automática a PO en el ERP, recepción en WMS, 3-way match para conciliar facturas con tolerancias configurables.

Procurement

¿Qué resuelve procurement con MuleSoft?

Cuando el ciclo de compras se distribuye entre Coupa o Ariba, ERP, portales de proveedores y procesos manuales, cualquier mejora puntual queda atada al sistema donde se hace. MuleSoft une el ciclo: la requisición nace en una app móvil, se aprueba con reglas claras, se convierte en PO automáticamente, se concilia con la factura sin toques humanos cuando todo concuerda. El equipo de procurement deja de ser una mesa de tickets y se concentra en sourcing y compliance.

  • Requisición desde móvil con flujo de aprobación según monto, centro de costos y categoría.
  • Conversión automática de PR a PO en SAP / Oracle / NetSuite / Dynamics.
  • 3-way match automático con tolerancias configurables; auto-aprobación cuando todo coincide.
  • Supplier onboarding con validación fiscal (AFIP, SAT, SUNAT) y listas de sanciones.

Sistemas típicos involucrados

Las familias que conviven en un proceso source-to-pay serio.

ERP

Módulos de procurement en SAP MM, Oracle EBS, NetSuite y Microsoft Dynamics 365 F&O. Son el sistema de registro para PR, PO, recepciones y pagos.

E-procurement

SAP Ariba, Coupa, Oracle Procurement Cloud, Jaggaer. Plataformas especializadas para requisición, sourcing, catálogo y supplier collaboration.

Portales de proveedores

Portales custom y EDI con grandes proveedores, marketplaces como Mercado Libre Empresas o Amazon Business cuando el cliente compra ahí también.

Validación fiscal y compliance

AFIP, SAT, SUNAT y equivalentes regionales para validar datos del proveedor. Listas de sanciones y de prevención de lavado para onboarding seguro.

Arquitectura objetivo

Apps por persona, Process APIs por subproceso, System APIs por sistema.

+----------------+ +----------------+ +----------------+
|  Requestor     | | Buyer Portal   | |  Supplier      |
|  Mobile / Web  | | (Coupa/Ariba)  | |   Portal       |
+--------+-------+ +--------+-------+ +--------+-------+
         |                   |                |
         +---------+---------+--------+-------+
                   |                  |
                   v                  v
+-------------------------------------------------------+
|  Experience APIs                                      |
|  (requisitor-mobile-eapi / supplier-portal-eapi /     |
|   procurement-bi-eapi)                                |
+--------------------+----------------------------------+
                     |
                     v
+-------------------------------------------------------+
|  Process APIs                                         |
|  - requisition-pa (req → PO workflow)                 |
|  - po-3way-match-pa (PO + GR + invoice match)         |
|  - supplier-onboarding-pa                              |
|  - catalog-sync-pa                                    |
|  - vendor-master-pa                                   |
+--------+--------+----------+----------+---------+-----+
         |        |          |          |         |
         v        v          v          v         v
+-----------+ +--------+ +--------+ +--------+ +----------+
| sap-mm    | | coupa  | | ariba  | |  tms   | |  wms     |
| sap-fi    | | -sapi  | | -sapi  | |        | |          |
+-----------+ +--------+ +--------+ +--------+ +----------+

System APIs

sap-mm-sapi y sap-fi-sapi para PR, PO, GR e invoices. coupa-sapi y ariba-sapi para requisiciones y catálogos. vendor-master-sapi para vista unificada del proveedor. tms-shipments-sapi para tracking.

Process APIs

requisition-pa orquesta de PR a PO con aprobaciones. po-3way-match-pa concilia PO, recepción y factura. supplier-onboarding-pa incorpora proveedores. catalog-sync-pa propaga cambios de catálogo y precios.

Experience APIs

requisitor-mobile-eapi y approver-mobile-eapi para empleados y aprobadores en el celular. supplier-portal-eapi para autoservicio del proveedor. procurement-dashboard-eapi para BI real-time.

Flujo paso a paso

Requisición end-to-end desde la app móvil hasta el pago al proveedor.

  1. 1 Un empleado abre la app de procurement en su celular y busca un producto. La Experience API requisitor-mobile-eapi traduce la búsqueda a una consulta consolidada.
  2. 2 La Process API catalog-search-pa consulta el catálogo de Coupa o Ariba más los catálogos PunchOut de proveedores conectados. El resultado vuelve unificado al móvil.
  3. 3 El empleado selecciona el producto, ingresa cantidad, justificación y centro de costos. Submit. La Experience API recibe el POST y delega en requisition-pa.
  4. 4 requisition-pa valida: presupuesto disponible (consulta al ERP vía sap-fi-sapi), centro de costos válido, producto en catálogo aprobado.
  5. 5 Determina ruta de aprobación según las reglas configuradas del cliente: monto, centro de costos, categoría y jerarquía. Las reglas viven como configuración, no hardcodeadas.
  6. 6 Crea la requisición en sap-mm-sapi como PR y notifica al aprobador vía push y email con link directo a la app.
  7. 7 El aprobador desde el móvil ve la requisición con todo el contexto, revisa y aprueba. requisition-pa recibe el approval y dispara la conversión.
  8. 8 Crea la PO en SAP vía sap-mm-sapi POST /purchase-orders y envía la PO al proveedor por su canal preferido: email PDF, EDI o portal.
  9. 9 El proveedor envía la mercadería. El WMS escanea recepción y wms-receipts-sapi notifica el evento receipt.recorded al hub.
  10. 10 po-3way-match-pa recibe la factura electrónica vía portal, EDI u OCR de PDF, matchea PO + recepción + factura con tolerancias configuradas. Si concuerdan: auto-aprueba pago en sap-fi-sapi. Si no concuerdan: crea ticket de revisión para el buyer.

Patterns aplicados

Los patrones que sostienen el ciclo source-to-pay en producción.

Workflow orchestration

State machine explícito para la requisición: draft, submitted, approved, po_created, fulfilled, paid. Cada transición auditada y reversible cuando aplica.

Approval routing parametrizable

La matriz de aprobación vive como configuración (tablas, BPM o reglas externas), no en código. Cambia con el negocio sin redeploy.

Idempotent invoicing

El número de factura del proveedor actúa como clave única. Reentregas, retransmisiones EDI o reintentos no generan pagos duplicados.

Master data sync

El maestro de proveedores se sincroniza con consistencia eventual entre ERP, e-procurement y sistema de pagos. Un solo punto de verdad para datos críticos.

Tolerance-based matching

El 3-way match acepta variaciones dentro de tolerancia configurable por cantidad y por precio. Refleja la realidad operativa sin frenar todo por diferencias mínimas.

Wait state para facturas adelantadas

Cuando llega factura antes que recepción, el matcher espera una ventana configurable antes de escalar. Evita ruido operativo en flujos normales.

Cómo lo implementamos

Cinco fases coordinadas con procurement, finanzas y el equipo del ERP del cliente.

1
Discover · 2-3 semanas

Mapeo del proceso source-to-pay

Inventario de sistemas (ERP, e-procurement, portales, EDI), tipos de gasto (direct e indirect), matriz de aprobación, casuística de excepciones, integraciones fiscales obligatorias del país. Identificación de los primeros casos a habilitar.

2
Design · 3-5 semanas

Contratos y reglas configurables

Diseño API-Led con System APIs por sistema y Process APIs por subproceso (requisition, 3-way match, onboarding, catalog sync). Modelo de eventos, plan de master data sync, parametrización de tolerancias y matriz de aprobación.

3
Build · 8-12 semanas

Apps móviles y procesos automatizados

Implementación de Experience APIs (requisitor, approver, supplier portal, dashboard), Process APIs, System APIs sobre ERP, Coupa o Ariba, validación fiscal, listas de sanciones, tests MUnit con casos reales del cliente.

4
Deploy · 2-4 semanas

Hardening y go-live por categoría

Hardening, security review, validación de tolerancias con finanzas, pruebas de aprobación móvil con managers reales, runbooks. Go-live por categoría de gasto (típicamente indirect primero), con hypercare.

5
Evolve · continuo

Más proveedores y más automatización

Cada proveedor nuevo se onboardea reusando supplier-onboarding-pa. Crece auto-match, baja la intervención manual, se incorporan EDI con grandes proveedores. Managed services y CoE acompañan el crecimiento.

Requisitos del proyecto

Lo que tiene que estar disponible del lado del cliente para arrancar.

Datos mínimos

Acceso al ERP (SAP MM y FI, Oracle EBS, NetSuite, Dynamics F&O) y al e-procurement (Ariba, Coupa, Oracle Procurement Cloud). Catálogo vigente, matriz de aprobación, lista de proveedores activos.

Licencias y capacidades

Anypoint Platform, conector SAP, conectores específicos de Coupa o Ariba según aplique, módulo de eventos cuando se publican cambios, accesos a APIs fiscales del país y a listas de sanciones.

Integraciones típicas

WMS y TMS para recepciones y tracking, sistemas de pagos a proveedores, EDI con grandes proveedores, BI corporativo y dashboards para procurement, sistemas de planeación cuando aplica.

Pre-requisitos organizacionales

IT lead, sponsor de procurement (CPO o gerencia de compras), referente de finanzas para definir tolerancias y políticas, dueño del master de proveedores, equipo del ERP comprometido.

KPIs operativos

Las métricas que típicamente mejoran tras automatizar el ciclo source-to-pay.

KPIQué midePor qué importa
Requisition to PO cycle timeTiempo desde que el empleado submitea la requisición hasta que existe PO en SAP.Refleja la fricción real del proceso. Con app móvil y reglas claras debería medirse en horas, no días.
Auto-match ratePorcentaje de facturas que auto-aprueban en el 3-way match sin intervención del buyer.Indicador directo de eficiencia del proceso de pagos y de calidad del master data.
Approval lead timeTiempo promedio que tarda un aprobador en decidir desde que recibe la notificación.Diagnostica si la fricción está en el manager (móvil ayuda) o en la configuración de ruteo.
Supplier lead timeTiempo promedio del proveedor desde recepción de la PO hasta entrega de mercadería.Métrica de salud del supply base, insumo para decisiones de sourcing y planeación.
Maverick spendingPorcentaje de gasto fuera de catálogo aprobado o fuera de los proveedores preferentes.Métrica de negocio clave: cuanto más bajo, mayor el ahorro acumulado del programa de procurement.
Contract compliancePorcentaje de PO que respetan los precios y condiciones del contrato vigente.Asegura que las negociaciones del equipo de procurement se materialicen en pagos reales.

Time-to-value: primer subproceso en producción (típicamente requisición móvil + aprobación) tras 12 a 16 semanas, con métricas observables a las 4 semanas siguientes.

Cómo se mide: dashboard sobre Anypoint Monitoring por Process API, integrado con Splunk, Datadog o Grafana cuando ya existe ese stack del lado del cliente, más KPIs de negocio compartidos con procurement y finanzas.

Preguntas frecuentes

Aplica especialmente. Coupa y Ariba ofrecen integración nativa con SAP, Oracle y Dynamics, pero la realidad es que casi siempre quedan integraciones complementarias: sistemas legacy, portales custom, EDI con grandes proveedores, validaciones fiscales LATAM, sistemas custom de planeación. MuleSoft entra ahí, sumando capacidades sin competir con la plataforma central.

Sí, con criterios distintos. Indirect spend (suministros, servicios, IT) suele entrar primero porque el catálogo es más estable y la matriz de aprobación más clara. Direct spend (materia prima, insumos productivos) requiere integración más profunda con MRP, planeación de demanda y contratos master, y suele ir en una fase posterior con foco en reducir lead times y stock buffer.

Las tolerancias del 3-way match son configurables por categoría y por proveedor. Tolerancias típicas son del orden de pocos puntos porcentuales en cantidad y un punto en precio, ajustadas con finanzas en la fase de design. Cuando hay desvío fuera de tolerancia, el matcher genera ticket para el buyer con todo el contexto (PO, recepción, factura, diferencia detectada) en lugar de bloquear el flujo.

Es uno de los drivers que justifica el proyecto. La Experience API approver-mobile-eapi sirve la requisición con todo el contexto operativo a una app móvil. El manager aprueba o rechaza desde donde esté, con auditoría completa. Para casos críticos, la app permite delegar temporalmente la autoridad respetando la matriz de aprobación configurada.

supplier-onboarding-pa orquesta el alta: validación de datos fiscales (consulta a AFIP, SAT, SUNAT o equivalente), validación contra listas de sanciones y prevención de lavado, creación en el master de SAP, en Coupa o Ariba y en el sistema de pagos, generación de credenciales para el portal del proveedor. Lo que antes era un workflow manual de semanas pasa a días con trazabilidad de cada validación.

Compras automatizadas, sin tickets manuales.

Hablemos de tu stack de procurement y diseñamos juntos el ciclo source-to-pay automatizado.

Ver los 17 casos de uso