DATEV and Gusto integration

What moves between them

The flow runs from Gusto into DATEV. After each payroll is processed and paid in Gusto, ml-connector reads the payroll detail and builds a DATEV EXTF booking batch: gross wages, employer taxes, withholdings, and deductions become debit and credit lines mapped to your SKR accounts and Kostenstelle cost centers. The batch is submitted as an async EXTF file job to the matching DATEV client and the job is polled until DATEV reports complete or failed. Supporting payroll PDFs can also be uploaded to DATEV Unternehmen Online as documents. Because EXTF posting is one-way write-only and DATEV publishes no GL read API, ml-connector never writes booking results back into Gusto.

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted and keeps each side's token fresh on its own clock: DATEV access tokens last 15 minutes and refresh with the client_id only, while Gusto access tokens last 2 hours and rotate a single-use refresh token on every renewal. Gusto tokens are scoped to one company, so a customer with several Gusto companies authorizes each one, and each maps to its own DATEV client-id looked up through the accounting:clients API. A Gusto payroll.processed or payroll.paid webhook, verified by its HMAC-SHA256 signature, triggers the batch build, and a scheduled poll backfills any payroll a webhook missed, since DATEV itself sends no events. Pay components are mapped first to SKR accounts and cost centers, so every EXTF line lands on an account that exists. The EXTF file is written as UTF-8 with precomposed (NFC) characters and a deterministic filename, because DATEV silently rejects non-precomposed text and flags duplicate filename plus document-type combinations with error DCO01253, which keeps re-submission retry-safe. Gusto dollar amounts are parsed as decimals rather than floats, and DATEV jobs are polled with exponential backoff and jitter. Every record carries a full audit trail and can be replayed if a DATEV job fails.

A real-world example

A German software company with about 120 employees runs payroll in Gusto for its US entity and keeps its books in DATEV through its Steuerberater. Before the integration, the finance team exported each payroll register from Gusto, hand-keyed the wage, tax, and deduction totals into a DATEV booking batch, and sorted out which cost center each department belonged to, every pay cycle. With DATEV and Gusto connected, each processed payroll posts into DATEV automatically as an EXTF batch allocated to the right SKR accounts and Kostenstelle, so the labor accounts are booked the same day payroll runs. The manual export and re-keying step is gone, and month-end close starts from numbers the tax advisor can review directly in DATEV.

What you can do

• •Post each processed Gusto payroll into DATEV as an EXTF booking batch, debited and credited to the correct accounts.
• •Map Gusto gross pay, employer and employee taxes, and deductions to your SKR accounts and Kostenstelle cost centers.
• •Trigger on Gusto payroll.processed and payroll.paid webhooks, verified by HMAC-SHA256, and backfill missed runs by schedule.
• •Bridge Gusto OAuth2 and DATEV's PKCE user login, refreshing each token on its own lifetime and per-company scope.
• •Submit DATEV file jobs with deterministic NFC filenames and poll them with retries and a full audit trail on every record.

Questions

Which direction does data move between DATEV and Gusto?

The flow is Gusto into DATEV. Processed payroll totals such as gross pay, taxes, and deductions move from Gusto into DATEV as EXTF booking batches mapped to your accounts and cost centers. DATEV EXTF posting is one-way write-only and exposes no API to read journal entries back, so ml-connector does not write booking results into Gusto.

How does the integration handle DATEV's lack of webhooks and asynchronous posting?

DATEV sends no outbound events and processes every booking as an async file job, so ml-connector submits each EXTF batch and then polls the job status endpoint with exponential backoff and jitter until DATEV reports complete or failed. On the Gusto side it does use webhooks, acting on payroll.processed and payroll.paid as they arrive, with a scheduled poll to backfill anything a webhook missed.

Can DATEV pull employee pay rates and the full chart of accounts automatically?

DATEV cannot. Its standard chart of accounts is not retrievable through the API, so the SKR accounts and cost centers used for mapping are configured once up front. Employee and pay data comes from Gusto, where pay rate fields require the compensations:read scope and an include parameter, so the connector is set up with those scopes during Gusto's partner review before going live.