Oracle JD Edwards and Tipalti integration

What moves between them

Supplier master records and reference data flow from JD Edwards into Tipalti to keep the payee database current. JD Edwards purchase orders and invoice data flow into Tipalti to trigger payment workflows. Payment completion, approval, and rejection events flow from Tipalti via webhook to ml-connector, which writes settlement status back into the JD Edwards accounts payable ledger so the ERP reflects what has been paid. Invoices that are matched to purchase orders in JD Edwards are prioritized for sync. The sync is pull-based on a schedule you configure, with webhook events processed immediately when Tipalti notifies ml-connector of a state change.

How ml-connector handles it

ml-connector stores both the JD Edwards AIS Server URL and credentials encrypted, then calls /jderest/v2/tokenrequest on each sync to obtain a fresh session token, since tokens expire after 30 to 60 minutes. It polls the F0401 (supplier master) and F0411 (AP ledger) tables with a date filter on the UPMJ (date updated) field to retrieve only changed records since the last sync. It transforms JD Edwards supplier records into Tipalti payee records, mapping the JD Edwards GL account (from F0901) to the corresponding Tipalti GL account so that payments land on the correct accounting dimension. On the Tipalti side, ml-connector uses the SOAP API for payee synchronization and the REST API for IPN webhook verification and payment status queries. It validates the HMAC-SHA256 signature on every webhook notification before writing payment status back to F0411, preventing replay of tampered events. Because JD Edwards has no idempotency header support, ml-connector uses the purchase order number and invoice reference as a natural dedup key to prevent duplicate payment records if a webhook is retried. It handles AIS Server downtime and token expiry by retrying with exponential backoff and refracting AIS Server unavailability into an alert so operational staff can investigate. Every record carries a full audit trail showing the source record ID, sync timestamp, and any transformation applied.

A real-world example

A mid-sized discrete manufacturer operates Oracle JD Edwards on-premises for procurement and financial close, and uses Tipalti for global supplier payments and 1099 tax compliance across a network of 200 suppliers in the US and Canada. Before the integration, the accounts payable team manually entered invoices from Tipalti back into JD Edwards to reconcile, creating a 2 to 3 day lag and manual data-entry errors. Supplier master maintenance was duplicated - changes to payment terms or address had to be entered in both systems by hand. With JD Edwards and Tipalti connected, new purchase orders and supplier invoices sync automatically, Tipalti sends payment notifications that flow back into JD Edwards' AP ledger, and supplier master changes in JD Edwards immediately propagate to Tipalti payees, eliminating the duplicate entry work and closing the synchronization lag to near real-time.

What you can do

• •Sync supplier master records from JD Edwards into Tipalti payees, keeping contact details, payment terms, and banking information aligned.
• •Poll JD Edwards for new and changed purchase orders and invoices, pushing them into Tipalti to initiate payment workflows without manual invoice entry.
• •Receive payment notifications from Tipalti via webhook, writing settlement status (approved, paid, rejected) back into JD Edwards accounts payable so the ERP reflects the true payment state.
• •Map JD Edwards GL accounts to Tipalti accounting dimensions so payments post to the correct cost centers and expense categories in your general ledger.
• •Manage JD Edwards session token refresh and AIS Server connectivity with exponential backoff retries and a complete audit trail of every supplier, invoice, and payment record.

Questions

How does ml-connector handle JD Edwards session token expiry and AIS Server downtime?

ml-connector obtains a fresh session token on each sync call to /jderest/v2/tokenrequest, handling the 30 to 60 minute token lifetime transparently. If the AIS Server is unavailable or the token is invalid (HTTP 444), ml-connector retries with exponential backoff and jitter, then surfaces the error to your operations team via an alert. IP allowlist restrictions on the AIS Server can be mitigated by whitelisting ml-connector egress IP addresses with your infrastructure team.

Which direction does data move between JD Edwards and Tipalti?

Supplier master records, purchase orders, and invoices flow from JD Edwards into Tipalti to populate the payment workflow. Payment events (approved, submitted, completed, rejected) flow from Tipalti back into JD Edwards via webhook, updating the accounts payable ledger so the ERP reflects what has been paid. GL account mapping is bidirectional to ensure consistency.

How does ml-connector prevent duplicate invoices if a Tipalti webhook is retried?

JD Edwards does not support the Idempotency-Key header standard, so ml-connector uses the natural key of purchase order number plus invoice reference to detect and skip duplicate invoices. Each record carries a source identifier in the audit trail so retried webhook events can be deduplicated without creating false invoice duplicates in the ERP.