Embedded Benefits für HRIS-Plattformen – die Daten liegen schon im System
· Roland Völkel
Zusammenfassung
- Ein HRIS hält die Daten, an denen Benefits hängen: Beschäftigungsverhältnis, Ein- und Austritt, Arbeitszeitmodell, Abwesenheiten, Standort, Kostenstelle. Embedded Benefits lesen dieses Modell, statt es in einem zweiten System zu duplizieren.
- Der Aufwand eines Benefits liegt nicht in der Oberfläche, sondern in Belegprüfung, Bewertungslogik, Auszahlungsstrecke und Reporting an die Lohnabrechnung.
- Steuerlogik ist Pflege, kein Einmal-Build: Der amtliche Sachbezugswert für eine Hauptmahlzeit lag 2025 bei 4,40 € und liegt 2026 bei 4,57 € (§ 2 Abs. 1 SvEV) – wer selbst baut, zieht solche Werte jedes Jahr nach.
- Zwei Einstiege: vollständig über die REST-API in der eigenen Oberfläche oder über SDK-Bausteine im bestehenden Frontend. In beiden Fällen bleibt der Anbieter für die Endkunden unsichtbar.
- Die Plattform behält Kundenbeziehung, Oberfläche, Branding und Preissetzung. Eine steuerliche Haftung übernimmt Hrmony ausschließlich beim Modul Mahlzeit – für die in der Einzelbelegprüfung geprüften Belege; bei allen anderen Modulen bleibt die steuerliche Verantwortung beim Arbeitgeber.
Warum Benefits im HRIS weniger Aufwand sind als daneben
Ein HRIS führt die Daten, an denen ein Benefit hängt: wer beschäftigt ist, seit wann, in welchem Arbeitszeitmodell, an welchem Standort, auf welcher Kostenstelle, wer wann abwesend ist und wer geht. Embedded Benefits nutzen genau dieses Datenmodell, statt es zu kopieren. Damit fällt für Ihre Kunden der Teil weg, der Benefits heute teuer macht: ein zweites System mit zweiter Nutzerliste, eigenem Onboarding und einer Exportstrecke, die am Monatsende gegen die Lohnabrechnung geprüft werden muss.
Embedded Benefits meint, dass eine Plattform Mitarbeiter-Benefits über ihr eigenes Produkt anbietet, während Bewertung, Belegprüfung, Auszahlung und lohnsteuerliches Reporting bei einem Infrastruktur-Anbieter liegen – die Benefits-Seite dessen, was Embedded Finance im Zahlungsverkehr beschreibt. Die Kategorie und ihre Bausteine sind im Überblick Was sind Embedded Benefits beschrieben.
Unter den Plattform-Typen ist ein HRIS der naheliegendste Ort dafür, weil das Datenmodell schon passt. Payroll-Systeme sitzen näher an der Abrechnung, aber weiter weg von Abwesenheiten und Self-Service – dazu Embedded Benefits für Lohnabrechnungs-Plattformen.
Die Datenpunkte, an denen ein Benefit hängt
| Daten im HRIS | Wofür das Benefit-Modul sie braucht | Beispiel |
|---|---|---|
| Stammdaten, Personalnummer, Ein- und Austritt | Nutzer anlegen, berechtigen, beim Austritt beenden | alle Module |
| Arbeitszeitmodell und Arbeitstage | Anspruchstage für den arbeitstagsgebundenen Zuschuss | Mahlzeit |
| Abwesenheiten inkl. Auswärtstätigkeit | Tage, an denen kein Anspruch entsteht oder eine andere Bewertung gilt | Mahlzeit |
| Standort und Kostenstelle | Budgetzuweisung, Kostenverteilung, Reporting | alle Module |
| Abrechnungslauf und Lohnarten | Rückweg der monatlichen lohnsteuerlichen Reporting-Datei | alle Module |
| Rollen und Rechte | wer im Kundenunternehmen Module konfiguriert und Budgets setzt | alle Module |
Wer Benefits als separates Produkt betreibt, baut diese sechs Zeilen zweimal – und hält sie synchron. Wer sie einbettet, liest sie einmal.
Was das HRIS nicht mitbringt
Die Oberfläche ist der kleine Teil. Der Rest ist Betrieb.
Belegprüfung. Beim Mahlzeit-Modul wird jeder Beleg geprüft, automatisiert und mit manueller Nachprüfung. Das ist kein OCR-Feature, sondern ein Prozess mit Ausnahmen, Rückfragen und Nachweisen.
Bewertungs- und Pauschalierungslogik. Beispiel Mahlzeit: Der Zuschuss wird nicht mit dem gezahlten Betrag bewertet, sondern mit dem amtlichen Sachbezugswert – 2026 sind das 4,57 € für eine Hauptmahlzeit (§ 2 Abs. 1 SvEV). Zusammen mit dem steuerfreien Arbeitgeberzuschuss von 3,10 € ergibt das bis zu 7,67 € pro Arbeitstag, über die 15-Tage-Regel bis zu 115,05 € im Monat. Lohnsteuerlich ist der geldwerte Vorteil – Sachbezugswert minus Eigenanteil der Mitarbeitenden – steuerpflichtig, wird aber vom Arbeitgeber pauschal mit 25 % abgegolten (§ 40 Abs. 2 S. 1 Nr. 1 EStG). Sozialversicherungsfrei ist dieser Anteil, sofern die Pauschalsteuer im Abrechnungszeitraum abgeführt wird (§ 1 SvEV). Bedingung: Arbeitstage ohne Auswärtstätigkeit, eine Hauptmahlzeit pro Tag. „Steuerfrei" ist das nicht, für Mitarbeitende aber netto – ein Unterschied, den Ihre Kunden im Zweifel von Ihrem Support erklärt bekommen wollen.
Beim Gutschein greift eine andere Regel: 50 € pro Kalendermonat bleiben lohnsteuer- und sozialversicherungsfrei, sofern der Gutschein zusätzlich zum ohnehin geschuldeten Arbeitslohn gewährt wird und die Ausgestaltung § 2 Abs. 1 Nr. 10 ZAG entspricht (§ 8 Abs. 2 S. 11, § 8 Abs. 4 EStG). Es ist eine Freigrenze, kein Freibetrag: 50,01 € machen den gesamten Betrag steuer- und beitragspflichtig, nicht den Cent darüber.
Pflege. Beide Regeln bewegen sich. Der Sachbezugswert wird jährlich angepasst – 2025 lag er bei 4,40 €, 2026 bei 4,57 €. Ein selbst gebautes Modul erbt diese Nachpflege dauerhaft, inklusive der Frage, wer im Team sie bemerkt.
Haftung. Hrmony übernimmt die steuerliche Haftung ausschließlich beim Modul Mahlzeit und dort für die in der Einzelbelegprüfung geprüften Belege. Bei allen anderen Modulen bleibt die steuerliche Einzelfallverantwortung beim Arbeitgeber. Das ist der ehrliche Zuschnitt – wer „volle Haftung für alles" verspricht, sollte gefragt werden, für welchen Baustein genau.
Zwei Einstiege in die Integration
Vollständig über die REST-API. Sie bauen Admin- und Nutzerstrecke in Ihrer eigenen Oberfläche und rufen Provisionierung, Modulaktivierung, Budgets und Transaktionen über die API. Maximale Kontrolle über UX und Reihenfolge, mehr Frontend-Arbeit bei Ihnen.
Über SDK-Bausteine. Sie setzen fertige Komponenten in Ihr Frontend und behalten Layout, Branding und Navigation. Weniger Aufwand, weniger Freiheit im Detail.
Für die Modul-Reihenfolge zählt, wie viel Ihr Datenmodell schon liefert. Das Gutschein-Modul braucht am wenigsten – Person, Budget, Monat. Das Mahlzeit-Modul braucht Arbeitstage und Abwesenheiten und ist genau deshalb für ein HRIS der stärkere Startpunkt: Es zeigt den Vorsprung, den Sie gegenüber einem separaten Anbieter haben.
Was bei Ihnen bleibt
Kundenbeziehung, Oberfläche, Branding und Preissetzung. Sie kaufen pro aktiviertem Modul und Nutzer ein und bestimmen den Verkaufspreis selbst; die Marge bleibt bei Ihnen. Wie sich das über eine bestehende Nutzerbasis rechnet, steht in Benefits als Umsatzquelle für Plattformen.
Im Betrieb bleibt der 1st-Level-Support bei Ihnen, 2nd Level und steuerrechtliche Rückfragen liegen beim Anbieter. Sales-Enablement und Materialien kommen mit.
Wann es nicht passt
Wenn Ihre Kunden überwiegend außerhalb Deutschlands abrechnen, greift die Steuerlogik nicht – Benefit-Infrastruktur ist national, nicht generisch.
Wenn Ihr System keine Abwesenheits- oder Arbeitszeitdaten führt und keine Anbindung an die Abrechnung hat, verlieren Sie den Datenvorsprung. Dann ist ein Marketplace-Eintrag der ehrlichere Weg.
Und: Benefits sind kein Nullaufwand-Produkt. Es entstehen Support-Anfragen, Enablement-Bedarf im Vertrieb und eine Zeile in der Preisliste. Der Unterschied ist, dass keine Benefit-Engine in Ihrem Backlog landet.
Wie ein erster Lauf aussieht
Discovery und Setup: Use Case, Abgleich Ihres Datenmodells mit den Modul-Anforderungen, Zugang zu Sandbox und Dokumentation. Dann die Integration: API oder SDK, Flows, technische Validierung. Danach Enablement und Pilot: Sales- und Support-Training, erste Pilotkunden. Zuletzt Launch und Skalierung über weitere Module und Kundensegmente.
Belastbare Zeitangaben entstehen nach der Discovery, nicht davor – wer vorher eine Zahl nennt, rät. Welche Fragen Sie einem Anbieter vorher stellen sollten, steht in Embedded-Benefits-Anbieter auswählen.
Wenn Sie prüfen wollen, wie das an Ihrem Datenmodell aussieht: Der Aufbau von Hrmony Embedded ist dort beschrieben, ein Datenabgleich ist ein Gespräch, kein Projekt.