Oracle Fusion Cloud ERP and Ramp integration

What moves between them

Bills and transactions flow from Ramp into Oracle Fusion Cloud ERP. After each expense is approved or reconciled in Ramp, ml-connector reads the bill and line-item transactions, maps them to Oracle Fusion GL accounts and cost centers, and posts the expense journal into Oracle Fusion's general ledger. Vendor records are aligned in both directions so bills reference valid suppliers in Oracle Fusion. GL postings are read-only in Ramp, so ml-connector never writes financial entries back to the expense platform. The sync can run on a schedule or trigger in real-time via Ramp webhooks.

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted and refreshes bearer tokens when a call returns 401. On the Oracle Fusion side it uses the customer-specific pod URL per tenant, since Oracle publishes no shared base address, and filters journal entries by LastUpdateDate to avoid polling the entire dataset. On the Ramp side it can receive bill and transaction webhooks where they are enabled, or poll the API with the same LastUpdateDate filtering. Vendors are matched by name or external reference before posting, so every expense journal references a GL account and cost center that already exists in Oracle Fusion. Ramp rate limits are handled with exponential backoff and retry, and every record carries a full audit trail. If a downstream post to Oracle Fusion fails, the record is queued and replayed once the ledger is ready.

A real-world example

A mid-sized professional services firm runs Oracle Fusion Cloud ERP for finance and procurement, and uses Ramp for corporate cards and bill pay across three offices and a field workforce. Before the integration, expense approvers exported approved bills from Ramp each week and manually re-entered them into Oracle Fusion's general ledger, allocating expenses to office locations and cost centers by hand. Month-end close required chasing mismatches between Ramp's spend totals and Oracle Fusion's expense accounts. With Ramp and Oracle Fusion connected, each approved bill flows into Oracle Fusion automatically, allocated to the correct office and cost center, and vendor records stay in sync. The expense accounts reconcile at month-end without manual work.

What you can do

• •Read bills and transactions from Ramp and post expense journals to Oracle Fusion GL, allocated to the correct cost centers.
• •Authenticate both systems via OAuth 2.0 bearer tokens and refresh credentials when they expire.
• •Sync vendors and GL accounts between Ramp and Oracle Fusion so bills reference valid suppliers and cost center combinations.
• •Accept real-time bill and transaction webhooks from Ramp or poll the Ramp API on a schedule tied to your close calendar.
• •Deliver a full audit trail and replay failed records once the downstream ledger is ready.

Questions

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

Bills and transactions move from Ramp into Oracle Fusion Cloud ERP as expense journals. Vendor records and GL accounts are aligned in both directions so expenses reference valid suppliers and cost centers. GL postings are read-only in Ramp, so ml-connector does not write financial entries back to the expense platform.

Does the integration use Ramp webhooks or polling?

ml-connector can receive real-time webhooks from Ramp for bills, transactions, and vendors where webhooks are configured, or it can poll the Ramp API with filtering by LastUpdateDate to avoid processing the entire dataset. Webhooks are faster for large expense volumes; polling is simpler to set up. Choose the approach that fits your approval workflow.

How does the integration handle Oracle Fusion's lack of direct webhooks?

ml-connector polls Oracle Fusion's REST API on a schedule you define, typically every 5 to 15 minutes, filtering by LastUpdateDate or CreationDate to retrieve only new or changed records. This approach works for expense-driven workflows where near-real-time sync is acceptable and the data volume is manageable without dedicated middleware.