Factorial DATEV integration

What a Factorial to DATEV integration actually does

Factorial is where your people data lives - who joined, who left, who changed roles or salary, who was sick which days, who worked overtime, who is owed a bonus or an expense reimbursement this month. DATEV, and the payroll office (Lohnbüro or Steuerberater) working inside DATEV LODAS or DATEV Lohn und Gehalt, needs a subset of that expressed precisely: master data for the employee record and movement data for the variable elements of this period’s run.

The gap between an HR system that tracks everything and a payroll system that only wants this month’s payroll-relevant deltas is where the manual work lives. A Factorial to DATEV integration closes it: it reads the relevant changes and period data from Factorial, maps them to your payroll office’s Personalnummern, wage types, and absence keys, and hands DATEV a clean import your Lohnbüro can load without re-keying a single figure.

What data moves

Factorial object / event	Becomes in DATEV	Notes
New hire / onboarding	New employee master record (Personalstammdaten)	Personalnummer assigned or matched; start date, tax and social-security fields
Termination / offboarding	Leaver record with end date	Drives final pay and de-registration on the payroll side
Salary or contract change	Updated master data	Effective date must land in the right Abrechnungszeitraum
Bank details / address change	Updated master data	Sensitive fields; validated before they reach a live payroll run
Absence (vacation, sick, unpaid, parental)	Absence key / wage type in movement data	Mapped per continued-pay and top-up rules, dated to the period
Overtime & time-tracking totals	Variable wage type (Bewegungsdaten)	Aggregated per employee per period, not raw punches
Supplements, bonuses, one-off payments	Mapped Lohnart	Each Factorial pay element mapped to a specific DATEV wage-type number
Expense reimbursements	Non-taxable / taxable wage type as applicable	Coded to the treatment your payroll office defines

The Personalnummer mapping, the wage-type (Lohnart) catalogue, and the absence keys are agreed once with your payroll office and encoded in the pipeline. After that, nobody re-maps them by hand each month.

The details that break naive exports

A generic export or a one-off script gets you most of the fields and leaves the expensive, error-prone part on your desk:

• Personalnummer matching. Factorial’s internal employee ID is not your DATEV Personalnummer. Without a stable, maintained mapping, a rehire or a duplicated record silently splits one person into two payroll accounts. The pipeline holds that mapping and refuses to guess.
• Wage-type mapping. A commission, a shift allowance, a company-car benefit, and a one-off bonus are four different Lohnarten, and the numbers are specific to your payroll office’s setup. A default export flattens them or drops them.
• Absence semantics. Sick leave inside the six-week Entgeltfortzahlung window is treated differently from day 43 onward; a Krankengeldzuschuss, parental leave, and unpaid leave each map to different keys. Dates and the continued-pay boundary have to be exact.
• The cut-off is real. Payroll closes on a date; Factorial does not. Changes after the cut-off belong to the next run as a Rückrechnung, not as an edit to a month that has already been paid.
• Master data versus movement data. LODAS and Lohn und Gehalt separate the standing employee record from this period’s variable data, and they import via different structures. Sending everything as one blob is what makes the import fail on the Lohnbüro’s side.
• Idempotency. Re-run a naive export and you double-submit a month’s absences and payments. The pipeline knows what it has already sent for a period and never posts it twice.

How we build and run it

We treat this as a recurring pipeline, not a monthly manual chore. Employee changes and period data are pulled from Factorial on a schedule (or by webhook where it helps), validated, transformed into your payroll office’s Personalnummern, Lohnarten, and absence keys, and written out as the DATEV master-data and movement-data import - in the LODAS or Lohn und Gehalt structure your Lohnbüro loads.

The pipeline is idempotent: every employee and every period carries a stable identifier, so a retry or a re-run never double-books absences or payments. It runs on cloud-native, fully EU-hosted AWS infrastructure, so salary, bank, and health-related absence data never leaves the EU - which keeps the AVV with your payroll office and your GDPR obligations clean for a genuinely sensitive dataset.

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

When this integration is worth building

If you run a small, stable team where a handful of fields change each month, Factorial’s export plus a few minutes of manual tidy-up is genuinely fine, and we will tell you so. The integration earns its place when headcount and turnover grow, when variable pay, allowances, and mixed absence types make each run a manual mapping exercise, when new hires and terminations arrive mid-period, or when your payroll office is charging you to fix exports that a pipeline should have delivered correctly the first time.