Doesn't Personio already have a DATEV export built in?

It does, and for a small, stable headcount that export is genuinely fine. What it does not do is run itself, reconcile which changes already reached DATEV, or govern the Lohnarten and absence-key mapping as your pay components grow. The native export is a file someone downloads and hands over each month. The integration turns that into an automated, monitored delivery with a stable mapping your Kanzlei can rely on cutoff after cutoff.

Which DATEV import do you deliver into - LODAS or DATEV Lohn und Gehalt?

Whichever your payroll runs on. The two products use different import structures, so we agree the target with your Steuerberater or in-house payroll team up front and produce the matching format keyed to the correct Berater- and Mandantennummer. Master data and movement data are delivered so DATEV can import them cleanly without manual rework on their side.

Who owns employee master data - Personio or DATEV?

That has to be decided per field before anything is automated, and it is the single most important design decision. Personio is usually the source of truth for name, address, entry and exit dates, salary, and IBAN. Some payroll-only fields - tax class, Sozialversicherungsnummer, Krankenkasse, confession - may originate with the Kanzlei. We map ownership field by field so the pipeline never overwrites a value DATEV rightfully owns.

How are absences handled - does Personio decide whether pay continues?

No. Personio records the absence; DATEV decides the pay effect. We map each Personio absence type to the correct DATEV Fehlzeitenschlüssel so that continued-pay sick leave (Entgeltfortzahlung), unpaid leave, vacation, and parental leave each carry the right key. DATEV then applies Entgeltfortzahlung and Sozialversicherung rules. Getting the key wrong is exactly what produces a wrong payslip.

What happens to changes made after the payroll cutoff?

They go to the correct period, not silently into the current run. Payroll closes mid-month; a raise or a new IBAN entered after cutoff belongs to the next Abrechnungsperiode, and a backdated change may require a Rückrechnung. The pipeline is delta-aware and cutoff-aware, so late edits are held or flagged for the next period instead of half-landing in a run that is already closed.

Personio DATEV Lohn und Gehalt integration

What a Personio to DATEV Lohn und Gehalt integration actually does

Personio holds the current truth about your people - who started, who left, who moved to a new address, who got a raise, who was off sick for a week, who is owed a one-time bonus. DATEV Lohn und Gehalt is where that truth becomes a payslip: it computes wage tax, Sozialversicherung, and net pay, and it is usually your Steuerberater running it.

The two systems do different jobs, and neither computes the other’s. Personio does not calculate payroll; DATEV does not manage HR. What sits between them is a monthly hand-off of data - master data and the month’s variable movements - that has to arrive complete, correctly mapped, and before the cutoff. A Personio to DATEV Lohn und Gehalt integration automates that hand-off: it reads the relevant changes from Personio, maps them to your payroll’s Lohnarten and absence keys, and delivers them into DATEV as a clean import your payroll team never has to retype.

What data moves

Personio object / event	Becomes in DATEV Lohn und Gehalt	Notes
Employee master data (Stammdaten)	Personalstammdaten	Name, address, birth date, entry/exit date; matched by Personalnummer
New hire (Eintritt)	New employee record + Eintrittsdatum	Requires complete tax class, SV number, and Krankenkasse before first run
Leaver (Austritt)	Exit record + Austrittsdatum	Drives final payroll and Sozialversicherung deregistration
Recurring compensation (salary, hourly wage)	Recurring wage types (Lohnarten)	Personio pay components map to your per-client Lohnart numbers
One-time payments, bonuses, commissions	Variable movement data (Bewegungsdaten)	Einmalbezüge that must land in the correct Abrechnungsperiode
Absences (sick, vacation, unpaid, parental)	Absence keys (Fehlzeitenschlüssel)	Entgeltfortzahlung vs unpaid drives whether pay continues
Bank details (IBAN)	Payment master data	A change is a cutoff-sensitive Stammdaten delta
Cost center	Kostenstelle	For the Lohnjournal and cost allocation

The exact Lohnart numbers, absence keys, and field ownership are agreed once with your payroll team and encoded in the pipeline. After that, nobody maps them again by hand.

The details that break naive exports

The native Personio export gets you most of the way and leaves the expensive part on your desk:

Personalnummer matching. Personio and DATEV each carry their own employee identifiers, and payroll fails quietly when they drift. The pipeline matches on the agreed Personalnummer and refuses to create a duplicate or post a change against the wrong person.
Lohnarten mapping. Base salary, a shift allowance, a commission, and a car-allowance benefit are four different DATEV Lohnarten, numbered per client. A generic export cannot know your scheme; the mapping has to be defined and then held stable.
Absence keys, not just absences. DATEV needs to know whether a sick day is Entgeltfortzahlung, unpaid, vacation, or parental leave, because each drives a different pay and Sozialversicherung effect. Sending the absence without the right Fehlzeitenschlüssel produces a wrong payslip.
Master data vs movement data. Stammdaten changes (address, tax class, IBAN) and the month’s Bewegungsdaten follow different import paths and different cutoff sensitivities. Treating them as one flat file is how a mid-month raise lands in the wrong period.
Field ownership. If Krankenkasse or Sozialversicherungsnummer is maintained by the Kanzlei, the pipeline must never overwrite it from Personio. Ownership is decided field by field, not system by system.
Cutoff and Rückrechnung. Payroll closes on a date. A change entered after it belongs to the next Abrechnungsperiode, and a backdated edit may need a retroactive recalculation. Delta and timing logic has to live in the pipeline, not in someone’s memory.

How we build and run it

We treat this as a pipeline, not a monthly file download. Changes in Personio - hires, leavers, master-data edits, recurring compensation, one-time payments, and absences - are read on a schedule aligned to your payroll cutoff, validated, mapped to your agreed Lohnarten and Fehlzeitenschlüssel, and delivered into DATEV Lohn und Gehalt (or LODAS) in the format your payroll imports, keyed to the correct Berater- and Mandantennummer.

The pipeline is delta-aware and idempotent: every Personio record carries a stable identifier, so re-running a cycle never creates a duplicate employee or double-books a pay component. It runs on cloud-native, fully EU-hosted AWS infrastructure, so employee data - which is squarely GDPR-sensitive personal data - never leaves the EU. That keeps the DPA / AVV with your Steuerberater and your DSGVO 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. You get a named owner and an SLA, so payroll stops depending on one person remembering to pull an export before the deadline.

When this integration is worth building

If you run a small, stable team on a single pay scheme with few monthly changes, the native Personio export is genuinely fine and we will tell you so. The integration earns its place when headcount and turnover climb, when your Lohnarten and benefits get complex, when absences and cutoff timing turn each month into a manual reconciliation, or when a missed change means a colleague is paid wrong and someone spends a day chasing a Rückrechnung. At that point a monitored, mapped, operated pipeline is cheaper than the errors it prevents.