Oracle Fusion Cloud ERP and Coupa integration

What moves between them

The main flow runs from Coupa into Oracle Fusion. Purchase orders approved in Coupa are read by webhook events or polling and matched to Oracle Fusion suppliers. Invoices received against those POs flow into Oracle Fusion as payables, mapped to the matching GL accounts and cost centers. Invoice payments in Coupa update the corresponding Oracle Fusion transactions. Reference data such as suppliers and GL dimensions is synced bidirectionally so procurement matches the chart of accounts and supplier master in Oracle Fusion.

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted and refreshes each token when a call returns 401. On the Coupa side it subscribes to webhook events for purchase orders, invoices, and payments, validating the HMAC signature on arrival, and falls back to polling if webhooks are disabled. On the Oracle Fusion side it polls by filtering on LastUpdateDate since Oracle Fusion publishes no outbound webhooks. Suppliers are looked up in Oracle Fusion before any PO or invoice is posted; if a supplier does not exist, the record is queued for retry. GL accounts are validated by querying Oracle Fusion's chart of accounts, and account combinations are checked where multi-segment accounts are in use. PO line amount, invoice amount, and tax are mapped per the customer's Oracle Fusion tax rules. Because Coupa and Oracle Fusion are both cloud SaaS products, all calls traverse the public internet with HTTPS encryption. ml-connector tracks the OAuth token expiry for each system independently, so token renewal does not create a service gap. Every record carries a full audit trail and can be replayed if a downstream GL posting fails.

A real-world example

A mid-market manufacturing company runs Oracle Fusion Cloud ERP for finance and supply chain, and uses Coupa for procurement across three plants and a procurement center. Before the integration, the AP team received purchase orders from Coupa, manually reviewed them in Oracle Fusion, and logged into both systems to confirm matching. When invoices arrived, they were entered into Oracle Fusion by reference to printed POs or email confirmations from Coupa, creating a high risk of mismatches and duplicate payments. With Oracle Fusion and Coupa connected, approved POs flow in automatically, invoices match to those POs in real time, and the AP team works from a single GL posting queue. Month-end close accelerates because AP reconciliation is pre-verified, and invoice matching eliminates the manual lookup step.

What you can do

• •Sync Coupa purchase orders into Oracle Fusion as procured goods receipts or invoices, matched to suppliers.
• •Post Coupa invoices into Oracle Fusion payables with GL account and cost center validation.
• •Validate suppliers and GL accounts in Oracle Fusion before accepting any Coupa transaction.
• •Consume Coupa webhook events for immediate visibility into PO, invoice, and payment changes, with fallback polling for missed events.
• •Track OAuth token expiry and refresh independently on both systems to prevent authentication outages.

Questions

Which direction does data move between Oracle Fusion and Coupa?

The main flow is Coupa into Oracle Fusion. Purchase orders, invoices, and payments approved in Coupa post into Oracle Fusion's payables and general ledger. Suppliers and GL accounts are synced bidirectionally to ensure Coupa transactions reference valid Oracle Fusion dimensions. Oracle Fusion is the system of record for the GL; Coupa is the system of record for procurement and spend.

How does ml-connector handle the lack of outbound webhooks in Oracle Fusion?

Oracle Fusion publishes no direct webhooks to external systems without Oracle Integration Cloud middleware. ml-connector polls Oracle Fusion on a scheduled cadence, filtering by LastUpdateDate to detect only changed records. Coupa webhooks provide immediate visibility into procurement changes, so ml-connector combines event-driven updates from Coupa with polling from Oracle Fusion for bidirectional reference data.

What happens if a Coupa invoice references a supplier or GL account that does not exist in Oracle Fusion?

ml-connector validates suppliers and GL accounts before posting any invoice. If a supplier or account is missing, the invoice is queued for retry and an audit entry is logged. The customer then adds the supplier or account to Oracle Fusion, and ml-connector automatically replays the queued invoice on the next cycle, eliminating manual recovery steps.