Wave Accounting and Toast integration

What moves between them

Orders and payments flow from Toast into Wave Accounting on a schedule tied to each restaurant's business date. After each Toast closeoutHour, ml-connector polls orders and payments from Toast, maps them to Wave customers (one per restaurant location), and creates Wave transactions posting the day's revenue to income accounts and receivables based on payment method. Service charges and discounts are mapped separately to their respective accounts. Toast webhooks provide near-real-time notification of order changes; ml-connector validates against the scheduled reconciliation poll to ensure no orders are missed.

How ml-connector handles it

ml-connector stores Toast and Wave OAuth credentials encrypted and maintains separate bearer tokens for each system, refreshing Toast tokens via client credentials grant and Wave tokens via refresh token. Since Wave has no push notification for order-to-invoice mapping, ml-connector polls Toast at a daily frequency keyed to each restaurant's business date and closeoutHour. Toast requires the Toast-Restaurant-External-ID header on every request, so ml-connector retrieves the full list of accessible restaurants once per session via GET /partners/v1/restaurants and caches it. For each restaurant's daily orders, ml-connector filters voided orders, sums revenue by account category (food, beverages, services), maps to Wave's chart of accounts, and posts a single daily transaction per restaurant. Wave's 2-hour OAuth token expiry is handled by caching the token and refreshing when a request returns 401. Toast's rate limits (20 requests per second, 1 per second for menus) are observed via backoff and jitter on 429 responses. Every order and payment carries a full audit trail in both systems and can be replayed if a downstream posting fails.

A real-world example

A small restaurant group operates three Toast locations (a downtown cafe, a suburban diner, and a catering kitchen) and uses Wave Accounting for bookkeeping. Before the integration, the manager exported Toast sales reports each day and manually entered them as Wave transactions, categorizing by revenue type (food, beverages, services) and assigning each location to a separate customer. Reconciling Week-end sales against the Toast P&L and Wave revenue accounts took two hours every Friday. With Wave and Toast connected, each morning after close Toast orders post automatically into Wave as daily transactions per location, mapped to the correct revenue accounts and assigned to the location's Wave customer. Week-end reconciliation is now five minutes: the manager confirms the day-by-day orders match the Toast dashboard, then approves the batch of Wave transactions.

What you can do

• •Post Toast orders as daily transactions into Wave Accounting, grouped by restaurant location and revenue category.
• •Map Toast service charges, discounts, and payment methods to separate Wave income and receivable accounts.
• •Handle multi-location Toast accounts where each restaurant is represented as a distinct Wave customer.
• •Refresh OAuth tokens for both Toast (client credentials) and Wave (authorization code flow with offline access).
• •Reconcile via scheduled polling on each restaurant's business date, plus webhook validation for near-real-time order change notification.

Questions

How does ml-connector handle Toast's multi-location model?

ml-connector queries all accessible restaurants via GET /partners/v1/restaurants on session startup and caches the list. Each restaurant has a unique Toast-Restaurant-External-ID, which ml-connector includes on every API call. Orders for each restaurant are polled separately and posted to Wave as transactions assigned to a distinct Wave customer per location, so your chart of accounts shows revenue by both account type and restaurant.

What happens if Toast's business date does not match Wave's calendar day?

Toast's business date (YYYYMMDD) is determined by each restaurant's configurable closeoutHour. A sale at 1 AM on June 12 belongs to June 11 if the restaurant's closeoutHour is 3 AM. ml-connector polls Toast using the restaurant's business date and posts the orders to Wave on the same calendar date, so Wave transactions reflect the day the sale actually occurred at that location.

How are voided orders and payments handled?

Toast returns voided orders, checks, and payments in API responses with a voided flag set to true. ml-connector filters these out before posting, so only active sales and payments appear in Wave. If an order is voided in Toast after ml-connector has already posted it, the order webhook triggers a notification, and ml-connector replays the daily reconciliation to detect the change and post a reversal transaction in Wave.