IFS Cloud and Cin7 integration

What moves between them

The main flow runs from IFS Cloud into Cin7. ml-connector polls IFS OData for suppliers, purchase orders, and supplier invoices on a configurable schedule, maps them into Cin7's Supplier and Purchase entities, and ensures the GL accounts in both systems align. Supplier master data (names, payment terms, contacts) syncs bidirectionally so both systems reference the same vendor list. Purchase order headers and line items flow from IFS to Cin7, with each line mapped to the correct GL account and company code. GL journal entries created in IFS (for example, supplier invoice accrual) are read from Cin7's chart of accounts to validate that posting targets exist before IFS updates. Cin7 chart of accounts is read-only via API, so no GL structure is pushed back to IFS.

How ml-connector handles it

ml-connector stores the IFS OAuth 2.0 client credentials encrypted and refreshes the bearer token every 50 minutes (before the 60-minute expiry). On the Cin7 side, the API key headers are presented on every call, and rate limits are tracked per key. Because IFS enforces OData page-size limits and rate throttling, ml-connector breaks large supplier or purchase-order pulls into paginated requests and backs off on HTTP 429 responses using exponential backoff with jitter. IFS requires an ETag header when updating records (for example, changing supplier bank details), so ml-connector reads the record first to capture the current ETag, then sends it with the mutation. Supplier and purchase-order mappings use the IFS supplier number or PO number as the deduplication key, so duplicate calls do not create orphan records. GL account mapping is validated at sync time: if IFS references a GL account code that does not exist in Cin7, the record is held in the audit queue for manual review rather than failing silently. Company codes are extracted from IFS financial records and validated against the customer's configured mapping table. Every sync carries a full audit trail, including the OData filter used to query IFS, the timestamp of the pull, and the row count per entity.

A real-world example

A mid-market manufacturing company runs IFS Cloud for production, procurement, and GL consolidation across three plants, and uses Cin7 for inventory valuation and purchase accounting. Before the integration, the procurement team exported purchase orders from IFS monthly and re-entered them into Cin7 by hand to maintain the inventory cost ledger. Supplier master data was maintained in both systems, leading to duplicate-vendor issues and mismatched payment terms. With IFS Cloud and Cin7 connected, each purchase order created in IFS automatically populates Cin7's purchase ledger in the correct GL account, supplier names stay synchronized, and the accounting close process eliminates the manual re-keying step.

What you can do

• •Read suppliers, purchase orders, and supplier invoices from IFS Cloud via OData polling and map them into Cin7 purchase and supplier records.
• •Keep supplier master data synchronized between IFS Cloud and Cin7, ensuring payment terms and contact details match in both systems.
• •Validate GL accounts in Cin7 before IFS journal entries are posted, preventing mismatches between systems.
• •Authenticate IFS Cloud with OAuth 2.0 client credentials and Cin7 with custom API key headers, managing token refresh and rate limits on both sides.
• •Track every supplier, purchase, and GL account sync in a full audit trail, with records held for manual review if validation fails.

Questions

Which direction does data move between IFS Cloud and Cin7?

The main flow is IFS Cloud into Cin7. Suppliers, purchase orders, and supplier invoices move from IFS into Cin7's purchase and supplier records. Supplier master data is synchronized bidirectionally so both systems reference the same vendors. GL account mappings are validated in Cin7 before IFS posts journal entries, but the chart of accounts itself is read-only in Cin7, so no GL structure flows back to IFS.

How does ml-connector handle IFS OData page limits and rate throttling?

IFS enforces a 5000-element page-size limit on OData queries and approximately 1000 requests per minute per tenant. ml-connector breaks large supplier or purchase-order pulls into paginated requests, each staying under the element limit, and monitors responses for HTTP 429 (rate limit exceeded). When throttled, it backs off using exponential backoff with jitter, and resumes the sync without losing records. Company codes are included in every financial record to ensure GL routing is correct.

What happens if a purchase order in IFS references a GL account that does not exist in Cin7?

ml-connector validates GL account codes in Cin7 before syncing a purchase order. If an account is missing, the record is placed in the audit queue for manual review rather than failing silently or creating a partial record. The audit trail shows which account was not found and which purchase order was affected, so the procurement or finance team can correct the mapping and replay the sync.