What data moves between IFS Cloud and Tipalti?

Supplier records (SupplierSet) and purchase proposal headers (PostingProposalHeadSet) flow from IFS into Tipalti as payees and invoices. GL accounts and company codes are synced to ensure invoice allocations match IFS dimensions. Payment status updates and completion events flow from Tipalti back to IFS via webhooks for audit and reporting.

Why does IFS require an ETag header for updates, and how does ml-connector handle it?

IFS Cloud enforces optimistic concurrency control using ETag headers to prevent simultaneous overwrites. ml-connector captures the @odata.etag value when reading a record and includes it in the If-Match header when writing back updates. If the ETag has changed (another process modified the record), IFS returns a 409 Conflict, and ml-connector retries the read-then-write cycle.

How does ml-connector handle the differences between IFS polling and Tipalti webhooks?

IFS does not offer webhooks as a self-registerable API, so ml-connector polls OData endpoints on a schedule using modified timestamps to fetch new and changed records. Tipalti supports IPN webhooks for payment events, so ml-connector subscribes to payment notifications and processes them in real time while still polling IFS on the configured schedule.

IFS CloudTipalti

IFS Cloud and Tipalti integration

IFS Cloud runs manufacturing, procurement, and finance operations. Tipalti automates accounts payable and handles mass payments to global suppliers. Connecting them keeps your supplier master and invoice data flowing from IFS into Tipalti without manual data entry. New supplier records in IFS automatically create payees in Tipalti, and invoices posted in IFS appear in Tipalti for approval, payment processing, and compliance workflows.

How IFS Cloud works

IFS Cloud is an enterprise ERP platform covering manufacturing, asset management, field service, finance, procurement, supply chain, and project management. It exposes suppliers, purchase orders, supplier invoices, GL accounts, and journal entries through its OData v4 REST API, with a tenant-specific base URL (https://<tenant>.ifs.cloud). Authentication uses OAuth2 client credentials, and tokens expire after approximately 60 minutes. IFS does not offer webhook subscriptions as a self-registerable API, so integration relies on polling OData endpoints with filters on modified timestamps. The platform enforces an ETag header on mutation operations for optimistic concurrency control, and rate-limits at approximately 1000 requests per minute per tenant.

How Tipalti works

Tipalti is an end-to-end accounts payable automation and mass payments platform that manages supplier onboarding, invoice processing, purchase orders, and global payments. It exposes its functionality through both SOAP/XML and REST/JSON APIs. SOAP calls require an HMAC-SHA256 signature (payer_name + api_key), while REST calls use OAuth2 client credentials or a static x-api-key header. Tipalti supports webhook notifications (IPN) for events such as payment submission, approval, and completion, with HMAC-SHA256 signature verification. All webhook events route through a single configurable endpoint per payer account, and event types include payee_details_changed, bill_updated, payment_submitted, and payment_completed.

What moves between them

Data flows primarily from IFS Cloud into Tipalti. Supplier records (SupplierSet) sync to Tipalti payees, and purchase proposal headers (PostingProposalHeadSet) sync to Tipalti invoices, allowing Tipalti to manage the approval and payment workflow. Reference data such as GL accounts and company codes flow in both directions to keep invoice dimensions aligned. Payment status and completion notifications are read from Tipalti (via IPN webhooks) and recorded in IFS for audit trails. The sync runs on a schedule configured by the customer, typically daily or after batch invoice posting in IFS.

How ml-connector handles it

ml-connector stores OAuth2 credentials for both IFS Cloud and Tipalti encrypted in the database. On the IFS side, it uses the tenant-specific base URL provided at setup and queries the OData API with filters on the CreatedDateTime and ModifiedDateTime fields to fetch new and changed suppliers and invoices. For each IFS supplier record, it maps the SupplierCode to the Tipalti payee identifier; for invoices, it maps IFS PostingProposalHeadSet to Tipalti invoices with the correct company code and GL account references. IFS requires an ETag header (If-Match) for mutation operations, so ml-connector captures the @odata.etag value on each read and includes it when writing back status or payment information. On the Tipalti side, ml-connector uses the OAuth2 REST endpoints for writes (new invoices and payees) and subscribes to IPN webhooks for payment events; webhook signatures are verified with HMAC-SHA256 before processing. Because IFS enforces a 5000-element array limit on expanded nested collections, ml-connector pages large result sets separately. Rate-limit responses (HTTP 429 from IFS) trigger exponential backoff with jitter. Deduplication is model-based: before creating a new payee or invoice, ml-connector queries for existing records by supplier code and invoice number.

A real-world example

A mid-sized discrete manufacturer runs IFS Cloud for production, procurement, and accounting across three plants. They use Tipalti for global supplier payments and vendor compliance to automate AP processing for over 2000 suppliers across five countries. Before integration, the AP team manually exported supplier lists and invoices from IFS weekly, re-entered them into Tipalti, and reconciled payment status back into IFS for month-end reporting. With IFS Cloud and Tipalti connected, new suppliers in IFS automatically populate in Tipalti for compliance workflows, invoices flow directly without re-keying, and payment status updates sync back to IFS. The AP team now focuses on approvals and exceptions instead of data transfer.

What you can do

Sync supplier records from IFS Cloud to Tipalti payees, keeping vendor master data aligned across both systems.
Push purchase proposal invoices from IFS into Tipalti with company codes and GL account references intact for AP processing.
Verify Tipalti webhook signatures (HMAC-SHA256) and ingest payment status, approval, and completion events back into IFS for audit trails.
Handle IFS ETag concurrency headers and OAuth2 token refresh on both platforms, with exponential backoff on rate-limit responses.
Page large OData result sets separately and deduplicate supplier and invoice records by code and invoice number before create operations.

Questions

What data moves between IFS Cloud and Tipalti?: Supplier records (SupplierSet) and purchase proposal headers (PostingProposalHeadSet) flow from IFS into Tipalti as payees and invoices. GL accounts and company codes are synced to ensure invoice allocations match IFS dimensions. Payment status updates and completion events flow from Tipalti back to IFS via webhooks for audit and reporting.
Why does IFS require an ETag header for updates, and how does ml-connector handle it?: IFS Cloud enforces optimistic concurrency control using ETag headers to prevent simultaneous overwrites. ml-connector captures the @odata.etag value when reading a record and includes it in the If-Match header when writing back updates. If the ETag has changed (another process modified the record), IFS returns a 409 Conflict, and ml-connector retries the read-then-write cycle.
How does ml-connector handle the differences between IFS polling and Tipalti webhooks?: IFS does not offer webhooks as a self-registerable API, so ml-connector polls OData endpoints on a schedule using modified timestamps to fetch new and changed records. Tipalti supports IPN webhooks for payment events, so ml-connector subscribes to payment notifications and processes them in real time while still polling IFS on the configured schedule.

Connect IFS Cloud and Tipalti

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

Get started