IFS Cloud and Toast integration

What moves between them

Sales orders, payments, and GL postings flow from Toast into IFS Cloud. After each business day, ml-connector reads Toast orders and payments via the ordersBulk polling endpoint or order_updated webhooks, then posts those transactions into IFS Cloud as sales orders and GL journal entries (vouchers) mapped to the configured company code and GL accounts. Multi-location restaurants require separate Toast-Restaurant-External-ID per location; ml-connector maps each location to its own IFS company code or cost center. Voided orders and checks are excluded from GL posting. Menu items and Toast configuration remain read-only in IFS.

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted and refreshes bearer tokens before expiry on each system. On the Toast side, it retrieves all accessible restaurant locations via GET /partners/v1/restaurants and caches the mapping between location ID and Restaurant-External-ID to enforce multi-location isolation. It polls Toast ordersBulk with businessDate parameter matching each restaurant's configurable closeoutHour (so a 1 AM sale belongs to the prior business date if closeout is 3 AM). Payment records are always polled since Toast webhooks do not cover them. On the IFS side, ml-connector reads the target GL accounts and company codes at setup time, then constructs OData POST requests for VoucherSet (journal entries) with the correct ETag concurrency headers. When a mutation fails with a 412 conflict (ETag mismatch), it retries with a fresh read of the target record. Toast voided orders are filtered (voided==true) before posting. Service charges flagged as gratuity are excluded from net sales GL posting.

A real-world example

A multi-location restaurant group operates 8 Toast POS locations across a metro area and runs IFS Cloud for corporate accounting and supply chain. Before the integration, the finance team pulled daily sales reports from Toast, manually coded each location's net sales and payment splits by payment method into IFS Cloud journal entries, and spent 1-2 hours per day chasing discrepancies between Toast totals and IFS GL balances. With Toast and IFS Cloud connected, each business day's orders and payments post automatically into the correct GL accounts for each location, reconciled by Toast's restaurant ID. The daily manual entry step is eliminated, month-end close starts with GL accounts already in balance, and payment reconciliation is a single query instead of eight separate manual audits.

What you can do

• •Post Toast orders and payments into IFS Cloud as sales orders and GL journal entries, coded to the correct company code and cost center per location.
• •Exclude voided orders, checks, and gratuity-flagged service charges from GL posting so only net sales post.
• •Orchestrate multi-location restaurants by mapping each Toast location ID to the correct IFS company code and GL accounts.
• •Handle OData ETag concurrency on IFS Cloud mutations and retry on 412 Conflict without data loss.
• •Poll Toast ordersBulk and payments on a nightly schedule tied to each location's business date closeout time.

Questions

How does ml-connector handle Toast multi-location restaurants?

Toast requires a separate Restaurant-External-ID for each location. ml-connector retrieves all accessible restaurant locations via GET /partners/v1/restaurants, caches the mapping between location ID and External-ID, and routes each location's orders and payments to the IFS company code you configure for that location. Each location is orchestrated independently so that location-specific sales and payments post to location-specific GL accounts.

Why does ml-connector need to poll Toast payments if Toast supports webhooks?

Toast webhooks cover order and menu changes, but not payments or labor data. ml-connector uses the ordersBulk polling endpoint for comprehensive reconciliation of all payments and orders, triggered each business night. This ensures no payment is missed even if a webhook fails to deliver.

What happens if an IFS Cloud journal entry mutation fails with an ETag conflict?

OData ETag headers enforce optimistic concurrency on IFS Cloud mutations. If a write returns 412 Conflict (the record changed between read and write), ml-connector reads the current record fresh, captures the new ETag, and retries the mutation. This is automatic and transparent, so no data is lost even if another process updates the same GL account.