DATEV and ADP integration

What moves between them

The flow runs from ADP into DATEV. After each payroll run, ml-connector reads ADP's general ledger documents and writes the labor cost lines into DATEV as an EXTF booking batch, mapped to the matching debit and credit account numbers and cost centers, then polls the DATEV import job until it completes. Supporting payroll PDFs are uploaded to DATEV Unternehmen Online against the right document type. Both sides treat their GL output as read-only: ADP GL documents are pull-only, and finalized DATEV bookings cannot be read back, so ml-connector never writes financial entries back into payroll and never expects a confirmation read from DATEV beyond job status.

How ml-connector handles it

ml-connector stores both credential sets encrypted and presents the ADP client certificate at the TLS layer on every request, re-calling the ADP token endpoint when a call returns 401. 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. ADP GL documents become an EXTF CSV batch: amounts, debit and credit accounts, document numbers, and cost centers are written into the Buchungsstapel layout, with account numbers and cost centers mapped 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. ADP rate limits return HTTP 429 per gateway node, so it backs off, and it tracks the ADP certificate expiry so a renewal does not become an outage. Every record carries a full audit trail and can be replayed if a call fails.

A real-world example

A German engineering firm with around 180 employees keeps its books in DATEV through its Steuerberater and runs payroll on ADP Workforce Now across two locations. Before the integration, the bookkeeper exported the payroll journal from ADP 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 ADP connected, each payroll run's GL document is written into DATEV as a booking batch automatically, allocated to the cost center for each location, and the supporting PDFs land in DATEV Unternehmen Online. The manual re-keying step is gone and the labor accounts are already in agreement when close begins.

What you can do

• •Write ADP payroll general ledger documents into DATEV as EXTF booking batches after every pay run, then poll the job until it posts.
• •Upload supporting payroll PDFs to DATEV Unternehmen Online against the correct client document type.
• •Map ADP cost centers and accounts to DATEV SKR account numbers and Kostenstellen so payroll lands on valid dimensions.
• •Authenticate ADP with OAuth2 and its required mutual TLS certificate, 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 ADP?

The flow is ADP into DATEV. Payroll GL documents move from ADP into DATEV as booking batches, and supporting PDFs are uploaded to DATEV Unternehmen Online. ADP general ledger documents are read-only, and finalized DATEV bookings cannot be read back, so ml-connector does not write financial entries back into payroll.

Why does DATEV use file jobs instead of a normal API write?

DATEV's accounting engine is on-premise, so finalized bookings are submitted as asynchronous EXTF CSV files to a cloud relay that forwards them, rather than written field by field. ml-connector builds the EXTF batch, submits it as a job, and polls the job endpoint until it posts or fails, because DATEV sends no webhook to confirm completion.

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 ADP values are mapped to them, so every booking line references a valid account.