Sage 50 and Toast integration

What moves between them

Sales orders and payments flow from Toast into Sage 50 GL on a nightly business-date reconciliation. Toast's businessDate field accounts for each location's configurable closeout hour, so a sale at 1 AM belongs to the prior date if closeout is 3 AM. Labor shift hours flow the same direction, mapped to labor cost accounts in Sage 50. Because Sage 50 is read-only on the Toast side, no data flows back to the POS.

How ml-connector handles it

ml-connector runs a local SDK session against Sage 50 to query the company data files and post GL entries, and authenticates Toast via OAuth2, caching the bearer token to avoid hitting the auth rate limit. It reconciles Toast orders and payments each business date, summing by revenue category and payment type, then posts compound GL entries into Sage 50 with offsetting accounts (sales revenue contra to receivables or bank, depending on payment status). It filters voided orders and excludes fundraising items per Toast API rules. For labor, it sums shift hours by wage type and posts to Sage 50 labor expense accounts. Because Toast's multi-location restaurants require a separate Restaurant-External-ID per location, ml-connector makes individual API calls per location and merges the GL into a single Sage 50 company file. It polls nightly rather than relying on Toast webhooks since webhooks are not guaranteed delivery. If a GL post fails, the order record is flagged and can be replayed the next night.

A real-world example

A regional restaurant group with five locations runs Toast at each site for POS, ordering, and shift management. Finance uses Sage 50 on a Windows server for GL accounting and month-end close. Previously, the accountant collected daily sales and labor reports from Toast's web UI and manually entered totals into Sage 50 GL accounts every morning, a 30-minute daily task that introduced transcription errors and delayed close. With Sage 50 and Toast connected, each night's nightly reconciliation poll posts that day's sales, payments, and labor costs into GL accounts by location-specific cost center, and month-end close begins with revenues and labor already reconciled. The accountant now uses that half-hour for variance analysis instead of re-entry.

What you can do

• •Post Toast daily sales by revenue category into Sage 50 GL accounts, reconciled by business date and location.
• •Sync Toast payments into Sage 50 bank and receivables accounts, flagged by payment type (card, cash, check).
• •Flow labor shift hours from Toast into Sage 50 labor expense accounts by wage type and location cost center.
• •Handle Toast OAuth2 token refresh, multi-location Restaurant-External-ID routing, and Sage 50 local SDK session setup without interactive login.
• •Nightly reconciliation polling with order voided-record filtering and fundraising-item exclusion per Toast API constraints.

Questions

How does ml-connector interact with Sage 50 if it is desktop-only with no cloud API?

ml-connector runs a local Windows process with access to the Sage 50 company data files on the same machine or LAN. It uses the Sage 50 .NET SDK (US edition) or Sage Data Objects COM layer (UK edition) to query GL accounts and post transactions. The process authenticates with local Windows username and password plus company file path, the same credentials a Sage 50 desktop user would use.

Does ml-connector handle Toast's multi-location setup?

Yes. Each Toast location requires a separate Restaurant-External-ID. ml-connector retrieves all accessible locations via Toast's partner API, makes individual API calls per location to fetch orders and payments, and posts the results into Sage 50 GL accounts tagged by location cost center so revenue and labor are tracked separately. This works for restaurants with single or multiple locations.

Why nightly reconciliation polling instead of Toast webhooks?

Toast webhooks are not guaranteed delivery, and payments and labor shifts have no webhooks at all, so polling is required. ml-connector reconciles each business date via a nightly poll, sums orders and payments by category, and posts compound GL entries. If a post fails, the record is flagged and can be replayed the next night, providing a safety net that webhooks alone cannot guarantee.