Visma and Toast integration

What moves between them

Toast sales orders and payments flow into Visma daily on a business-date reconciliation schedule. Each business date, ml-connector retrieves all orders for that date from Toast, filters out voided orders and payments, and creates GL transactions in Visma that post to the correct GL accounts and dimensions based on Toast revenue center. Service charges and gratuities are handled separately based on Toast classification flags. Reference data such as revenue centers is mapped to Visma GL accounts once during setup. Payments to Toast orders are also synced as GL transactions into Visma. The flow is one-way: Toast to Visma only, since Visma GL transactions are the source of truth and Toast POS has no equivalent GL posting capability.

How ml-connector handles it

ml-connector authenticates to both systems on each run: Visma via OAuth 2.0 client credentials with the ipp-company-id header, and Toast via OAuth 2.0 client credentials followed by the required Toast-Restaurant-External-ID header on all subsequent calls. For multi-location Toast customers, ml-connector retrieves all accessible locations via the Toast partner endpoint and processes each location separately with its own external ID. Toast business dates are calculated per location based on the configurable closeoutHour to ensure orders land on the correct calendar day. All Toast orders returned include voided flag and service charge classification; ml-connector filters voided orders and checks before posting, and treats gratuity service charges as tips rather than net sales. Toast payments are polled because webhooks do not cover payments. Visma write operations require ETag headers for safe updates; ml-connector reads the entity's current ETag before any PUT. When posting GL transactions to Visma, ml-connector maps Toast revenue centers to pre-configured Visma GL accounts and dimensions (cost centers). The reconciliation poll runs once daily after the restaurant's closeout hour and can be retried without duplicate posting because each Toast order carries an externalId field used for deduplication. Visma's 500 call per hour rate limit for test clients is observed. Toast rate limit of 20 req/sec is respected by spacing calls; menu API's 1 req/sec is respected separately. Token caching is implemented on the Toast side to avoid re-authenticating on every request and hitting auth rate limits.

A real-world example

A mid-sized Nordic hospitality group operates 8 Toast locations (restaurants and cafes) across three countries and uses Visma.net ERP for consolidated accounting, invoicing, and financial reporting. Prior to the integration, the accounting team manually exported daily sales reports from Toast each morning, categorized them by revenue center, and entered them into Visma as GL transactions. This process took 30 to 45 minutes per day and was error-prone due to manual categorization and re-keying. Month-end close was delayed as team members reconciled Toast sales totals against Visma to find discrepancies. With Toast and Visma connected, each location's sales post into Visma automatically each morning, allocated to the correct GL accounts by revenue center and business date. The manual export and entry step is eliminated, and the group's consolidated ledger reflects all Toast sales and payments correctly from day one of each month, reducing close time by several days.

What you can do

• •Move Toast daily sales orders into Visma as GL transactions, allocated to GL accounts and dimensions by revenue center.
• •Sync Toast payments to Visma as GL transactions with correct allocation, excluding voided orders and payments.
• •Handle business date calculation per Toast location based on configurable closeout hour, ensuring orders land on the correct calendar day.
• •Manage OAuth 2.0 authentication on both sides and apply Visma ETag requirements on all write operations for safe concurrent updates.
• •Reconcile Toast sales to Visma daily on a schedule, with deduplication via Toast externalId to allow safe retries.

Questions

Which direction does data move between Toast and Visma?

Toast sales orders and payments move into Visma as GL transactions. The flow is one-way: Toast to Visma only. Visma GL transactions are the source of truth for accounting, and Toast POS has no equivalent GL posting capability to write back. Reference data such as revenue center to GL account mappings are established once during setup.

How does ml-connector handle Toast's multi-location and business-date complexity?

ml-connector retrieves all accessible Toast locations via the partner endpoint and processes each separately with its own Toast-Restaurant-External-ID. Business dates are calculated per location based on the configurable closeoutHour setting, so a sale at 1 AM is correctly assigned to the prior day if closeoutHour is 3 AM. Orders are queried by business date and voided flag is checked at source to filter them before posting to Visma.

What authentication and rate-limit handling does ml-connector implement?

ml-connector obtains OAuth 2.0 tokens for both Visma (via ipp-company-id header) and Toast (with userAccessType: TOAST_MACHINE_CLIENT), caching Toast tokens to avoid re-authentication. Visma write operations include the required ETag header read before PUT. Toast rate limits of 20 req/sec and menu API's 1 req/sec per location are respected by spacing calls appropriately.