Microsoft Dynamics GP and Toast integration

What moves between them

Daily sales orders and payments flow from Toast into Microsoft Dynamics GP. ml-connector pulls completed orders and their payments from the previous business date (accounting for each location's closeout hour), filters voided transactions, groups revenue by Toast revenue center and service charge category, and posts the daily total to the GL as a receivables journal entry allocated to the restaurant customer. Labor data can be pulled from Toast shifts and posted as a memo or cost allocation if your GL tracks labor by location. Voided orders, checks, and payments are read but excluded from GL posting.

How ml-connector handles it

ml-connector validates each Toast location's OAuth2 credentials and configures separate authentication sessions per restaurant if multiple locations are enabled. It exchanges the Toast clientId and clientSecret for a bearer token and caches the token to avoid rate-limit penalties on every request. The integration polls Toast's ordersBulk API for the prior business date (adjusting for that location's closeoutHour setting) and filters out voided==true records. Revenue totals are grouped by revenue center and service charge type, then mapped to the corresponding GL revenue account and receivables customer in GP. The on-premises Windows authentication requirement for GP is met via an agent or firewall rule that exposes the GP SBA endpoint, and ml-connector presents the configured Windows domain credentials. Daily GL posting is idempotent: each day's business date is keyed so a replay of the same date does not duplicate entries. Webhook delivery is optional since Toast's push is not guaranteed, so nightly polling acts as the safety net. Every record carries a full audit trail including the raw Toast order data, the mapped GL account, and any filtered lines (voided items, fundraising selections).

A real-world example

A small restaurant group with three locations runs Microsoft Dynamics GP for accounting and inventory on a dedicated Windows Server, and uses Toast POS and management at each location. Before the integration, each location's manager exported a daily sales summary from Toast by hand, emailed it to the head office, and the accounting team entered the total sale amount into a single GL receivables entry for all locations combined, with no breakdown by location. This made it impossible to reconcile individual restaurant performance against GL postings and meant month-end close involved manual lookups to match GL sales to Toast reports. With the integration, each restaurant's completed sales orders and payments flow into GP automatically the morning after close, posted to the GL by location. The accounting team now has item-level detail in the audit trail and can reconcile each restaurant's GL accounts in minutes.

What you can do

• •Pull completed sales orders and payments from Toast by business date and post the daily total to GL as a receivables journal entry.
• •Exclude voided orders, checks, and payments so only confirmed sales post to your ledger.
• •Map Toast revenue centers and service charge categories to GL accounts and customer dimensions for detailed GL allocation.
• •Support multi-location restaurants with separate OAuth credentials per Toast location and business-date adjustment by each location's closeout hour.
• •Maintain full audit trail on every order, including raw Toast data, GL posting reference, and any filtered lines.

Questions

How does ml-connector handle Microsoft Dynamics GP's on-premises requirement and Windows authentication?

ml-connector expects the GP SBA or SOAP endpoint to be exposed via a firewall rule or local agent running on the GP server's network. It authenticates to GP using the Windows domain account credentials (Kerberos or NTLM) configured by the customer, presents those credentials on every request, and respects GP's role-based user security model. The customer remains responsible for creating and maintaining the dedicated Windows domain account used by the integration.

What happens if a Toast order is partially voided or contains fundraising items?

ml-connector filters voided orders (voided==true) entirely before posting. For individual line items marked as voided or fundraising items flagged in selections, the integration excludes them from the revenue total posted to GL. The full order detail including filtered lines is captured in the audit trail for reconciliation.

How does the integration handle multi-location restaurants and different business dates at each location?

Each Toast location is configured with a separate Toast-Restaurant-External-ID, and the integration maintains separate authentication sessions per location. When polling orders, ml-connector accounts for each location's configurable closeoutHour so a sale at 1 AM June 12 belongs to June 11's business date if that location's close-out hour is 3 AM. GL postings are tagged by location so revenue is allocated correctly to each restaurant's GL customer.