Payroll-API vs. klassische Lohn-Schnittstelle: der Unterschied
„Wir haben eine Lohn-Schnittstelle” und „wir bieten eine Payroll-API” klingen ähnlich, meinen aber etwas völlig anderes. Der Unterschied entscheidet, wie viel Arbeit bei dir bleibt — und ist gerade für Software-Anbieter zentral.
Auf einen Blick: Eine klassische Lohn-/DATEV-Schnittstelle transportiert nur Daten um ein eigenständiges Lohnprogramm herum — sie importiert Bewegungsdaten oder exportiert Buchungen und Dateien; die Abrechnung selbst läuft weiter im Programm. Eine Payroll-API stellt die Abrechnung selbst als Dienst bereit: Du schickst Bewegungsdaten und bekommst fertige Ergebnisse und Dokumente zurück, ohne ein eigenes Lohnprogramm zu betreiben. Faustregel: Schnittstelle = Tür zu einem Programm, API = das Programm als Service.
Zwei Dinge, die oft verwechselt werden
Beide haben mit „Daten rein, Daten raus” zu tun — aber an unterschiedlichen Stellen. Bei der Schnittstelle bleibt das Lohnprogramm der Ort, an dem gerechnet wird. Bei der API ist genau dieses Rechnen der Dienst, den du aufrufst.
Die klassische Schnittstelle: um ein Programm herum
Der Klassiker ist die DATEV-Schnittstelle: Ein Lohnprogramm exportiert die Buchungen als DATEV-Buchungsstapel (EXTF) in die Finanzbuchhaltung, oder es importiert Bewegungsdaten aus einer Zeiterfassung. Der Austausch läuft meist über Dateien in einem festen Format. Kennzeichen: Es gibt weiterhin ein eigenständiges Programm, das die Abrechnung macht — die Schnittstelle bringt nur Daten hinein oder heraus.
Das ist bewährt, aber begrenzt: Du (oder dein Kunde) betreibst weiter ein Lohnprogramm, pflegst dessen Updates und trägst dessen Zertifizierung.
Die Payroll-API: die Abrechnung als Dienst
Eine Payroll-API dreht das um. Statt Daten in ein Programm zu schieben, rufst du die Abrechnung selbst über HTTP auf: Mandant und Mitarbeiter anlegen, Bewegungsdaten senden, Lauf rechnen, Dokumente abrufen — programmatisch. Zurück kommen die Ergebnisse und fertigen Dokumente (Entgeltabrechnung, Buchungsstapel, Zahldatei) sowie die Meldungen. Ein eigenes Lohnprogramm brauchst du nicht mehr.
Technisch erkennt man eine gute Payroll-API an sauberen REST-Ressourcen, Idempotenz (ein doppelt gesendeter Monat rechnet nicht doppelt), Webhooks für Status-Rückmeldungen und Beträgen als Cent-Integer.
Wann passt was?
| Klassische Schnittstelle | Payroll-API | |
|---|---|---|
| Wer rechnet? | ein eigenständiges Lohnprogramm | der API-Anbieter |
| Austausch | Dateien (z. B. DATEV-Format) | HTTP-Aufrufe, JSON, Webhooks |
| Zertifizierung | trägst du / dein Kunde | trägt der Anbieter |
| Gut für | vorhandenes Lohnprogramm anbinden | Abrechnung einbetten, ohne selbst zu bauen |
Für Software-Anbieter der entscheidende Unterschied
Wer Lohnabrechnung ins eigene Produkt bringen will, kommt mit einer reinen Export-Schnittstelle nicht weit — sie setzt ein Lohnprogramm voraus, das jemand betreiben und zertifizieren muss. Eine Payroll-API dagegen ist die Basis für Embedded Payroll: Die Abrechnung läuft im Hintergrund, die Zertifizierungslast trägt der Anbieter, und deine Kunden sehen „Lohn in deiner Software”. Genau darauf ist Lohnfluss ausgelegt.
Häufige Fragen
Ist eine DATEV-Schnittstelle eine API?
Meist nicht im engeren Sinn: Der DATEV-Austausch läuft klassisch über Dateien (EXTF/CSV). Eine Payroll-API ist eine HTTP-Schnittstelle, über die die Abrechnung selbst aufgerufen wird.
Kann eine Payroll-API auch einen DATEV-Buchungsstapel liefern?
Ja. Der Buchungsstapel ist eines der Dokumente, die aus dem Lauf entstehen — die API stellt ihn zum Abruf bereit. Das eine schließt das andere nicht aus.
Brauche ich mit einer Payroll-API noch ein Lohnprogramm?
Nein. Das ist der Kern: Die Abrechnung ist der Dienst. Du lieferst Bewegungsdaten und bekommst Ergebnisse und Dokumente zurück.
Weiterführend
- Payroll API — Ressourcen, Idempotenz, Webhooks
- Embedded Payroll — Lohn als Baustein im eigenen Produkt
- Lohnbuchungen an DATEV — der klassische Export im Detail
- Interesse? Auf die Warteliste eintragen.