Germany / Integration buying scope
DATEV integration: importing data, exchanging records and returning payslips
- Import
- Lohnimportdatenservice: a route for data into DATEV payroll.
- Exchange
- Lohnaustauschdatenservice: bidirectional capability, subject to the implemented connection.
- Documents
- Lohnauswertungsdatenservice: payroll outputs returning to the connected application.
In this guide
- This is a payroll purchase, not an accounting-export comparison
- Put the three names side by side
- Bidirectional does not mean every field has two editors
- A returned payslip is not a returning employee master record
- Test conflicting address changes
- Make the implementation quote describe the flow
- Choose the service that supports your required data
This is a payroll purchase, not an accounting-export comparison
This guide is for a German employer keeping its DATEV payroll operator, often a tax adviser, while buying HR software. Establish whether the operator uses LODAS or Lohn und Gehalt. A statement about DATEV bookkeeping exports does not answer that payroll question.
The service names matter because the buyer may mean “our adviser gets approved changes” while the sales team demonstrates “employees receive payslips.” Both are useful. Neither proves the other.
Put the three names side by side
| Service | Buying purpose | Question that exposes the limit |
|---|---|---|
| Lohnimportdatenservice | Send supported master and payroll input data towards DATEV. | Which approved changes still require the payroll operator to enter them? |
| Lohnaustauschdatenservice | Exchange supported payroll-related data between systems. | Which fields can move in each direction, and how are conflicting values resolved? |
| Lohnauswertungsdatenservice | Bring supported payroll documents back to the HR application. | Which documents return, how are they assigned, and who releases them? |
DATEV distinguishes the unidirectional import service from its newer exchange service. Personio’s setup guide separately names outgoing data, returning documents and eAU retrieval. These are service capabilities and one supplier’s implementation—not a universal field list.
Bidirectional does not mean every field has two editors
DATEV describes its exchange service as bidirectional, with validation and mechanisms for resolving different data states. It also says an implementing third-party connection and a payroll program are required. The underlying service alone is not a finished HR integration.
Ask the supplier to mark every essential field as HR-owned, payroll-owned or governed by a defined conflict process. “Last update wins” may be a technical answer; the payroll owner still needs to decide whether that is the right operational rule.
For fields that cannot be synchronised, agree who enters the change in the second system and checks the result. Include that time when comparing connections.
A returned payslip is not a returning employee master record
Personio documents a payroll-document import route through the Lohnauswertungsdatenservice. Its monthly workflow separates sending data, completing payroll and checking and distributing the returned documents.
That is useful two-direction traffic, but it is not automatically bidirectional synchronisation of every employee field. Ask separately whether a change made in payroll updates the HR record. Then ask which returned document types are supported and who checks recipient assignment.
Do not put payslip availability and master-data synchronisation into one acceptance box. They answer different employee and payroll needs.
Test conflicting address changes
Use a supplier-approved test environment with no real employee data. A fictional worker, TEST-201, starts with “Example Street 1” in both systems. HR changes it to “Example Street 2”; before synchronisation, the payroll operator changes its test copy to “Example Street 3.”
| Buying question | Required answer |
|---|---|
| Does this field travel? | The exact supported direction for the contracted connection. |
| Which value is authoritative? | A named owner or documented conflict-resolution process. |
| What does the operator see? | The accepted value, rejected change or unresolved exception. |
| What happens next? | A safe, explained repeat or correction process without silent oscillation. |
For an import-only proposal, this exercise may correctly expose that no return update exists. That is not automatically a failure. It becomes a failure when the purchase assumed that the HR record would be updated and nobody owns the gap.
Make the implementation quote describe the flow
- Identity: legal entity, DATEV client context and receiving payroll program.
- Data: supported fields, direction, payroll period and excluded items.
- Documents: required return types, recipient matching and release responsibility.
- Operations: trigger, timing, approval, exceptions and correction owner.
- Commercial scope: HR connector charges, DATEV service charges, adviser setup and ongoing work.
Do not turn a published data-service fee into an all-in integration budget. The employer is buying a configured process spanning organisations. We have not verified a complete comparable implementation price.
Ask the adviser to review the proposed flow before contracting. Resolve missing fields and manual steps before committing to implementation.
Choose the service that supports your required data
An import route can be sufficient when HR owns the relevant inputs and the adviser manages the remaining work. A supported exchange route matters when the business needs controlled changes to return. A document service matters when employees should receive payroll outputs through HR.
Do not replace a working connection merely because another service sounds newer. Replace it when a required flow is missing, the manual work is material, or the current process cannot be reconciled. Then use the Germany HRIS shortlist’s acceptance cases to test the result with the payroll operator.
Questions buyers ask
Does a DATEV interface mean two-way synchronisation?
No. Confirm the exact data service and the supplier’s implementation. Import, exchange and returning payroll documents have different purposes.
Does a payslip returning to HR prove master data also returns?
No. Document return and master-data synchronisation must be scoped and tested separately.
Should every employer move to the exchange service?
Not solely because it is newer. Require a supported flow that solves a material gap in the current process, with agreed ownership and implementation scope.
Sources and research scope
Primary DATEV and Personio documentation inspected 2 October 2026. SuitApp’s DATEV interface overview was read as a benchmark; its broad claim that native interfaces remove manual rework was not adopted. This page answers service-scope and data-ownership questions; the existing Germany shortlist retains the provider ranking and wider acceptance packet. No product account testing or blanket supported-field claim.
- DATEV exchange-service descriptionBidirectional capability, validation and implementation prerequisites.
- DATEV import-versus-exchange explanationDirection distinction.
- Personio DATEV setupSeparate outgoing, returning-document and eAU setup scope.
- Personio document importDocument return service.
- Personio monthly workflowSeparate export, payroll completion and document checking/distribution.