Sage 100 and Toast integration

What moves between them

Sales orders and customer payments move from Toast into Sage 100's accounts receivable and general ledger. After each business day close at a restaurant-configurable time, ml-connector retrieves the day's completed orders and payments from Toast, maps Toast restaurant locations to Sage 100 company codes and revenue centers to GL accounts, and posts the net sales and payments as AR invoices and GL journal entries in Sage 100. Labor expenses from Toast shifts are posted as cost allocations to the appropriate GL accounts mapped from Toast's labor classifications. Toast data is read-only, so ml-connector never writes back to Toast, and it performs nightly reconciliation polling as a safety net since Toast webhooks do not guarantee delivery.

How ml-connector handles it

ml-connector stores Toast OAuth2 credentials (clientId and clientSecret) encrypted and refreshes the bearer token before expiration, caching it to avoid hitting Toast's authentication rate limits. It retrieves Toast restaurant configuration on startup to map Toast-Restaurant-External-ID values to Sage 100 company codes, and it caches Toast menu and revenue center configuration so labor expense allocations land on GL accounts that exist in the current Sage 100 chart. On the Sage 100 side, ml-connector connects to the customer's on-premises SOAP endpoint at the stored instance URL, authenticates with username and password per call, and translates Toast order records into Sage 100 customer invoices, payment records, and labor cost journal entries using the multi-segment GL account code format specific to that customer's configuration. It polls Toast for completed orders each night at a time you configure that aligns with the restaurant's closeoutHour, handling the fact that Toast orders are assigned to business dates based on that closeout time. Toast's rate limits are respected via request queuing and exponential backoff on 429 responses, and Sage 100's COM record-locking constraints are handled by retrying with jitter when conflicts occur. Every order, payment, and GL posting is logged with full audit trail and can be replayed if downstream Sage 100 posting fails.

A real-world example

A multi-location casual dining operator runs Toast on the cloud for POS and labor management at five restaurants and Sage 100 on a Windows server in the back office for accounting and inventory. Before integration, the accounting team pulled sales reports from Toast each morning and manually entered the prior day's net sales, tax, and payment allocations into Sage 100 by hand, then reconciled payment batches against Toast's settlement records. With Sage 100 and Toast connected, each restaurant's nightly closeout automatically flows into Sage 100 as AR invoices and GL journal entries posted to the correct revenue centers and expense accounts, and payment records are reconciled without manual entry. Month-end close is faster because the daily sales totals and GL balances are already in agreement.

What you can do

• •Post Toast daily restaurant sales as AR invoices in Sage 100, mapped to customer records by location and reconciled against payment settlements.
• •Flow customer payments from Toast payment processors into Sage 100 AR with full audit trail and memo from the original Toast transaction.
• •Allocate Toast labor shifts and costs to Sage 100 GL accounts by cost center and job code, with posting on the restaurant's configured business date.
• •Authenticate Toast via OAuth2 client credentials and map multi-location restaurant identifiers to Sage 100 company codes, handling on-premises SOAP access and COM locking.
• •Reconcile nightly via scheduled polling from Toast's orders API, respecting rate limits and restaurant closeout hours, with full audit trail and replay-on-failure guarantees.

Questions

How does ml-connector handle the mapping between Toast restaurant locations and Sage 100 company codes?

ml-connector retrieves the list of accessible Toast restaurants via the Toast partners API during setup and displays them for configuration. You map each Toast location to a Sage 100 company code in ml-connector's UI. When an order arrives from Toast, ml-connector uses the restaurant identifier to look up the correct Sage 100 company code and GL account format, ensuring every transaction posts to the correct company and account structure. This mapping is cached and refreshed on each reconciliation cycle.

What happens if Sage 100's on-premises server is down or unreachable?

ml-connector detects connection failures to Sage 100's SOAP endpoint and pauses posting with a detailed error log. Toast orders are queued in ml-connector's database until Sage 100 is reachable again. When the connection is restored, ml-connector resumes posting from the queue, using the stored externalId or order reference to prevent duplicate entries. Full audit trail captures the outage and recovery.

Does ml-connector support Toast's webhook push events, or does it always poll?

ml-connector uses nightly polling as the primary reconciliation method to ensure completeness, because Toast webhooks do not guarantee delivery and payments have no webhook events. If you enable Toast webhooks in your Toast settings, ml-connector can subscribe to order and menu change events as a supplemental notification layer for faster updates. However, polling remains the safety net that reconciles any orders missed by webhooks.