Personio DATEV integration

What a Personio to DATEV integration actually does

Personio is where the workforce actually changes: someone is hired on the 15th, another moves to a four-day week, a third is off sick for a fortnight, a fourth earns a quarterly bonus. DATEV, and the payroll office or Steuerberater running it, needs all of that expressed as payroll input each period - the right Personalnummer, the right Lohnart, the right absence reason, delivered before the cutoff so the run is correct the first time.

The gap between those two systems is where the manual work lives today: someone exports from Personio, reconciles it against DATEV by hand, chases missing personnel numbers, and emails a file around. A Personio to DATEV integration closes that gap automatically. It reads each relevant change from Personio, applies your payroll logic, and hands DATEV clean master data and movement data your payroll office can import without re-keying anything.

What data moves

Personio object / event	Becomes in DATEV	Notes
New hire (Eintritt)	New employee master record	Personalnummer assigned by the agreed rule; tax ID, SV number, bank details, health insurer
Leaver (Austritt)	Termination / deactivation	Leaving date drives the final period; the record is deactivated, never deleted
Master-data change	Updated Personalstammdaten	Name, address, IBAN, tax class, child allowances, cost centre
Compensation change	Recurring wage record	Effective date matters - a mid-month raise splits the period
Absence (sickness, leave, unpaid)	Fehlzeit with the mapped reason	Sick pay vs continued pay vs unpaid each map to a different Fehlgrund
One-time payment (bonus, commission)	Movement data on the right Lohnart	Variable pay lands in the correct period, not the one it was entered in
Working-hours / contract change	Adjusted employment record	Part-time factor and weekly hours feed the calculation

The exact Personalnummer scheme, Lohnart numbers, absence-reason mapping, and payroll engine are agreed once with your payroll office and encoded in the pipeline. After that, nobody maps them again by hand.

The details that break naive exports

The built-in export or a generic HR connector gets you most of the way and leaves the expensive, error-prone part on your desk:

• Personnel-number matching. Personio and DATEV must agree on one Personalnummer per person. Match by name and you eventually pay the wrong Miller. The pipeline enforces the identifier and stops rather than guessing when it is missing.
• Lohnart mapping. A Personio bonus, a commission, and a non-cash benefit are three different DATEV wage types with different tax and social-security treatment. A raw export has no idea which Lohnart yours is; that logic has to be encoded, not defaulted.
• LODAS is not Lohn und Gehalt. The two engines take different import formats and number things differently. An export built for one will not cleanly import into the other.
• Absence semantics. Continued pay during illness, unpaid leave, and normal holiday behave differently in payroll. Each Personio absence type has to map to the correct DATEV Fehlgrund, or net pay comes out wrong.
• Effective dates and cutoff. A raise on the 15th is not a full-month raise, and a change entered after the payroll cutoff belongs to next period. The pipeline reasons about the Abrechnungszeitraum instead of dumping whatever is current.
• Corrections and idempotency. Re-running a naive export can submit the same period twice. A correction to a period already sent has to be a deliberate delta, not a full re-send. The pipeline tracks what it has already delivered and never double-posts.

How we build and run it

We treat this as a pipeline, not a monthly file drop. Personio changes - hires, leavers, compensation, absences, one-time payments - are pulled on a schedule aligned to your payroll cutoff, validated, transformed into your agreed DATEV coding, and written out as a LODAS or Lohn und Gehalt import for your payroll office.

The pipeline is idempotent: every Personio record carries a stable identifier, so a retry or a re-run never produces a duplicate or a mispost. It runs on cloud-native, fully EU-hosted infrastructure, so highly sensitive employee data - salary, bank details, tax ID, social security number, health-related absences - never leaves the EU, which keeps your AVV and GDPR obligations clean.

And then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Personio and DATEV API and format changes are our responsibility under contract, with a named owner and an SLA. The payroll cutoff stops depending on someone remembering to run and clean up an export.

When this integration is worth building

If you have a small, stable headcount, one payroll engine, and few variable payments, Personio’s built-in export is genuinely fine and we will tell you so. The integration earns its place when headcount and turnover climb, when bonuses and commissions make wage-type mapping a monthly chore, when absences and mid-period changes make the manual reconciliation error-prone, or when your payroll office is charging you to fix data that a pipeline should have delivered correctly before the cutoff in the first place.