Microsoft Dynamics 365 F&O and Toast integration

What moves between them

The flow runs from Toast into Microsoft Dynamics 365 F&O. After a location reaches its closeout hour, ml-connector reads that business day's orders, checks, and payments from Toast, then posts a summarized daily sales journal into the Dynamics general ledger: net sales by sales category, tax collected, discounts, service charges, tips, and tender split by payment type, each mapped to a GL main account and financial dimension. Toast revenue centers and sales categories drive the dimension and account selection. Toast holds no GL, vendors, or AP, so Dynamics stays the system of record and ml-connector never writes financial entries back into Toast. Labor time entries can flow the same direction to support a labor cost accrual when that flow is enabled.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Toast side it exchanges the client ID and secret for a bearer token with userAccessType TOAST_MACHINE_CLIENT, caches it until near expiry to stay under the separate auth rate limit, and sends the Toast-Restaurant-External-ID header on every call so each location is read on its own. On the Dynamics side it requests an Entra ID token against the tenant scope, refreshes it about hourly, and accepts the full environment host per customer since there is no shared URL. It keys sync on Toast businessDate, not wall-clock time, so a 1 AM sale lands on the prior day to match Toast Web; the closeoutHour is read from the restaurant record. Voided orders, voided checks, and voided payments are returned by the API and are filtered out before posting, and gratuity service charges are separated from non-gratuity ones for correct tip handling. Revenue centers and sales categories are mapped to GL accounts and financial dimensions first, and the dimension string is formatted to the Dynamics integrating-applications layout so the journal posts rather than failing silently. Toast has no idempotency key, so ml-connector dedupes on businessDate plus location and a BullMQ jobId, which avoids double-posting a re-read day; Dynamics natural keys are respected so a duplicate journal errors cleanly. Where the Toast order_updated webhook is enabled it can trigger an earlier read, but a nightly /ordersBulk pass by businessDate is the reconciliation safety net because Toast does not guarantee webhook delivery. Toast rate limits return HTTP 429 with Retry-After, and the historical /ordersBulk endpoint is slower still, so reads are throttled, backed off, and retried, and every record carries a full audit trail and can be replayed if a Dynamics post fails.

A real-world example

A regional restaurant group with roughly a dozen locations runs Microsoft Dynamics 365 F&O for corporate finance and Toast as the POS in every venue. Before the integration, each general manager printed the nightly Toast sales summary and a bookkeeper keyed the totals into Dynamics location by location, which meant the ledger lagged a day or two, tax and tip lines were sometimes miscoded, and month-end close stalled while someone reconciled bank deposits against register sales. With Microsoft Dynamics 365 F&O and Toast connected, each location's closed business day posts into Dynamics as a sales journal split by revenue center and sales category, with tax, discounts, tips, and tender on the right accounts. The bookkeeping team stops re-keying, deposits tie to recorded sales, and close starts from numbers that already match Toast.

What you can do

• •Post each Toast business day into Microsoft Dynamics 365 F&O as a daily sales journal split by revenue center and sales category.
• •Record tax collected, discounts, service charges, tips, and tender by payment type against the correct GL accounts and financial dimensions.
• •Read Toast sales by businessDate against the closeout hour and exclude voided orders, checks, and payments so the ledger ties to the Toast closeout.
• •Bridge Toast OAuth client credentials and the Microsoft Entra ID token, and authenticate each location with its own Toast-Restaurant-External-ID.
• •Trigger on the Toast order_updated webhook where enabled, with a nightly reconciliation poll, businessDate dedup, retries, and a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and Toast?

The flow is Toast into Microsoft Dynamics 365 F&O. Each day's orders, checks, payments, tax, discounts, tips, and tender move from Toast into the Dynamics general ledger as a summarized sales journal. Toast has no chart of accounts, vendors, or AP, so Dynamics stays the system of record and ml-connector does not write financial entries back into Toast.

Does Toast push sales, or does ml-connector poll for them?

Both are supported. Toast pushes an order_updated webhook signed with HMAC-SHA256 that can trigger an earlier read, but there is no webhook for payments or labor, and Toast does not guarantee webhook delivery. So the default and reconciliation path is a scheduled /ordersBulk pull by businessDate after the location's closeout hour, which is what posts to Dynamics.

How does the integration keep the Dynamics journal matching the Toast closeout?

It syncs on Toast businessDate rather than wall-clock time, reading the location's closeoutHour from the restaurant record so a late-night sale lands on the correct day, the same way Toast Web reports it. Voided orders, checks, and payments are filtered out before posting, and gratuity service charges are separated from non-gratuity ones. Revenue centers and sales categories map to Dynamics GL accounts and financial dimensions so each journal line lands on a valid account.