IFS Cloud and BILL integration

What moves between them

Supplier invoices and purchase orders flow from IFS Cloud into BILL on a polling schedule you control, typically aligned with your invoice receipt pattern. Vendor records sync bidirectionally to keep both systems aligned. BILL confirms payment status, which can be read back into IFS Cloud for reconciliation if needed. New vendors in IFS Cloud are posted to BILL to keep the vendor master list current, and vendor updates trigger refreshes in BILL. The flow handles IFS Cloud's tenant-specific URLs and OData projection versions, and BILL's session token lifetime, so both authentication layers are transparent to your team.

How ml-connector handles it

ml-connector stores IFS Cloud OAuth credentials and BILL session credentials encrypted, and refreshes the IFS Cloud OAuth token when a call returns 401 or as the 60-minute lifetime approaches. It polls IFS Cloud's OData API for new and modified supplier invoices and vendors using timestamp filters, captures the OData ETag on read operations, and uses that ETag in the If-Match header when updating records (required by IFS for optimistic concurrency). Vendor names and numbers are mapped to BILL's vendor creation endpoint, and invoice detail (line items, GL account codes, amounts) is transformed from IFS Cloud's OData structure into BILL's bill import format. Since BILL supports only 10 webhook subscriptions, ml-connector manages that limit and polls for payment status changes from BILL to detect invoices marked paid. IFS Cloud's page size limit of 5000 elements and rate limit of 1000 requests per minute per tenant are respected, with exponential backoff and jitter on 429 responses. Every invoice carry a full audit trail showing the source record IFS Cloud reference, the target BILL invoice ID, and any transformation logic applied.

A real-world example

A mid-sized manufacturing company runs IFS Cloud ERP for production, procurement, and general ledger. The accounts payable team uses BILL for vendor payment automation and 2-way invoice reconciliation. Before integration, invoices arrived in BILL as email PDFs or manual uploads, causing delayed matching with IFS Cloud purchase orders and duplicate invoice entries. The AP team also maintained a separate vendor list in BILL, creating sync gaps when procurement added new suppliers in IFS Cloud. With IFS Cloud and BILL connected, each purchase order and incoming invoice flows into BILL automatically, vendors are synchronized, and invoice matching becomes automatic. The AP team focuses on exception handling and payments rather than invoice data entry.

What you can do

• •Automatically import supplier invoices from IFS Cloud into BILL, triggered on a schedule aligned with your invoice receipt pattern.
• •Keep vendor records synchronized across IFS Cloud and BILL so procurement changes flow to AP without manual updates.
• •Map IFS Cloud GL account codes and cost dimensions to BILL line items for accurate expense allocation during payment.
• •Bridge IFS Cloud OAuth 2.0 client credentials and BILL session token authentication, refreshing both transparently as needed.
• •Respect IFS Cloud's OData concurrency model (ETag / If-Match), pagination limits, and rate limits (1000 req/min), with automated retry and backoff.

Questions

Why does ml-connector poll IFS Cloud instead of using webhooks?

IFS Cloud offers Event Actions (server-side business event triggers), but they require per-customer manual configuration in the IFS admin UI and are not self-registerable via API. ml-connector uses pull-based polling of OData timestamps instead, which requires no IFS admin setup and scales automatically across all customers.

How does ml-connector handle IFS Cloud's OData ETag requirement for updates?

Every read from IFS Cloud includes an @odata.etag value. ml-connector captures that ETag during the invoice read, then passes it in the If-Match header when updating the record (e.g., to mark it as sent to BILL). If the record changed between read and update, IFS returns a 412 conflict, and ml-connector retries the read-modify-update cycle.

What happens if BILL's 10-webhook subscription limit is reached?

ml-connector manages the subscription lifecycle and polls BILL via GET endpoints for payment status changes on invoices already sent. This hybrid approach (webhooks for high-frequency events, polling for low-frequency reconciliation) fits within BILL's 10-subscription cap while keeping payment status current without manual GET calls.