IFS Cloud and Stampli integration

What moves between them

The flow runs from Stampli into IFS Cloud. On a schedule you define, ml-connector polls Stampli's SFTP directory for new or updated invoice files (CSV or XML format). For each invoice, it reads the vendor, amount, GL coding, and approval status. It then looks up or creates the matching Stampli vendor record in IFS Cloud, and posts the invoice as a supplier invoice (PostingProposalHeadSet) and a GL voucher (VoucherSet) allocated to the correct cost center and company code. Purchase order and vendor reference data is synchronized in the same direction when available.

How ml-connector handles it

ml-connector stores Stampli's SFTP credentials encrypted and polls the outbound directory on an interval you control (typically every 15 to 30 minutes to match Stampli's 5-minute refresh rate). For each invoice file, it parses the CSV or XML, deduplicates by invoice number to avoid re-posting, and validates that the GL account and cost center exist in the IFS tenant before creating a PostingProposalHeadSet record. On the IFS side, it obtains an OAuth2 bearer token from the tenant-specific auth endpoint, and makes all requests to the tenant-specific OData base URL. Because IFS requires an ETag on mutations, ml-connector reads each voucher or invoice record first to capture the @odata.etag value, then POSTs with that etag in the If-Match header to enforce concurrency. IFS enforces a 1000-request-per-minute rate limit and a 5000-element page size on OData queries, so ml-connector backs off on HTTP 429 and paginates large result sets. The company code must be provided in the connector configuration, since almost every financial entity in IFS requires it.

A real-world example

A mid-sized manufacturing company runs IFS Cloud for procurement and finance across three plants and uses Stampli to automate accounts payable. Before the integration, the AP team approved invoices in Stampli, then exported invoice registers every week and manually entered supplier invoices into IFS, a process that took two to three hours and introduced data entry errors. With Stampli and IFS Cloud connected, each approved invoice in Stampli flows automatically into IFS as a supplier invoice and GL voucher on the correct cost center within minutes. The AP team now focuses on exception handling and vendor disputes rather than manual invoice entry, and the month-end close starts with all invoices already recorded and matched.

What you can do

• •Post Stampli-approved invoices into IFS Cloud as supplier invoices (PostingProposalHeadSet) with GL voucher entries (VoucherSet) on the correct cost center and company code.
• •Synchronize vendors from Stampli into IFS Cloud and validate vendor relationships so invoices land against the correct supplier account.
• •Deduplicate invoices by invoice number to prevent re-posting on polling retry.
• •Authenticate IFS Cloud via OAuth2 with tenant-specific URLs and handle ETag concurrency on all mutations.
• •Poll Stampli's SFTP directory on a schedule you define, with retries and a full audit trail on every invoice and voucher.

Questions

How does the integration handle Stampli's file-based API and IFS Cloud's OData endpoints?

ml-connector polls Stampli's outbound SFTP directory for CSV or XML invoice exports on an interval you control. It parses those files, deduplicates invoices by number, and posts each one into IFS Cloud via the OData API. IFS requires an ETag header on mutations, so ml-connector reads the target record first to capture the etag, then includes it on the POST or PATCH.

Which invoices and vendors sync, and in which direction?

Invoices and vendors flow from Stampli into IFS Cloud. Approved invoices in Stampli are posted as PostingProposalHeadSet records and GL vouchers in IFS, allocated to the cost center and GL account you map. Vendors are synchronized so that invoice supplier references resolve correctly. Reference data such as purchase orders can also sync where available.

What happens if an invoice fails to post to IFS or Stampli SFTP polling times out?

Every invoice and polling attempt is logged with a full audit trail. If a post fails (e.g., GL account does not exist, cost center is invalid, or IFS returns a transient error), ml-connector retries with exponential backoff. Failed records are marked for replay once the underlying issue is resolved so no invoice is lost.