DATEV and UKG integration
DATEV is the accounting and tax backend used across Germany and Austria. UKG runs HR, payroll, and workforce management. Connecting the two moves payroll labor cost into the general ledger without re-keying. After each UKG payroll run, the GL distributions become DATEV booking batches and post against the correct accounts and cost centers, and employee changes keep the org picture aligned. ml-connector handles the very different file-based and REST surfaces on each side and moves data on the cadence your payroll calendar sets.
What moves between them
The flow runs from UKG into DATEV. After each payroll run, ml-connector reads UKG third-party pay GL distributions, mapped by cost center, job code, and GL segment, and builds a DATEV EXTF booking batch with debit and credit accounts, amounts, document dates, and posting text, then submits it as an async file job and polls until DATEV reports complete or failed. Employee hires, terminations, and cost center reassignments flow the same direction so the booking dimensions stay valid. Reference data such as cost centers is aligned so every payroll line references a DATEV account that exists. DATEV bookings are write-only, so ml-connector never reads posted journals back into UKG.
How ml-connector handles it
ml-connector stores both credential sets encrypted. On the UKG side it accepts the tenant hostname per customer and sends Basic auth with both API key headers on every request, since omitting either returns a silent 401. On the DATEV side it runs the interactive OAuth login the tax advisor or client must approve, refreshes the 900 second access token using client_id only, and sends the X-DATEV-Client-Id header with the client path parameter from the clients API. Because DATEV has no webhooks and posting is asynchronous, every booking batch is submitted as a job and polled with exponential backoff and jitter; UKG webhooks trigger incremental employee syncs while delta polling of changed employees backfills anything missed inside the 14 day window. EXTF files use deterministic filenames so a retry is duplicate-safe, since DATEV rejects a repeat of the same filename and document type with error DCO01253, and files are UTF-8 with precomposed characters to avoid silent rejection. Cost centers are mapped first so every line lands on a valid account, and DATEV GL numbers are configured up front because they cannot be pulled. Every record carries a full audit trail and can be replayed if a downstream call fails.
A real-world example
A German engineering firm of about 400 staff across three sites runs payroll in UKG Pro and keeps its books in DATEV through its tax advisor. Before the integration, payroll administrators exported the labor cost register each cycle and the advisor re-keyed the totals into DATEV by cost center, then spent the start of every month-end reconciling headcount against the labor accounts. With DATEV and UKG connected, each payroll run's GL distributions are turned into an EXTF booking batch automatically, allocated to the cost center for each site, and employee changes keep the dimensions current. The advisor opens the period with labor accounts already booked, and the manual re-keying step is gone.
What you can do
- Turn each UKG payroll run's GL distributions into a DATEV EXTF booking batch and submit it as an async file job.
- Map UKG cost centers and job codes to DATEV GL accounts so every payroll line posts to a valid account.
- Keep DATEV booking dimensions current with UKG hires, terminations, and cost center reassignments.
- Bridge UKG Basic auth and its two API key headers with DATEV interactive OAuth and token refresh.
- Use UKG webhooks for incremental employee syncs, with delta polling backfilling the 14 day retention gap.
Questions
- Which direction does data move between DATEV and UKG?
- The flow is UKG into DATEV. Payroll GL distributions and employee changes move from UKG into DATEV, where they become booking batches against the right accounts and cost centers. DATEV bookings are write-only and posted journals cannot be read back, so ml-connector does not write financial entries into UKG.
- How does the integration handle DATEV having no webhooks and asynchronous bookings?
- DATEV does not push events and processes bookings as background jobs. ml-connector submits each EXTF or DXSO batch as a job and polls the status endpoint with exponential backoff and jitter until it completes or fails. On the UKG side it uses webhooks for near real-time employee changes and delta polling to backfill anything outside the 14 day event window.
- Can ml-connector pull GL accounts and posted entries from DATEV?
- No. DATEV does not expose the full chart of accounts over its API, and finalized bookings sent to DATEV Rechnungswesen are write-only. The target DATEV GL accounts are configured up front, and ml-connector maps UKG cost centers and job codes onto them so each payroll line posts correctly.
Related integrations
More DATEV integrations
Other systems that connect to UKG
Connect DATEV and UKG
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started