Oracle Fusion Cloud ERP and Toast integration

What moves between them

Daily sales orders and payments flow from Toast into Oracle Fusion Cloud ERP. After each restaurant closes (at that location's configurable closeout hour), ml-connector polls Toast for that business date's orders and payments, summarizes them by tender type and revenue category, and posts the daily sales journal into Oracle Fusion's general ledger with lines for gross sales, discounts, service charges, and taxes. Payment records route to accounts receivable or the appropriate clearing account based on tender type. Voided orders, checks, and payments are filtered out; fundraising items are excluded from net sales. Multi-location restaurants are supported; each location is mapped to a separate GL cost center or revenue center in Oracle Fusion. The sync runs once per day after the last location in a multi-location account has closed, ensuring all orders and payments for a business date are complete before posting.

How ml-connector handles it

ml-connector stores both sets of OAuth 2.0 credentials encrypted and manages token caching and refresh for each system independently. On the Toast side, it caches the bearer token to avoid hitting the auth rate limit and respects the 20 req/sec rate limit (slower for menu and historical data). It retrieves all accessible Toast locations via GET /partners/v1/restaurants, maps each to the corresponding GL account or cost center in Oracle Fusion, and reconciles business dates by location closeout hour (a configurable value in Toast). Payments without an Idempotency-Key header use Toast's externalId field for dedup and check if a record was already created before retrying. On the Oracle Fusion side, it constructs the correct pod-specific URL per customer, exchanges the OAuth credentials for a JWT, and posts the daily journal using the journalHeaders and journalLines API. Tender types (card, cash, gift card) are mapped to separate GL accounts; service charges flagged as gratuity are excluded from tip income. The integration includes a nightly safety-net reconciliation poll in case webhooks are missed, and tracks job state per location and business date so a partial failure can be replayed.

A real-world example

A growing restaurant group operates five locations across two cities, each with its own Toast account and closeout schedule. The group uses Oracle Fusion Cloud ERP for consolidated financial reporting and month-end close. Before the integration, the accounting team manually exported each location's daily sales report from Toast every morning, transcribed the totals into a spreadsheet, reconciled discounts and service charges by hand, and entered the summary journal into Oracle Fusion, a process that took 30-45 minutes per day and often contained transcription errors. With Toast and Oracle Fusion connected, the daily sales journal for each location posts automatically after that location closes, mapped to its own cost center in the GL. The finance team receives an email with a summary of what posted, and month-end close starts with all restaurant revenue already in the ledger, eliminating the manual entry step entirely.

What you can do

• •Post daily sales and payment journals from Toast into Oracle Fusion Cloud ERP's general ledger, mapped to the correct GL account per restaurant location.
• •Map Toast tender types (card, cash, gift card) to separate GL accounts for accurate revenue recognition.
• •Handle Toast's multi-location model by retrieving all accessible locations and routing each to the correct GL cost center or revenue center.
• •Filter voided orders and payments, exclude fundraising items, and classify service charges correctly before posting to Oracle Fusion.
• •Run a nightly reconciliation poll to catch any missed webhooks and ensure all orders and payments for a business date are posted before the next close.

Questions

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

ml-connector retrieves all accessible Toast locations via GET /partners/v1/restaurants and maps each location to a separate GL cost center or revenue center in Oracle Fusion. Each location's business date is calculated using that location's configurable closeout hour (a sale at 1 AM belongs to the prior date if closeout is 3 AM). The nightly reconciliation poll waits for the last location in the group to close before posting the consolidated journal.

What happens to voided orders, payments, and service charges?

ml-connector filters out voided orders, checks, and payments before posting to Oracle Fusion (they are returned by Toast with voided==true). Service charges flagged as gratuity (gratuityServiceCharge:true) are excluded from tip income and routed separately. Fundraising items flagged in menu selections are also excluded from net sales.

How does the integration manage OAuth 2.0 token caching and rate limits?

ml-connector caches the bearer token for both Toast and Oracle Fusion to avoid hitting auth rate limits on every request. On the Toast side it respects the 20 req/sec limit (with slower rates for menu and historical data). On the Oracle Fusion side it refreshes the JWT when the one-hour TTL expires and constructs the correct pod-specific URL per customer so that authentication happens once per pod, not per location.