DATEV and Rippling integration

What moves between them

The flow runs from Rippling into DATEV. After each payroll run, ml-connector reads Rippling worker, compensation, and accounting dimension data and writes the labor cost lines into DATEV as an EXTF booking batch, mapped to the matching debit and credit account numbers and Kostenstellen, then polls the DATEV import job until it completes. Worker hires, terminations, and department changes are picked up from Rippling webhooks where an App Shop listing exists, or from a scheduled poll otherwise, so headcount-related allocations stay current. Rippling is treated as the system of record for workforce data, and finalized DATEV bookings cannot be read back, so ml-connector never writes financial entries back into Rippling and never expects a confirmation read from DATEV beyond job status.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Rippling side it uses either the OAuth bearer token from the App Shop install or a single-tenant API key, refreshes the OAuth token before it expires, and checks each worker response for __meta.redacted_fields since compensation is commonly withheld when a scope is missing. On the DATEV side it runs the interactive PKCE login once with the tax advisor, then refreshes the 900-second token automatically using the client_id alone, and looks up the DATEV client ID before any submission. Rippling pay data becomes an EXTF CSV batch: amounts, debit and credit accounts, document numbers, and cost centers are written into the Buchungsstapel layout, with Rippling accounting dimensions mapped to DATEV account numbers and cost centers first, because DATEV's chart of accounts cannot be read back and must be configured in advance. The file is UTF-8 NFC normalized with a whitelisted filename so DATEV does not reject it, and a deterministic filename makes a retry safe since DATEV rejects a duplicate filename plus document-type pair. Because DATEV has no webhooks, ml-connector submits the job and polls the job endpoint with backoff until it posts or fails. Rippling throttling returns HTTP 429, so it backs off and paginates large rosters at a controlled rate. Where no App Shop listing exists, lifecycle changes come from polling workers by updated_at or the company_activity log rather than push. Every record carries a full audit trail and can be replayed if a call fails.

A real-world example

A German technology company with around 150 employees keeps its books in DATEV through its Steuerberater and runs HR and payroll on Rippling across two legal entities. Before the integration, the bookkeeper exported the payroll register from Rippling each month and typed the wage and tax postings into DATEV by hand, matching each line to the right SKR account and Kostenstelle, then reconciled headcount against the labor accounts at month-end. With DATEV and Rippling connected, each pay run's labor cost lines are written into DATEV as a booking batch automatically, allocated to the cost center mapped from each Rippling dimension, and worker changes keep those allocations current. The manual re-keying step is gone and the labor accounts are already in agreement when close begins.

What you can do

• •Write Rippling payroll labor costs into DATEV as EXTF booking batches after every pay run, then poll the job until it posts.
• •Keep DATEV allocations current with Rippling hires, terminations, and department changes from webhooks or a scheduled poll.
• •Map Rippling accounting dimensions and job codes to DATEV SKR account numbers and Kostenstellen so payroll lands on valid dimensions.
• •Authenticate Rippling with OAuth or an API key, and DATEV with interactive PKCE login plus automatic token refresh.
• •Submit on a schedule tied to your payroll calendar, with deterministic filenames, retries, and a full audit trail on every record.

Questions

Which direction does data move between DATEV and Rippling?

The flow is Rippling into DATEV. Worker, compensation, and dimension data moves from Rippling into DATEV, where it becomes payroll booking batches. Rippling is the system of record for workforce data, and finalized DATEV bookings cannot be read back, so ml-connector does not write financial entries back into Rippling.

Does the integration use Rippling webhooks or polling?

It depends on the Rippling app type. Employee lifecycle webhooks such as employee.created and employee.terminated are only available to published App Shop apps, so for those ml-connector receives pushes. For single-tenant API-key setups it polls workers filtered by updated_at or the company_activity event log on a schedule, since DATEV itself sends no events either way.

How does the integration handle DATEV's short token and missing chart of accounts?

DATEV access tokens last only 900 seconds, so ml-connector refreshes them automatically using the client_id alone after the one-time tax advisor login. Because DATEV does not expose its standard chart of accounts over the API, the SKR account numbers and cost centers are configured in advance and Rippling accounting dimensions are mapped to them, so every booking line references a valid account and Kostenstelle.