Which direction does data move between IFS Cloud and Square?

The main flow is Square into IFS Cloud. Payments, refunds, and orders move from Square into IFS Cloud's GL and vouchers, while vendor master data is aligned in both directions. GL journal entries are posted only into IFS Cloud; Square is read-only for financial reporting purposes.

How does ml-connector handle IFS Cloud's OData ETag requirement for mutations?

OData ETag is a concurrency control mechanism that requires reading a record first to capture its @odata.etag value, then including that etag in the If-Match header when updating. ml-connector reads the GL account or voucher record before posting, captures the ETag, and includes it in every mutation to ensure optimistic concurrency and prevent lost updates.

How does the integration handle Square's 30-day access token expiry?

ml-connector stores refresh tokens encrypted and monitors token expiry. It proactively refreshes the access token before expiry so payment and order webhooks are always received without interruption. If a token expires in flight, ml-connector detects the 401 response and refreshes immediately before retrying the request.

IFS CloudSquare

IFS Cloud and Square integration

IFS Cloud runs your enterprise finance, manufacturing, procurement, and supply chain. Square processes your payments and commerce. Connecting the two keeps your financial records synchronized without manual re-keying. Payments received through Square post into IFS Cloud's general ledger aligned to the correct GL accounts and cost centers, and purchase orders and vendor payments move from Square back to IFS Cloud for reconciliation. ml-connector handles the different APIs and concurrency models on each side.

How IFS Cloud works

IFS Cloud exposes vendors, purchase orders, supplier invoices, GL accounts, and journal entries through OData v4 REST APIs at tenant-specific URLs (https://<tenant>.ifs.cloud/main/ifsapplications/projection/v1/<ProjectionName>.svc/<EntitySet>). Authentication uses OAuth2 Client Credentials against a tenant-specific auth realm, with tokens valid for approximately 60 minutes. IFS Cloud has no standard webhook API, so records are polled on a schedule. Mutations require OData If-Match ETag headers for optimistic concurrency control. The API enforces a 1000-requests-per-minute rate limit and recommends keeping result sets under 5000 elements per request. Company code is mandatory on all financial entities.

How Square works

Square exposes payments, refunds, invoices, orders, vendors, and inventory through a versioned REST API at https://connect.squareup.com/v2. It authenticates via OAuth2 Authorization Code flow or Personal Access Token, both using Bearer tokens that expire in 30 days with refresh token support. Square publishes webhooks for payment, refund, order, invoice, and inventory events with HMAC-SHA256 signature verification. The Vendors API is in beta, and there is no purchase orders or GL accounts API, so inventory and vendor workflows are modeled through Orders and Vendor references. Square is commerce-layer only and requires mapping to external accounting systems for GL reconciliation.

What moves between them

The main flow moves payments, refunds, and order data from Square into IFS Cloud. After each payment settlement or refund in Square, ml-connector reads the payment record and posts a corresponding GL journal entry (voucher) into IFS Cloud's general ledger, allocated to the cost center for the merchant location. Order fulfillments and vendor transactions from Square are written as purchase order receipts or payment proposals in IFS Cloud. Vendor master data is aligned in both directions so Square vendors match IFS Cloud suppliers. GL entries are posted only into IFS Cloud; Square is read-only for financial reporting.

How ml-connector handles it

ml-connector stores OAuth2 credentials and refresh tokens encrypted for both systems. On the Square side it subscribes to payment, refund, and order webhooks and verifies signatures with the HMAC-SHA256 secret. On the IFS Cloud side it polls the OData API on a schedule aligned with your daily settlement batch. Before posting any GL journal entry into IFS Cloud, ml-connector reads the account record to capture its ETag, then mutates with that ETag in the If-Match header to satisfy OData's optimistic concurrency requirement. It maps Square location IDs to IFS Cloud cost centers and validates that the target GL account and cost center exist before posting. Square access tokens expire in 30 days, so ml-connector refreshes proactively before expiry. IFS Cloud rate limits at approximately 1000 requests per minute per tenant, so ml-connector backs off on HTTP 429 responses with exponential jitter. Every record carries a full audit trail and can be replayed if a downstream mutation fails.

A real-world example

A mid-sized retail operation runs Square for all point-of-sale payments and online orders across 12 locations, and uses IFS Cloud for procurement, supply chain, and enterprise finance. Before the integration, the finance team exported daily settlement reports from Square and manually entered the payment summaries into IFS Cloud, then allocated each payment to the correct location cost center and GL account. With Square and IFS Cloud connected, each daily settlement automatically posts into IFS Cloud's GL, allocated to the matching location cost center, and order fulfillments sync back for inventory and accrual reconciliation. Month-end close starts with payment and order data already reconciled, eliminating manual re-keying and reducing reconciliation time by several days.

What you can do

Post Square payments and refunds into IFS Cloud GL journal entries, allocated to the correct location cost centers.
Sync Square order fulfillments and vendor transactions as purchase order receipts and payment proposals in IFS Cloud.
Align Square vendor master data with IFS Cloud suppliers in both directions.
Handle OData ETag concurrency control and OAuth2 token refresh on both systems, with retries on rate limits and network errors.
Receive Square webhooks for payments, refunds, and orders, and poll IFS Cloud on a daily or custom schedule with a full audit trail on every record.

Questions

Which direction does data move between IFS Cloud and Square?: The main flow is Square into IFS Cloud. Payments, refunds, and orders move from Square into IFS Cloud's GL and vouchers, while vendor master data is aligned in both directions. GL journal entries are posted only into IFS Cloud; Square is read-only for financial reporting purposes.
How does ml-connector handle IFS Cloud's OData ETag requirement for mutations?: OData ETag is a concurrency control mechanism that requires reading a record first to capture its @odata.etag value, then including that etag in the If-Match header when updating. ml-connector reads the GL account or voucher record before posting, captures the ETag, and includes it in every mutation to ensure optimistic concurrency and prevent lost updates.
How does the integration handle Square's 30-day access token expiry?: ml-connector stores refresh tokens encrypted and monitors token expiry. It proactively refreshes the access token before expiry so payment and order webhooks are always received without interruption. If a token expires in flight, ml-connector detects the 401 response and refreshes immediately before retrying the request.

Connect IFS Cloud and Square

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started