IFS Cloud and Anaplan integration

What moves between them

The main flow is IFS Cloud into Anaplan. GL vouchers (journal entries) are read from IFS Cloud on a weekly or monthly schedule (typically aligned with month-end close) and imported into an Anaplan model as line items. Supplier invoices (posting proposals) and GL accounts flow the same direction. Reference data such as suppliers, customers, and accounting dimensions (code-part values in IFS) are synced bidirectionally to keep Anaplan lists aligned with the current IFS master data. GL postings are read-only in IFS, so ml-connector never writes financial entries back. The import pattern in Anaplan is action-driven: ml-connector transforms IFS data into CSV, posts it to a pre-created import action, polls the task status, and monitors the import result for errors.

How ml-connector handles it

ml-connector stores IFS OAuth2 credentials and Anaplan basic or certificate credentials encrypted, and refreshes IFS tokens automatically when approaching expiry. On the IFS side, it builds OData queries with $filter on modified-date or state fields, handles If-Match / ETag concurrency by reading the record first before any mutation, respects the 1000-request-per-minute rate limit with exponential backoff on 429 responses, and validates company code (a mandatory field on IFS financial entities) as part of the customer configuration. On the Anaplan side, it transforms IFS records (GL vouchers, invoices, suppliers) into CSV rows matching the target module structure, POSTs the file to a pre-created import action, polls the task ID until the import reaches COMPLETE or ERROR, and checks the import log for per-row failures. Because Anaplan locks the model during bulk import, ml-connector serializes imports and does not run concurrent exports during a large import. It maps IFS company codes to Anaplan list items and IFS cost centers / GL accounts to Anaplan line item dimensions. ETag handling prevents optimistic lock conflicts on IFS mutations. Anaplan's 600-request-per-minute rate limit is shared across all integrations on the workspace, so ml-connector backs off and retries, with monitoring to alert if the workspace is consistently hitting the limit (indicating other integrations or UI activity).

A real-world example

A global mid-cap manufacturing company runs IFS Cloud for ERP across three operating companies, each with its own company code and cost center structure. The corporate finance team uses Anaplan for quarterly rolling forecasts and annual budgets. Before the integration, the finance analyst exported GL balances and invoice summary reports from IFS at month-end, manually entered them into Anaplan, then ran variance reports against the budget. The analyst spent three days each month re-keying and reconciling. With IFS and Anaplan connected, GL vouchers and supplier invoices flow automatically into Anaplan on a weekly basis. The planning model always reflects current actuals, variance reports run on demand without manual entry, and the monthly consolidation starts with accurate figures already in place.

What you can do

• •Sync IFS Cloud GL vouchers (journal entries) and posting proposals (supplier invoices) into Anaplan models as line items on a configurable schedule.
• •Map IFS company codes and cost centers to Anaplan list items and line item dimensions so finance data lands on the correct forecast dimensions.
• •Read IFS GL accounts, suppliers, and accounting dimensions and keep Anaplan reference lists current with master data changes.
• •Handle IFS OAuth2 token refresh, ETag concurrency requirements, 1000-request-per-minute rate limits, and OData pagination transparently.
• •Monitor Anaplan import task status, detect per-row failures in the import log, and alert on workspace-wide rate limit saturation.

Questions

What data moves between IFS Cloud and Anaplan, and in which direction?

The main flow is IFS Cloud into Anaplan. GL vouchers (journal entries), supplier invoices (posting proposals), GL accounts, suppliers, and accounting dimensions are read from IFS and imported into Anaplan models as line items and list items. The import is read-only on IFS, so ml-connector never writes GL postings or invoices back to IFS.

How does ml-connector handle IFS's ETag concurrency requirement and OData pagination?

ml-connector reads the full record to capture the @odata.etag value before performing any PATCH or POST mutation, then includes that ETag in the If-Match header to enforce optimistic concurrency. For reads, it respects IFS's recommendation to keep result sets under 5000 elements per request and uses $skip and $top to paginate large datasets, filtering on modified timestamp to detect only changed records.

How does Anaplan's action-based import pattern work with ml-connector?

Anaplan imports are triggered by POSTing CSV data to a pre-created import Action, which returns a task ID. ml-connector polls the task status until it reaches COMPLETE or CANCELLED, then checks the import log for per-row errors. Large imports lock the model, so ml-connector serializes them to avoid blocking concurrent reads, and monitors workspace-wide rate limits to back off if other integrations are active.