ml-connector
Oracle JD EdwardsSAP Concur

Oracle JD Edwards and SAP Concur integration

Oracle JD Edwards manages your on-premises finance, purchasing, and manufacturing. SAP Concur manages employee travel and expenses. Connecting them keeps your GL in step with approved spending and prevents duplicate vendor invoices or expense re-entry errors. Approved expense reports and vendor invoices from Concur flow into JD Edwards' GL on your schedule, mapped to the correct cost centers and GL accounts so month-end close requires no manual reconciliation between the two systems.

How Oracle JD Edwards works

Oracle JD Edwards EnterpriseOne exposes GL accounts, accounts payable ledger, purchase orders, and vendor master records through REST APIs running on a customer-hosted Application Interface Services (AIS) Server at a site-specific URL. Authentication uses a session token obtained by POST with username and password; tokens expire every 30 to 60 minutes and must be refreshed before use. The API supports date filtering on transaction tables for polling, with pagination via maxPageSize parameter. Since JD Edwards has no native outbound webhooks, data is pulled on a polling schedule rather than pushed. Custom orchestrations can be configured to call an inbound webhook, but JD Edwards itself remains pull-only.

How SAP Concur works

SAP Concur is a multi-datacenter cloud service that manages expense reports, invoices, purchase orders, and vendor records through REST APIs authenticated with OAuth 2.0 password grant credentials. The OAuth token lasts one hour and requires refresh via the token endpoint. Concur supports Event Subscription Service webhooks that push notifications when expense reports or invoices reach approval, at-least-once delivery with automatic retry on network errors. Webhooks use mutual TLS with a certificate signed by SAP SE, and each subscription has a specific CN that must be validated. Concur also exposes Financial Integration document endpoints to retrieve approved records in a normalized format for downstream posting.

What moves between them

Expense reports and vendor invoices are pulled from SAP Concur after approval and posted into Oracle JD Edwards' GL as journal entries. Vendors, cost centers, and GL accounts are mapped between systems so approved expenses and invoices land on valid JD Edwards dimensions. Concur supports push via webhook when an expense is approved, but since JD Edwards cannot receive unsolicited webhooks (it is on-premises), ml-connector combines Concur webhooks for real-time notification with polling on JD Edwards side to confirm the record is ready for GL posting. The posting is one-way: JD Edwards GL transactions are read-only in Concur's Financial Integration surface, so ml-connector does not write financial entries back to Concur.

How ml-connector handles it

ml-connector stores both credential sets encrypted and manages their distinct lifetimes separately. For JD Edwards, it caches the session token and refreshes it before expiry or when a call returns HTTP 444 (invalid token). For Concur, it manages the OAuth access token (1 hour) and refresh token (6 months) via the token endpoint, extracting the geolocation from the OAuth response to route all subsequent API calls to the correct Concur datacenter (US, EMEA, or China). On the inbound side, ml-connector registers a webhook subscription with Concur to receive notifications when an expense report or invoice is approved, validates the mutual TLS certificate CN and Concur signature on each webhook payload, and logs the event. It then polls the JD Edwards AIS Server to confirm the record is eligible for posting (vendor exists, cost center exists), and queues the GL posting batch. Concur Financial Integration documents are fetched in their normalized format, GL amounts are recalculated for batch balance, and the batch is posted via JD Edwards' batch voucher orchestration. Cost center and vendor lookups happen in both directions so master data stays aligned. If a JD Edwards post fails due to a missing cost center or vendor, the record is marked for retry and can be replayed once the dimension is added to JD Edwards. AIS Server IP allowlists are common; customer must whitelist the connector's egress IP addresses.

A real-world example

A mid-market services company uses Oracle JD Edwards for core accounting and purchasing, and SAP Concur for employee travel and expense management. Before the integration, the finance team approved expenses in Concur, then manually exported the monthly expense summary to a CSV, looked up the cost center from the approver's name, and re-entered each line into JD Edwards as a GL posting. When an employee's cost center changed mid-month, the team had to go back and re-post the entries to the correct account. With Oracle JD Edwards and SAP Concur connected, approved expenses appear in JD Edwards automatically at the moment of approval, already allocated to the correct cost center and GL account. Month-end close is faster, and cost center changes are reflected immediately across both systems.

What you can do

  • Post approved expense reports from SAP Concur into Oracle JD Edwards' general ledger on your approval schedule, allocated to the correct cost center.
  • Map vendor records, cost centers, and GL accounts between Concur and JD Edwards so expenses land on valid dimensions.
  • Validate webhook signatures and mutual TLS certificates, and poll JD Edwards' AIS Server to confirm records are eligible for posting before queuing GL batches.
  • Refresh Oracle JD Edwards session tokens (30-60 minute lifetime) and SAP Concur OAuth tokens (1-hour lifetime) continuously so connections stay alive.
  • Maintain a full audit trail of each expense and invoice posted, with retry and replay capability if a GL posting fails due to missing cost center or vendor.

Questions

How does ml-connector handle the difference between Concur webhooks and JD Edwards' polling-only design?
SAP Concur supports webhooks that push notifications when an expense is approved. Since Oracle JD Edwards is on-premises and has no inbound webhook endpoint, ml-connector registers to receive Concur webhooks for real-time notification of approval, then polls the JD Edwards AIS Server to confirm the record is ready for GL posting and retrieves it via the API. This hybrid approach gives you near-real-time updates while respecting JD Edwards' architecture.
What happens when an Oracle JD Edwards session token expires?
JD Edwards tokens expire every 30 to 60 minutes by default, and HTTP 444 signals expiry. ml-connector refreshes the session token before expiry using the stored username and password, and if a call returns 444, it re-authenticates immediately and retries the request. The connection stays transparent to you; no manual intervention is needed.
How are vendors and cost centers validated between the two systems?
Before posting an expense or invoice, ml-connector looks up the vendor in the JD Edwards vendor master (F0401 table) and the cost center in the GL account master to ensure both exist and are active. If either is missing, the record is marked for retry and logged in the audit trail. Once the dimension is added to JD Edwards, the record can be replayed without re-approval in SAP Concur.

Related integrations

Connect Oracle JD Edwards and SAP Concur

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started