Oracle E-Business Suite and Tipalti integration

What moves between them

AP invoices and vendors are pulled from Oracle E-Business Suite on a configurable schedule and inserted into Tipalti as invoices and payees. Oracle AP_INVOICES_ALL records map to Tipalti invoices with vendor and GL account details; PO_HEADERS_ALL and PO_LINES_ALL map to Tipalti purchase orders for three-way matching. GL_CODE_COMBINATIONS map to Tipalti GL accounts. Payment approvals and status updates flow back to Oracle via interface table inserts, ready for concurrent program execution. The direction is primarily Oracle to Tipalti for invoice and vendor data; payment status returns to Oracle.

How ml-connector handles it

ml-connector polls Oracle E-Business Suite on a schedule you define, using the ISG REST endpoints for each customer's hostname and port. It authenticates with HTTP Basic Auth, obtains a session token if needed, and includes all required application context headers (ctx_orgid, ctx_responsibility, etc). It reads open invoices filtered by LAST_UPDATE_DATE and pagination limits to avoid overwhelming either system. For each invoice, it extracts the vendor, GL account, and PO reference, then maps these to Tipalti via REST using OAuth2 or HMAC authentication. Tipalti's single IPN endpoint receives events (payment_submitted, bill_updated), and ml-connector polls for status changes to write back to Oracle's AP_INVOICES_INTERFACE table. Write operations insert into interface tables; Oracle's concurrent programs then validate and post to base tables asynchronously, which may take minutes to hours. ml-connector retries failed reads on 401 (session timeout) and 429 (rate limit) with exponential backoff, and maintains a full audit trail of every invoice and payment status change.

A real-world example

A mid-market electronics distributor runs Oracle E-Business Suite for financials and procurement across three offices and uses Tipalti for global vendor management and US/EMEA mass payments. Before the integration, accounts payable staff received invoices in email, matched them manually to Oracle POs, entered them into both Oracle and Tipalti separately, then approved payments in Tipalti and re-keyed the payment status back into Oracle to close invoices. The process took 2-3 days per week of manual reconciliation. With Oracle E-Business Suite and Tipalti connected, invoices are pulled from Oracle automatically each morning, matched to POs in Tipalti's three-way matching, and routed for approval. When payments are submitted in Tipalti, the status syncs back to Oracle, closing the loop. The AP team now focuses on exception handling instead of data re-entry.

What you can do

• •Pull AP invoices and vendor records from Oracle E-Business Suite and sync them into Tipalti for three-way matching and payment automation.
• •Map Oracle GL accounts and cost centers to Tipalti GL codes so invoice allocations are validated against your chart of accounts.
• •Handle Oracle's customer-hosted REST endpoints with HTTP Basic Auth and session token refresh on 401 timeout.
• •Authenticate Tipalti with HMAC-SHA256 signatures or OAuth2 credentials and route payment status changes back to Oracle via interface tables.
• •Poll Oracle on a schedule aligned with your invoice receipt and approval cycle, with full audit trail and replay on error.

Questions

How does the integration handle Oracle's customer-hosted ISG endpoint and lack of webhooks?

Oracle E-Business Suite publishes no shared API gateway; each customer hosts the Integrated SOA Gateway on their own hostname and port. ml-connector accepts the full ISG URL per customer and polls the AP_INVOICES_ALL endpoint on a schedule tied to your invoice receipt cycle. Because Oracle has no webhooks without Oracle Integration Cloud as middleware, polling is the standard and most reliable approach.

What happens when an Oracle session token expires or a call hits Tipalti's rate limit?

Oracle session tokens expire based on EBS session timeout, typically 30-60 minutes. ml-connector caches the token and re-authenticates on 401. Tipalti returns HTTP 429 when rate limits are hit per API gateway node. ml-connector backs off and retries both with exponential backoff and jitter, so temporary limits do not cause invoice loss.

Can payment status flow back from Tipalti into Oracle, and how?

Yes. When a payment is submitted or status changes in Tipalti, ml-connector writes the update to Oracle's AP_INVOICES_INTERFACE table. Oracle's concurrent programs then validate and post to the base AP_INVOICES_ALL table asynchronously, which may take minutes to hours. This keeps your Oracle AP aging current with Tipalti payment activity.