DATEV and Toast integration

What moves between them

The flow runs from Toast into DATEV. After each business day closes, ml-connector reads Toast orders and the payments captured against them by business date, drops voided orders, checks, and payments, and aggregates net sales, tax collected, discounts, service charges, and tender by type. It maps Toast revenue centers and sales categories to DATEV general ledger accounts and posts the result as an EXTF CSV booking batch to DATEV Rechnungswesen, with a credit-and-debit pair per total. Invoice or daily-summary PDFs can also be uploaded to DATEV Unternehmen Online through the documents product. DATEV bookings are write-only and the chart of accounts is not readable, so ml-connector never reads ledger entries back into Toast.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Toast side it exchanges the client ID and secret for a TOAST_MACHINE_CLIENT bearer token, caches it until near expiry to stay under the separate login rate limit, and sends the Toast-Restaurant-External-ID for each location on every request. On the DATEV side it carries an OAuth access token obtained through the interactive Authorization Code with PKCE login, where the state value is at least twenty characters, and it refreshes that token every 900 seconds by sending the client_id only, never the client_secret. Sales are pulled with businessDate so the totals match what Toast Web reports show under the location's closeout hour, paging ordersBulk at one hundred per page and following the Link next header. Voided records are filtered and gratuity service charges are separated from non-gratuity ones before posting. The DATEV account numbers under SKR03 or SKR04 are configured per client up front, since the chart cannot be pulled from the API, and each revenue center and sales category is mapped to one of them. The booking batch is written as a deterministic EXTF CSV filename in UTF-8 with precomposed characters, because DATEV rejects a non-precomposed file silently and treats a repeated filename plus document type as a duplicate, which makes a re-submitted day safe rather than double-booked. The submission is an asynchronous job, so ml-connector polls the import job with exponential backoff and jitter until it completes or fails. Where Toast order webhooks are enabled they can trigger an early pull, but the nightly business-date pass is the authority since webhook delivery is not guaranteed. Every record carries a full audit trail and can be replayed if a DATEV import fails.

A real-world example

A regional restaurant group of about a dozen locations runs Toast at every site and books to DATEV through its Steuerberater. Before the integration, a bookkeeper exported each location's daily sales report from Toast, re-keyed the net sales, VAT, and card-versus-cash splits into a DATEV booking batch by hand, and reconciled tip handling line by line, which left several days unbooked at any time and made the VAT return a scramble. With DATEV and Toast connected, each location's closed business day flows into DATEV as an EXTF booking batch, split across the configured sales and tax accounts, with voided orders removed and gratuity charges kept separate. The bookkeeper reviews exceptions instead of typing totals, the books stay current per location, and the VAT figures tie back to what Toast actually recorded.

What you can do

• •Post each closed Toast business day into DATEV as an EXTF booking batch, split across the configured sales, tax, and tender accounts.
• •Filter voided orders, checks, and payments, and separate gratuity service charges from non-gratuity ones before booking.
• •Map Toast revenue centers and sales categories to DATEV SKR03 or SKR04 general ledger accounts configured per client.
• •Bridge Toast machine-to-machine client credentials and DATEV interactive OAuth with PKCE, refreshing each token before it expires.
• •Submit booking files under deterministic filenames and poll the asynchronous DATEV import job, with retries and a full audit trail on every record.

Questions

Which direction does data move between DATEV and Toast?

The flow is Toast into DATEV. Daily sales, tax, discounts, service charges, and tender totals move from Toast into DATEV as EXTF booking batches, and daily-summary PDFs can be uploaded to DATEV Unternehmen Online. DATEV bookings are write-only and the chart of accounts cannot be read back, so ml-connector never writes ledger data into Toast.

How does the integration post sales when DATEV has no normal booking API?

DATEV processes finalized bookings as EXTF-format CSV files through an asynchronous import job, not a synchronous REST write. ml-connector aggregates each Toast business day, writes a deterministic EXTF CSV file in UTF-8 with precomposed characters, submits it, then polls the import job with exponential backoff until it completes. Because DATEV treats a repeated filename and document type as a duplicate, a re-submitted day is safe rather than double-booked.

How are the two different logins handled?

Toast uses OAuth 2.0 Client Credentials with a TOAST_MACHINE_CLIENT access type, so ml-connector authenticates with no user present and caches the bearer token until near expiry. DATEV uses OAuth 2.0 Authorization Code with PKCE and requires an interactive login by the tax advisor or client, after which ml-connector refreshes the 900-second token by sending the client_id only. Both credential sets are stored encrypted and bridged so the daily sync runs unattended.