How does Toast multi-location routing work with Odoo?

Toast requires a separate restaurant GUID (Toast-Restaurant-External-ID header) for each location. ml-connector retrieves all accessible locations on setup and polls each location separately on the same business date schedule. Each location's sales and labor are mapped to its own cost center or location dimension in Odoo so the GL reflects which restaurant each transaction came from.

What happens when a Toast order is voided or a payment is reversed?

Toast returns voided orders, checks, and payments in API responses but flags them with a voided=true field. ml-connector filters these out before posting to Odoo, so reversals do not create double-entry errors in the GL. If a previously posted transaction is voided after the nightly reconciliation, a followup audit report flags the mismatch.

Does Toast business date match Odoo's accounting date?

Not automatically. Toast business date is configurable per restaurant (closeoutHour can be 3 AM, 4 AM, etc.), so a sale at 1 AM may belong to the prior calendar day. ml-connector adjusts the Toast business date based on each restaurant's closeoutHour setting and maps it to the Odoo posting date. If your restaurants have different close times, each gets its own business date offset in the mapping configuration.

OdooToast

Odoo and Toast integration

Odoo runs your back office: accounting, inventory, and HR. Toast runs your restaurant: POS, orders, and payments. Connecting the two keeps your sales register and your general ledger in sync. Daily sales and labor are posted from Toast into Odoo's GL without re-keying, mapped to the revenue and cost centers that match your restaurant's actual structure. ml-connector handles Toast's business-date accounting, restaurant routing, and the OAuth2 credential flow that every API call requires.

How Odoo works

Odoo is an open-source enterprise resource planning suite available as Odoo Online (SaaS), Odoo.sh (PaaS), or self-hosted. It exposes accounting moves, partners, purchase orders, payments, GL accounts, analytic accounts, products, and employees through XML-RPC and JSON-2 REST APIs. Authentication uses an API key paired with username login. Odoo Online instances have unique subdomains, while self-hosted instances use custom domains. API access requires a Custom pricing plan, and all API calls respect the integration user's Odoo access rights and record rules. Polling with high-water-mark filtering on write_date is the recommended approach for production workloads.

How Toast works

Toast is a cloud restaurant management platform that exposes sales orders, checks, payments, menu items, employees, shifts, and configuration data through REST APIs. Authentication uses OAuth2 client credentials, and every API request requires both a bearer token and a Toast-Restaurant-External-ID header that identifies which location is being accessed. Toast provides both webhooks for real-time events (order updates, menu changes) and polling endpoints. Payment and labor data are available only through polling, not webhooks. Rate limits are 20 requests per second default, with stricter limits on menu and historical data APIs. Multiple Toast locations require separate API calls per restaurant GUID.

What moves between them

Daily sales and labor flow from Toast into Odoo. After each business date closes in Toast (per the restaurant's configurable closeoutHour), ml-connector polls Toast for all orders, checks, and payments for that date, filters out voided transactions and fundraising items, aggregates sales by revenue center and employee, and posts the daily sales journal and labor cost allocations into Odoo's general ledger. Revenue is mapped to Odoo sales GL accounts; labor costs are allocated to cost centers by shift. Data flows one direction: Toast to Odoo. Odoo menu and GL configuration flows back to Toast once per day for validation.

How ml-connector handles it

ml-connector authenticates to Toast with OAuth2 client credentials and caches the bearer token to avoid hitting the authentication rate limit on every call. Each Toast location is routed separately via the Toast-Restaurant-External-ID header. Daily reconciliation uses Toast's business date (YYYYMMDD) adjusted for the restaurant's closeoutHour setting, so a sale at 1 AM belongs to the prior business date if the restaurant closes at 3 AM. Voided orders, checks, and payments are filtered out, and fundraising items flagged in menu selections are excluded from net sales. Service charges classified as gratuities are separated for tip reporting. Toast does not provide an Idempotency-Key header, so ml-connector uses the order externalId field to deduplicate on retries and check if the order was already created. Toast webhooks for orders and menu are optional but reduce reconciliation scope; payments and labor still require nightly polling. Every sales journal and labor allocation carries full detail and can be replayed if a downstream GL posting fails.

A real-world example

A three-location restaurant group operates Toast for POS and labor management across multiple shifts and revenue centers (dine-in, takeout, delivery). The operations team exports daily sales reports from Toast and manually enters GL journals into Odoo, then reconciles tips and labor allocations across locations. With Toast and Odoo connected, each business date's sales and labor automatically post to Odoo, segregated by location and revenue type. The accounting team starts each day with GL balances already updated, eliminating the manual entry and reducing the reconciliation cycle from hours to minutes.

What you can do

Post Toast daily sales journals to Odoo GL by revenue center, filtering voided transactions and fundraising items.
Allocate Toast labor shifts and employees to Odoo cost centers and GL accounts based on configured mappings.
Handle Toast multi-location routing via separate restaurant GUIDs and business-date closeout hours specific to each location.
Authenticate with Toast OAuth2, cache tokens to stay within rate limits, and validate GL accounts in Odoo before posting.
Poll Toast each business date on a schedule you control, with full audit trail and replay capability on every transaction.

Questions

How does Toast multi-location routing work with Odoo?: Toast requires a separate restaurant GUID (Toast-Restaurant-External-ID header) for each location. ml-connector retrieves all accessible locations on setup and polls each location separately on the same business date schedule. Each location's sales and labor are mapped to its own cost center or location dimension in Odoo so the GL reflects which restaurant each transaction came from.
What happens when a Toast order is voided or a payment is reversed?: Toast returns voided orders, checks, and payments in API responses but flags them with a voided=true field. ml-connector filters these out before posting to Odoo, so reversals do not create double-entry errors in the GL. If a previously posted transaction is voided after the nightly reconciliation, a followup audit report flags the mismatch.
Does Toast business date match Odoo's accounting date?: Not automatically. Toast business date is configurable per restaurant (closeoutHour can be 3 AM, 4 AM, etc.), so a sale at 1 AM may belong to the prior calendar day. ml-connector adjusts the Toast business date based on each restaurant's closeoutHour setting and maps it to the Odoo posting date. If your restaurants have different close times, each gets its own business date offset in the mapping configuration.

Connect Odoo and Toast

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started