IFS Cloud and Procore integration

What moves between them

The main flow runs from IFS Cloud into Procore. Purchase orders from IFS Cloud are mapped to Procore purchase order contracts, and supplier invoices become payment applications or direct costs. Cost codes and GL dimensions (accounting dimensions from CodePartValueSet) are synchronized bidirectionally so project budgets in Procore align with IFS Cloud GL accounts. Requisitions and direct costs from Procore flow back into IFS Cloud as purchase order updates or voucher proposals for project cost tracking. Vendor master data is aligned in both directions. Synchronization occurs on a polling schedule during business hours and can also ingest Procore webhook pushes for real-time requisition and cost updates.

How ml-connector handles it

ml-connector stores both OAuth 2.0 credential sets encrypted and refreshes each token when a call returns 401 or approaches expiry. On the IFS Cloud side, it accepts the full tenant-specific subdomain per customer and respects the ETag header requirement by reading each purchase order or invoice record first to capture its @odata.etag before attempting a mutation. It validates all GL accounts and cost codes exist in IFS Cloud before posting Procore data, and queries existing records by order number before creating duplicates. On the Procore side, it extracts company_id and project_id from the webhook payload and injects them into every API call since nearly all Procore endpoints require these path parameters. Vendor records are matched by name across systems to establish a mapping table, and any unmatched vendor in IFS Cloud is created in Procore first before the purchase order can be posted. IFS Cloud rate limits return HTTP 429 per tenant, so ml-connector backs off exponentially with jitter and retries. Page size is kept under 5000 elements to avoid OData errors. Procore webhooks must return 2xx within 5 seconds, so the handler queues all processing asynchronously and returns immediately. Every record carries a full audit trail and can be replayed if a downstream write fails.

A real-world example

A mid-sized construction equipment manufacturer runs IFS Cloud for manufacturing and project finance, and uses Procore for field operations and project cost tracking across five active job sites. Before the integration, the procurement team managed purchase orders in IFS Cloud and the project managers manually entered them into Procore as purchase order contracts, then exported Procore requisitions and entered them back into IFS Cloud to reconcile project costs at month-end. With IFS Cloud and Procore connected, each PO created in IFS Cloud automatically appears in Procore under the correct cost code and project, project managers add requisitions in Procore, and those requisitions flow back into IFS Cloud as vouchers ready to match against supplier invoices. The manual re-entry step is eliminated and project financials stay in sync across both systems.

What you can do

• •Sync purchase orders from IFS Cloud to Procore as purchase order contracts, mapped to the correct project and cost code.
• •Post supplier invoices from IFS Cloud into Procore as direct costs or payment applications with full project and cost allocation.
• •Keep vendors aligned across both systems; create missing vendors in Procore before posting orders from IFS Cloud.
• •Synchronize cost codes and GL dimensions between IFS Cloud and Procore so project budgets match GL accounts.
• •Ingest Procore requisitions and direct costs via webhook and poll them back into IFS Cloud as purchase order proposals and vouchers.

Questions

Which direction does data move between IFS Cloud and Procore?

The main flow is IFS Cloud to Procore: purchase orders and supplier invoices sync into Procore as commitments and direct costs. Cost codes and GL dimensions (accounting dimensions) are aligned bidirectionally so project budgets match GL accounts. Procore requisitions and direct costs flow back into IFS Cloud as purchase order proposals and vouchers for project cost tracking. Vendor master data is synchronized in both directions.

How does the integration handle IFS Cloud's ETag requirement and lack of webhooks?

ml-connector reads each IFS Cloud purchase order or invoice record first to capture its @odata.etag value before attempting a mutation, satisfying IFS Cloud's optimistic concurrency requirement. Since IFS Cloud has no API-driven webhook system, ml-connector polls OData endpoints on a business hours schedule with filters on modified timestamps, respecting IFS Cloud's page size limits and rate limits. It can also ingest Procore webhook pushes for real-time updates on requisitions and costs flowing back into IFS Cloud.

What happens when a vendor or cost code doesn't exist in Procore when an IFS Cloud purchase order is posted?

ml-connector maintains a vendor mapping table and validates that each vendor from IFS Cloud exists in Procore first. If a vendor is missing, ml-connector creates it in Procore before posting the purchase order. Cost codes and GL dimensions are validated to exist in both systems before any financial record is posted; if a mismatch is found, the record is flagged in the audit log and queued for retry once the missing dimension is created.