IFS Cloud and Airbase integration

What moves between them

The main flow runs from IFS Cloud into Airbase. Supplier records and purchase orders from IFS Cloud are read periodically and synced to Airbase so the vendor list and PO baseline remain current. Approved purchase requests and payment records from Airbase flow back into IFS Cloud as journal entries and voucher updates, allocated to the GL accounts and cost dimensions configured in IFS. GL accounts are aligned in both directions so payments land on valid IFS accounting dimensions. Because IFS Cloud is pull-only and Airbase supports webhooks, ml-connector polls IFS on a schedule and also subscribes to Airbase webhook events for real-time purchase request approvals, allowing IFS to see payment approval status as soon as it occurs.

How ml-connector handles it

ml-connector stores both credential sets encrypted and refreshes the IFS Cloud OAuth 2.0 token every 50 minutes to stay ahead of expiry, since the token lifetime is approximately 60 minutes. On the IFS side, it respects OData pagination and captures the ETag header on read, then includes the ETag on any PATCH or POST mutations to satisfy optimistic concurrency control. On the Airbase side, it uses the static bearer token on every request. Supplier records are synced bidirectionally: new suppliers in IFS post to Airbase, and updates to supplier payment terms in Airbase (where supported) update the vendor record in IFS. Purchase orders flow IFS to Airbase with line-item detail, and approved purchase requests from Airbase are written back to IFS as journal entries in the configured GL account per purchase type. Because IFS enforces a 5000-element page size limit and rate-limits at approximately 1000 requests per minute, ml-connector batches requests and backs off on HTTP 429 responses with exponential jitter. Payment records are deduplicated in IFS by checking for existing vouchers before creating new entries. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized discrete manufacturer runs IFS Cloud for procurement and finance across two regional plants and uses Airbase for centralized spend management and AP automation. Before the integration, procurement teams entered purchase orders manually in both IFS and Airbase, creating duplicate work and reconciliation headaches. Finance teams received payment approvals from Airbase and re-entered them in IFS by hand. With IFS Cloud and Airbase connected, purchase orders created in IFS flow to Airbase automatically, approved purchase requests sync back as GL vouchers, and supplier records stay aligned. Procurement teams maintain a single source of truth in IFS, and finance closes faster with payment records already posted.

What you can do

• •Sync purchase orders and line items from IFS Cloud to Airbase, keeping the PO baseline current.
• •Flow approved purchase requests and payment records from Airbase back into IFS Cloud's GL as journal entries, allocated to the correct GL accounts.
• •Align suppliers and vendor records bidirectionally so new vendors in IFS appear in Airbase.
• •Authenticate IFS Cloud with OAuth 2.0 tenant-specific credentials and manage token refresh, and Airbase with static bearer token.
• •Poll IFS Cloud on a schedule while subscribing to Airbase webhooks for real-time purchase request approvals, with retries and a full audit trail on every record.

Questions

Which direction does data move between IFS Cloud and Airbase?

Purchase orders and supplier records flow from IFS Cloud into Airbase so they remain in sync. Approved purchase requests and payment records flow from Airbase back into IFS Cloud as journal entries and GL vouchers. Suppliers are aligned bidirectionally so changes in either system can propagate.

How does ml-connector handle IFS Cloud's OData protocol and token refresh?

ml-connector respects IFS Cloud's OData v4 pagination limits of approximately 5000 elements per request and captures the ETag header on read operations. It refreshes the OAuth 2.0 token every 50 minutes to stay ahead of the approximately 60-minute expiry window. On mutations, it includes the ETag in PATCH and POST requests to satisfy IFS Cloud's optimistic concurrency control.

How are purchase orders mapped and deduplicated across the two systems?

Purchase orders are synced with their line-item detail from IFS Cloud to Airbase using the IFS Cloud PO number as the unique identifier. When approved purchase requests return from Airbase, ml-connector checks for existing GL vouchers in IFS before creating new entries to prevent duplicates. GL accounts and cost dimensions are pre-configured so payments land on valid accounts in IFS.