Oracle E-Business Suite and BILL integration

What moves between them

The main flow runs from Oracle E-Business Suite into BILL. ml-connector reads approved suppliers and AP invoices from EBS and creates matching vendors and bills in BILL, mapping each bill line to a BILL chart-of-accounts account. Because BILL has no purchase order object, approved EBS purchase orders are also represented as bills in BILL when that is how the customer pays them. The return flow runs from BILL into EBS: when a bill is paid in BILL, the payment posts into the EBS AP and GL open interface tables and is finished by the Payables Open Interface Import and Journal Import concurrent programs. Reference data such as GL accounts and vendor records is aligned so every bill lands on a valid account.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the EBS side it accepts the full instance base URL per customer, obtains a session token cookie, attaches the required responsibility and operating unit org ID context on every call, and re-authenticates when EBS returns a 401 because token sessions expire in 30 to 60 minutes. On the BILL side it logs in with the developer key and org credentials, refreshes the session on 401, and keeps concurrency at or below the three-request org limit. GL accounts and suppliers are mapped first so every BILL bill line references an account that exists on both sides. Writes back into EBS go through the open interface tables, so a 200 means the row was staged, not posted; ml-connector triggers or waits on the concurrent program and polls the base tables to confirm the invoice or journal actually imported. It uses the SOURCE column plus invoice number as a natural key to avoid duplicate inserts, since EBS has no idempotency header. EBS reads run as scheduled low-concurrency polling on the last update date because EBS has no webhooks and no rate limiter, while BILL payment.updated and payment.failed webhooks, verified with HMAC-SHA256, trigger the return flow as soon as a payment changes.

A real-world example

A mid-sized construction supply distributor with about 300 employees runs Oracle E-Business Suite for procurement, inventory, and the general ledger, but wants its AP clerks to approve and pay supplier bills in BILL for its faster ACH and approval routing. Before the integration, staff re-keyed each approved supplier and invoice from EBS into BILL, then typed every cleared payment back into EBS so the ledger matched, which delayed month-end close and produced posting errors. With Oracle E-Business Suite and BILL connected, approved suppliers and payables flow into BILL automatically, payments made in BILL post back into the EBS AP and GL interface tables, and the manual double entry on both ends is gone.

What you can do

• •Create BILL vendors and bills from approved Oracle E-Business Suite suppliers and AP invoices.
• •Represent approved EBS purchase orders as bills in BILL, since BILL has no purchase order object.
• •Post BILL payment confirmations back into the EBS AP and GL open interface tables and confirm the import.
• •Bridge EBS Basic or token-cookie auth and the BILL session login, refreshing each session on a 401.
• •Poll EBS on a schedule and consume HMAC-signed BILL payment webhooks, with retries and a full audit trail.

Questions

Which direction does data move between Oracle E-Business Suite and BILL?

The main flow is EBS into BILL: approved suppliers and AP invoices become vendors and bills in BILL. The return flow is BILL into EBS, where a paid bill posts into the EBS AP and GL open interface tables. Reference data such as GL accounts is aligned so every bill lands on a valid account.

How are purchase orders handled if BILL has no PO object?

BILL does not support purchase orders in its v3 API, so POs stay in Oracle E-Business Suite as the system of record. Where a customer pays against a PO through BILL, ml-connector represents the approved EBS purchase order as a bill in BILL. The PO itself is never created in BILL because the object does not exist there.

How does the integration handle EBS asynchronous writes and lack of webhooks?

Writes into EBS insert rows into open interface tables that a concurrent program later imports, so a 200 only means the row was staged. ml-connector triggers or waits on the Payables Open Interface Import and Journal Import programs, then polls the base tables to confirm the record posted. Because EBS has no webhooks, reads run as scheduled polling on the last update date, while BILL payment events arrive by signed webhook.