Oracle JD Edwards and Toast integration

What moves between them

Daily reconciliation flows from Toast into Oracle JD Edwards. Each business date, ml-connector polls Toast's orders and payments via GET /ordersBulk?businessDate=YYYYMMDD, retrieves the full order detail including items, discounts, and service charges, and posts summary journal entries into the JD Edwards GL. Revenue is mapped to GL accounts by revenue center (Toast's RevenueCenter dimension); discounts and service charges are mapped to separate accounts. Payments are classified by tender type and posted to the cash or credit liability GL accounts corresponding to each Toast payment method. Voided orders and checks (identified by the voided==true flag in the Toast API) are excluded from GL posting. Tax collected is segregated and posted to the appropriate tax payable GL account. All postings are tagged with the Toast-Restaurant-External-ID so that multi-location restaurants can reconcile back to Toast by location. Reference data such as revenue centers, discount codes, and tax rates are pre-mapped and validated before any journal entry is created.

How ml-connector handles it

ml-connector stores both credential sets encrypted and authenticates to each system independently. On the Toast side, it caches the OAuth2 bearer token to avoid hitting the auth rate limit, observes Toast's 20 req/sec general rate limit and 1 req/sec menu rate limit per location, and staggers historical order requests with 5-10 second spacing when pulling orders older than one month. On the JD Edwards side, it posts to the customer's AIS Server URL (obtained from the credential), re-authenticates when a session token expires (HTTP 444 signals this), and includes the customer's whitelisted IP in its egress to clear the AIS Server inbound IP allowlist. Orders are polled by business date (which accounts for each Toast restaurant's closeoutHour setting) and checked for the voided flag before posting. All journal entries are posted using a named orchestration or the journal entry batch form service (F0911Z1); batch deduplication uses the Toast order ID as the external reference so that retries do not create duplicate GL entries. Every record is logged to a full audit trail including order ID, payment ID, amount, GL account, and the JD Edwards batch ID. If a downstream GL post fails, the entire batch is replayed from Toast source data without manual intervention.

A real-world example

A regional restaurant group with six locations runs Toast for POS and payments across all units and uses Oracle JD Edwards for consolidated accounting and AP management. Before the integration, the accounting team spent two hours every morning exporting sales reports from each Toast location, consolidating them in a spreadsheet, and manually posting the summary to the GL by revenue center. Month-end close required drilling through six sets of Toast reports and six GL detail lines to reconcile sales, and corrections meant reversing and re-posting in JD Edwards. With Toast and JD Edwards connected, each night the system polls the prior business day from Toast across all locations, maps each location to its GL revenue center, and posts the complete journal. The accounting team now opens JD Edwards to find the GL pre-posted and reconciled to Toast, and can spend their time on variance analysis instead of data entry. Adding a new location is as simple as adding the Toast-Restaurant-External-ID to the mapping table; the sync continues without code changes.

What you can do

• •Post Toast orders, discounts, and service charges to Oracle JD Edwards GL accounts mapped by revenue center and business date.
• •Classify Toast payments by tender type and post to the appropriate cash and credit liability accounts.
• •Exclude voided orders and checks from GL posting and match them by Toast order ID to prevent duplicate entries on retry.
• •Authenticate with Toast OAuth2 bearer tokens and JD Edwards AIS Server session tokens while respecting rate limits and token expiry.
• •Poll Toast by business date (accounting for each location's closeoutHour) with full audit trail and error replay to JD Edwards.

Questions

How does ml-connector handle multi-location Toast accounts with Oracle JD Edwards?

Toast requires a separate Restaurant-External-ID GUID for each location, and ml-connector retrieves all accessible locations via GET /partners/v1/restaurants. Each order and payment is tagged with its source Toast-Restaurant-External-ID and posted to the JD Edwards GL account corresponding to that location's revenue center mapping. A single organization can map many Toast locations to their respective GL cost centers or consolidate all into one if needed.

What prevents duplicate GL entries if a Toast poll fails and is retried?

ml-connector uses the Toast order ID and payment ID as the external reference key when posting to JD Edwards, and includes the JD Edwards batch number in the audit log. Orchestrations or batch form service calls (F0911Z1) are idempotent on the reference key, so retrying the same Toast orders does not create duplicate GL lines. The full order details from Toast are logged so corrections can be traced back to the source.

How does ml-connector work around Toast's business-date complexity and JD Edwards session tokens?

Toast classifies orders by business date (YYYYMMDD) based on each restaurant's configurable closeoutHour setting, not calendar date. ml-connector respects this and polls GET /ordersBulk by the Toast business date. On JD Edwards, session tokens expire every 30-60 minutes (signals HTTP 444), and ml-connector automatically re-authenticates to the AIS Server and resubmits the post. Both systems' constraints are bridged at the ml-connector layer.