IFS Cloud and Procurify integration

What moves between them

Purchase orders and vendor invoices flow from Procurify into IFS Cloud. ml-connector polls Procurify on a schedule you choose (e.g., daily or after approvals), reads purchase orders and bills (mapped to IFS supplier invoices), and posts them into IFS Cloud's general ledger using the OData API. Vendor records sync in both directions so your supplier master stays consistent. GL postings use the company code and cost center dimensions configured per customer so finance can allocate procurement spend to the right cost centers. All records are read and post to IFS; no writes go back into Procurify.

How ml-connector handles it

ml-connector maintains OAuth 2.0 sessions for both systems and refreshes tokens before expiry to keep polling uninterrupted. It reads from Procurify using date-range filters to retrieve new or modified purchase orders and bills, then queries IFS Cloud to fetch GL accounts, vendors, and cost center dimensions for the configured company codes. Before creating a supplier invoice in IFS, it checks for an existing invoice with the same Procurify bill number to avoid duplicates. Each PO and bill is mapped to an IFS posting proposal via the required OData ETag concurrency mechanism, and postings are batched to respect the 5000-element page limit. ml-connector retries with exponential backoff on HTTP 429 rate-limit responses from either system and maintains a complete audit trail of every transaction moved between the two platforms.

A real-world example

A growing product company uses Procurify for distributed procurement across engineering and operations teams, and IFS Cloud for manufacturing ERP and general ledger. Before the integration, operations exported approved POs from Procurify weekly and manually entered them into IFS as supplier invoices, allocating costs to the correct department and cost center. Finance then spent days reconciling Procurify's spend reports against IFS subledgers. After connecting the two systems, each approved PO in Procurify automatically flows into IFS with the cost center already mapped based on the approving department, and bills post to the GL on the same day they land in Procurify. Month-end close now starts with procurement and AP data already reconciled, eliminating the manual re-entry step and reducing close cycle by three days.

What you can do

• •Post Procurify purchase orders and vendor invoices into IFS Cloud as supplier invoices with GL account and company code allocation.
• •Keep vendor records aligned between Procurify and IFS Cloud so your supplier master is consistent across both systems.
• •Map Procurify purchase orders and bills to IFS cost centers and accounting dimensions so spend is allocated to the correct GL accounts.
• •Authenticate both systems with OAuth 2.0, refresh tokens before expiry, and poll on a schedule tied to your procurement approval workflow.
• •Maintain a complete audit trail of every PO, bill, and vendor record moved between the systems with automatic deduplication and retry logic.

Questions

Which direction does data move between IFS Cloud and Procurify?

The main flow is Procurify into IFS Cloud. Purchase orders and bills move from Procurify into IFS Cloud as supplier invoices and GL postings, while vendor records are synced in both directions to keep the supplier master consistent. IFS Cloud records are read-only from Procurify's perspective, so ml-connector does not write back to Procurify.

How does the integration handle IFS Cloud's OData ETag requirement and page limits?

ml-connector captures the If-Match ETag header when reading an IFS record before posting a mutation to enforce optimistic concurrency and prevent conflicts. For large datasets, ml-connector respects the 5000-element page limit per OData request, batching POs and bills across multiple calls and breaking expanded nested collections into separate queries to avoid partial data or errors.

What authentication and polling strategy does ml-connector use for these two systems?

Both systems use OAuth 2.0 client credentials. ml-connector maintains separate bearer tokens for each system and refreshes tokens before expiry to keep polling uninterrupted. Since neither system supports webhooks, ml-connector polls Procurify on your chosen schedule using date-range filters, queries IFS for corresponding GL accounts and dimensions, and deduplicates before posting to avoid re-entering the same bills.