# Personio DATEV Lohn und Gehalt integration

*Personio → DATEV Lohn und Gehalt*

**In short:** A Personio to DATEV Lohn und Gehalt integration keeps the data your payroll runs on in sync: new hires, leavers, address and tax-class changes, IBANs, recurring salary, one-time payments, and absences flow from Personio into DATEV as Personalstammdaten and Bewegungsdaten before each monthly cutoff. Personio owns the HR truth; DATEV Lohn und Gehalt computes tax and Sozialversicherung. Done properly it is not a monthly file download: it is a delta-aware, idempotent pipeline that maps Personio pay components to your per-client Lohnarten and absence keys so nobody re-keys a leaver into DATEV by hand.

## 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.

## Frequently asked questions

### 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.

## Common errors

- [Personio: 429 rate limit exceeded](https://seamless.engineering/errors/personio-api-rate-limit-429/)

## Related integrations

- [Personio ↔ DATEV](https://seamless.engineering/integrations/personio-datev/): Personio DATEV integration
- [Personio ↔ Microsoft Teams](https://seamless.engineering/integrations/personio-microsoft-teams/): Personio Microsoft Teams integration
- [Personio ↔ Slack](https://seamless.engineering/integrations/personio-slack/): Personio Slack integration
- [Personio ↔ Workday](https://seamless.engineering/integrations/personio-workday/): Personio Workday integration
- [Personio ↔ LinkedIn](https://seamless.engineering/integrations/personio-linkedin/): Personio LinkedIn integration
- [Factorial ↔ DATEV](https://seamless.engineering/integrations/factorial-datev/): Factorial DATEV integration

## Browse by system

- [All Personio integrations](https://seamless.engineering/integrations/personio/)
- [All DATEV integrations](https://seamless.engineering/integrations/datev/)
- [Personio API changelog](https://seamless.engineering/api-changelog/personio/): 0 breaking changes and 3 deprecations in the last 90 days
- [DATEV API changelog](https://seamless.engineering/api-changelog/datev/): No breaking changes or deprecations in the last 90 days

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact