Oracle Fusion Cloud ERP and Procurify integration

What moves between them

The main flow runs from Procurify into Oracle Fusion Cloud ERP. Purchase orders and requisitions approved in Procurify are polled every 5-15 minutes and mapped into Oracle Fusion Cloud ERP purchase orders and supplier invoices, tagged with the correct supplier and account code. Bills and payments from Procurify are matched against AP invoices in Oracle Fusion Cloud ERP so both systems track the same payment status. Vendor and GL account master data is aligned in both directions so purchase orders and invoices reference vendors and accounts that already exist in both systems.

How ml-connector handles it

ml-connector stores both OAuth 2.0 credential sets encrypted and refreshes the Oracle Fusion Cloud ERP bearer token when a call returns 401; Procurify tokens are refreshed before expiry. On the Oracle side it accepts the full customer pod URL since each pod has a unique hostname, and on the Procurify side it accepts the customer subdomain and routes accordingly. Because both APIs support time-based polling only, ml-connector polls both on a schedule you control, using LastUpdateDate and po_created_date filters to fetch only changed records since the last run. It maps Procurify purchase order line items to Oracle Fusion Cloud ERP purchase order lines, requisition notes to supplier invoice descriptions, and bill amounts to AP invoices. Vendor matching uses Procurify vendor name and Oracle Fusion Cloud ERP supplier name, with a manual cross-reference for mismatches. If a poll or post fails, ml-connector backs off and retries, and every record is tracked so failed syncs can be replayed without duplication. Payment status flows back from Oracle Fusion Cloud ERP to Procurify so both systems show the current GL posting state.

A real-world example

A mid-market manufacturing company runs Oracle Fusion Cloud ERP for financials and procurement, and uses Procurify for spend management and AP processing across three locations. Before the integration, procurement teams approved purchase requisitions in Procurify, then emailed PO confirmations to finance, who manually created purchase orders in Oracle Fusion Cloud ERP and matched them to incoming supplier invoices by hand. Month-end close required reconciling Procurify's bill register against Oracle Fusion Cloud ERP's AP aging, and discrepancies meant hunting through email threads to find the original PO. With Procurify and Oracle Fusion Cloud ERP connected, each approved requisition automatically becomes a purchase order in Oracle Fusion Cloud ERP, supplier bills are automatically matched to invoices in the GL, and payment status flows back to Procurify so procurement always sees whether finance has posted a payment. The AP reconciliation is complete before month-end begins, and the manual PO re-entry is gone.

What you can do

• •Sync Procurify purchase orders and requisitions into Oracle Fusion Cloud ERP as purchase orders and supplier invoices on a schedule you control.
• •Map vendors, GL accounts, departments, and cost centers between Procurify and Oracle Fusion Cloud ERP so every transaction references accounts that exist in both systems.
• •Authenticate Procurify with OAuth 2.0 client credentials and Oracle Fusion Cloud ERP with pod-specific OAuth 2.0 tokens, handling token refresh automatically.
• •Poll both APIs with time-based filters to fetch only changed records and avoid duplicate entries or missed updates.
• •Track every sync state and enable replay of failed records so payment posts and PO updates do not fall out of sync.

Questions

Which direction does data move between Oracle Fusion Cloud ERP and Procurify?

The main flow is Procurify into Oracle Fusion Cloud ERP. Purchase orders, requisitions, and bills move from Procurify into Oracle Fusion Cloud ERP as purchase orders and supplier invoices. Vendors, GL accounts, and departments are kept in sync in both directions. Payment status flows back from Oracle Fusion Cloud ERP to Procurify so both systems see the current AP posting state.

How does ml-connector handle Oracle Fusion Cloud ERP's unique pod URLs?

Each Oracle Fusion Cloud ERP customer runs on a dedicated pod with a unique https://{pod}.fa.{region}.oraclecloud.com URL. ml-connector stores the full pod URL per customer and routes all API calls to that instance, so there is no shared hostname to discover. OAuth 2.0 credentials are tied to each pod's OCI Identity Domain.

Do Procurify and Oracle Fusion Cloud ERP support webhooks, or does ml-connector need to poll?

Neither Procurify nor Oracle Fusion Cloud ERP supports direct outbound webhooks for external connectors. ml-connector polls both APIs on a schedule you control, using LastUpdateDate and po_created_date filters to fetch only records that have changed since the last run, keeping API load low and sync latency predictable.