IFS Cloud and Zuora integration

What moves between them

Invoices and payments flow from Zuora into IFS Cloud. When a Zuora invoice is posted or a payment is received (electronic only), ml-connector captures the webhook notification, fetches the full invoice or payment record from Zuora, maps the Zuora account to the corresponding IFS Cloud GL account and company code, and creates a GL voucher (journal entry) in IFS Cloud. Refunds and credit memos are tracked but not posted as GL records until mapped by the customer. The sync runs on Zuora's webhook push schedule; no polling is required on the Zuora side once webhooks are configured.

How ml-connector handles it

ml-connector stores Zuora and IFS Cloud OAuth2 credentials encrypted and refreshes both tokens when a call returns 401. For every Zuora invoice or payment webhook received, ml-connector fetches the full record from Zuora using the Zuora API (since webhook payloads carry ID only), maps the Zuora account ID to the customer-configured IFS Cloud GL account and company code pair, and then mutates IFS Cloud's VoucherSet by first reading the entity to capture the ETag header, then POSTing the GL voucher with that ETag value (OData's optimistic concurrency requirement). If an account mapping is missing, the record is held in the audit log until the customer adds the mapping. Zuora electronic payment notifications fire for card and bank transfers only, not for manual or external payments. IFS Cloud's 5000-element result limit and ETag requirement are handled transparently; ml-connector never expands nested collections beyond safe size and always captures concurrency tokens before mutation. Both platforms enforce rate limiting (1000 requests per minute for IFS Cloud, 50,000 requests per minute for Zuora production), so ml-connector implements exponential backoff with jitter on HTTP 429 responses. Every record carries a full audit trail and can be replayed if a downstream IFS Cloud mutation fails.

A real-world example

A mid-sized SaaS company runs Zuora for subscription billing and order management, and uses IFS Cloud for enterprise finance and cost center tracking. Before the integration, the finance team exported invoices and payment records from Zuora every week and re-entered them manually into IFS Cloud as GL vouchers, then mapped them to cost centers by hand. This was error-prone and delayed month-end close by several days. With Zuora and IFS Cloud connected, each invoice posted in Zuora flows directly into IFS Cloud as a GL entry, automatically mapped to the correct GL account based on the customer's subscription product type. Payments received flow the same way, and the finance team no longer manually re-enters billing data. Month-end close now starts with all billing records already in the ledger, correctly accounted.

What you can do

• •Post Zuora invoices into IFS Cloud as GL vouchers when invoices are marked Posted, mapped to the correct GL accounts and company codes.
• •Capture Zuora electronic payment records and create corresponding GL entries in IFS Cloud, reconciling billing with the general ledger.
• •Validate account-to-GL mappings at sync time and hold records with missing mappings in the audit log until the customer provides the mapping.
• •Handle OData ETag concurrency headers and company code requirements transparently, so billing records from Zuora create valid GL vouchers in IFS Cloud.
• •Track refunds and credit memos from Zuora, with configurable GL posting rules for debit memos and adjustments.

Questions

Does this integration post invoices as soon as they are created in Zuora, or only when marked Posted?

Only when invoices are marked Posted in Zuora. ml-connector listens for Zuora's Invoice Posted webhook event. Drafts and unpublished invoices do not trigger the sync. Payments flow when marked Processed, which covers electronic payments only (card and bank transfer); manual and external payments are captured for audit but not posted automatically.

How does ml-connector handle the OData ETag and company code requirements for GL vouchers in IFS Cloud?

Every GL voucher create in IFS Cloud requires an OData ETag header for optimistic concurrency control. ml-connector first reads the target entity set to capture the ETag, then performs the POST with that header value. Company codes are mandatory on all IFS Cloud financial entities. ml-connector requires the customer to map each Zuora account ID to an IFS Cloud GL account and company code pair at setup time; if a mapping is missing when a record arrives, it is held in the audit log until the mapping is added.

What happens if Zuora sends a webhook notification for a payment that ml-connector cannot map to an IFS Cloud account?

The payment record is captured and logged in the audit log with a status of 'mapping-missing'. It does not create a GL entry until the customer adds the account mapping in the connector configuration. Once the mapping is added, the payment can be replayed to create the GL voucher. This prevents orphaned or misallocated entries in the general ledger.