Oracle E-Business Suite and Ramp integration

What moves between them

Bills flow from Ramp into Oracle E-Business Suite. As bills are created or updated in Ramp, ml-connector receives the webhook event, validates the bill amount and vendor code against EBS GL accounts and the vendor master, and inserts the bill into the AP_INVOICES_INTERFACE table with the mapped GL charge account and cost center from the Ramp accounting dimensions. EBS runs the AP import concurrent program, which validates, balances, and posts the bill to the GL and AP ledgers. GL accounts and vendors are synchronized bidirectionally on a scheduled interval so new EBS accounts and vendors are visible in Ramp, and new Ramp vendors are registered in EBS. Rejected or cancelled bills trigger a reversal entry in EBS if the original was posted.

How ml-connector handles it

ml-connector stores both credential sets encrypted and authenticates EBS with the customer-provided hostname and HTTP Basic credentials, re-authenticating with a session token on 401 to handle token expiry. It authenticates Ramp with OAuth2 client credentials and refreshes the access token when nearing expiry. On webhook receipt, ml-connector verifies the HMAC-SHA256 signature against Ramp's public key to prevent spoofing. It accepts application context headers for the EBS user's responsibility and organization and validates that every GL account and vendor referenced in the Ramp bill exists in EBS before posting. The bill is formatted and inserted into AP_INVOICES_INTERFACE with an interface transaction ID, then ml-connector triggers the EBS Payables Open Interface Import concurrent program, which handles validation, duplicate detection, and GL posting asynchronously. If the import fails, ml-connector logs the error and retries the concurrent program on a schedule rather than re-posting the bill. Bill amount disputes are resolved through the Ramp webhook status updates (paid, rejected, cancelled), which feed back into EBS with matching GL reversal or correction entries keyed to the original interface ID. Every record carries an audit trail and an idempotency key to prevent duplicate postings if the EBS import runs more than once.

A real-world example

A mid-sized B2B professional services firm uses Ramp for corporate cards, vendor bill payment, and spend visibility. Their finance team receives vendor bills through Ramp, approves them, and previously re-entered bill details into Oracle E-Business Suite by hand at month-end to keep the GL accounts balanced. With Ramp and EBS connected, bills flow directly into the AP register and post to GL accounts mapped to Ramp's cost centers (client code, project, department). The import validation catches vendor duplicates and missing GL accounts, and the audit trail shows which bills have been imported and when. Month-end close now begins with the AP and GL in agreement, eliminating the manual reconciliation work.

What you can do

• •Read Ramp bills in real-time via webhook push and insert them into Oracle EBS AP interface with mapped GL accounts and vendors.
• •Validate GL accounts and vendor codes in both systems so bill postings land on valid dimensions before import.
• •Trigger the EBS Payables Open Interface Import concurrent program and audit the result for each bill.
• •Handle bill rejections and cancellations by posting GL reversal entries keyed to the original bill.
• •Synchronize GL accounts and vendors bidirectionally on schedule so new accounts and vendors are visible across both systems.

Questions

How does ml-connector handle the difference between Ramp's bill creation and EBS AP invoice posting?

Ramp bills are created and paid in Ramp; ml-connector reads each bill via webhook on creation or update, validates the GL account and vendor against EBS, and posts the bill into EBS through the AP_INVOICES_INTERFACE open interface table. The EBS Payables Open Interface Import concurrent program then handles validation, duplicate detection, and GL posting asynchronously. ml-connector tracks the interface transaction ID and the EBS import result in the audit log.

What happens if an EBS GL account or vendor referenced in a Ramp bill does not exist?

ml-connector validates every GL account and vendor code in a Ramp bill against the EBS GL_CODE_COMBINATIONS and PO_VENDORS tables before posting to the interface. If either is missing, the bill is held in a pending state and a validation error is logged. The bill can be resubmitted once the GL account or vendor is created in EBS and the interface record is retried.

Does ml-connector handle bill rejections and cancellations in Ramp?

Yes. When a bill is rejected or cancelled in Ramp, ml-connector receives the webhook event, looks up the original bill's interface transaction ID in EBS, and posts a reversal entry to the AP and GL ledgers to undo the posting. The reversal is tagged with the cancellation reason and the original bill's interface ID for full audit trail traceability.