Oracle JD Edwards and BILL integration

What moves between them

The main flow runs from Oracle JD Edwards EnterpriseOne into BILL. Supplier records from F0401 become BILL vendors, and approved purchase orders and supplier invoices become BILL bills with line items mapped to GL accounts. Once BILL processes a payment, the confirmation flows back into JD Edwards, where ml-connector posts an AP voucher or GL journal entry through an orchestration so the ledger reflects what was paid. JD Edwards is polled on the schedule you set, since it cannot push events, while BILL bill and payment changes arrive in near real time through webhooks. Chart of accounts and business units are aligned so every BILL line references a GL account that already exists in JD Edwards.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two different session logins. On the JD Edwards side it accepts the full AIS Server URL per customer, posts the username and password to get a session token, sends that token in the jde-AIS-Auth header, and re-authenticates automatically on HTTP 444 after an AIS Server restart; the customer CNC admin must also add the connector egress IPs to the AIS allowedHosts list or calls return HTTP 405. On the BILL side it logs in with the devKey and org credentials, caches the sessionId, and re-logs in on a 401 because session expiry is silent, while keeping no more than three calls in flight per org to respect the concurrent limit. Vendors map by name and tax ID, purchase order and invoice lines map to BILL bill line items, and each line is tagged to a GL account and department that exist on both sides. Because JD Edwards writes only through orchestrations, the customer imports the AP orchestration into Orchestrator Studio so payment confirmations can post as vouchers. Neither system offers an idempotency header, so ml-connector dedupes on JD Edwards document numbers and BILL entity IDs before creating records, and retries with backoff when BILL returns a rate-limit error or JD Edwards returns a 500.

A real-world example

A mid-sized industrial distributor with about 300 staff runs Oracle JD Edwards EnterpriseOne on its own infrastructure for procurement and finance, and adopts BILL to modernize how it approves and pays supplier invoices. Before the integration, buyers raised purchase orders in JD Edwards while AP clerks re-typed each supplier and invoice into BILL, then manually entered every payment back into the JD Edwards AP ledger, which left the two systems out of step at month-end. With the connection in place, approved purchase orders and suppliers flow from JD Edwards into BILL automatically, the AP team approves and pays in BILL, and each payment posts back to JD Edwards as a voucher against the correct account. The double entry disappears and the ledger matches what BILL actually paid.

What you can do

• •Create BILL vendors and bills from Oracle JD Edwards EnterpriseOne suppliers and approved purchase orders.
• •Post each BILL payment confirmation back into JD Edwards as an AP voucher or GL journal entry through an orchestration.
• •Bridge the JD Edwards session token in the jde-AIS-Auth header to the BILL devKey and sessionId login.
• •Map BILL bill line items to valid JD Edwards GL accounts and business units before any record is written.
• •Poll JD Edwards on your schedule while receiving signed BILL bill and payment webhooks in near real time.

Questions

Which direction does data move between Oracle JD Edwards EnterpriseOne and BILL?

The main flow is JD Edwards into BILL: suppliers and approved purchase orders become BILL vendors and bills. After BILL processes a payment, the confirmation flows back into JD Edwards as an AP voucher or journal entry. Purchase orders stay in JD Edwards because BILL has no purchase order entity of its own.

How does ml-connector write payments back into JD Edwards when it has no public write endpoint?

JD Edwards does not allow direct table writes over REST, so all writes go through named orchestrations. The customer imports the AP orchestration into Orchestrator Studio, and ml-connector calls it to create the voucher or journal entry. Reads still use the data service against the F-tables.

How are the two session-token logins kept alive?

Both systems use short-lived session tokens rather than OAuth2. ml-connector re-authenticates with JD Edwards on an HTTP 444 invalid-token response after an AIS Server restart, and re-logs in to BILL on a 401 because BILL session expiry is silent. It also keeps no more than three BILL calls in flight per org to respect the concurrent limit.