Benefits-Software daneben stellen oder Embedded Benefits einbauen
· Roland Völkel
Zusammenfassung
- Benefits-Administrations-Software ist ein System, das Ihr Kunde zusätzlich kauft und neben Ihrer Plattform betreibt; Embedded Benefits sind ein Modul, das er in Ihrem Produkt aktiviert.
- Für Product ist das kein Anbietervergleich, sondern eine Ortsentscheidung – und der Ort bestimmt, wer Mitarbeiterdaten, Oberfläche, Support und Umsatz hält.
- Das Nebeneinander bricht an vier vorhersehbaren Stellen: doppelte Stammdaten, ein zweiter Onboarding-Flow, ein separater Abrechnungsexport und ein Wertgespräch, das ein Dritter mit Ihrem Kunden führt.
- Im deutschen Kontext hängen die Module an lohnsteuerlichen Konstrukten und enden monatlich in derselben Abrechnung, die Ihre Plattform ohnehin bedient – ein zweiter Datenpfad in denselben Lauf ist der eigentliche Bruch.
- Einbauen ist die schwächere Wahl, wenn Ihr Produkt keine Mitarbeiterstammdaten führt, wenn Ihre Kunden hinter einem gesetzten Benefit-Stack sitzen oder wenn Sie mehrere Länder gleichzeitig abdecken müssen.
Benefits-Administrations-Software kauft Ihr Kunde zusätzlich und betreibt sie neben Ihrer Plattform. Embedded Benefits aktiviert er in Ihrer Plattform. Für Product ist das kein Anbietervergleich, sondern eine Entscheidung über den Ort – und der Ort bestimmt, wer die Mitarbeiterstammdaten hält, wer die Oberfläche stellt, wo das Support-Ticket landet und bei wem die Marge bleibt.
Was Benefits-Administrations-Software leistet
Benefits-Administrations-Software ist ein eigenständiges System, in dem Benefit-Programme konfiguriert, Mitarbeitende zugeordnet, Anspruchsregeln geprüft, Auswertungen gezogen und Werte für die Lohnabrechnung exportiert werden. Die Kategorie funktioniert und ist für eine bestimmte Welt gebaut: HR setzt sich einen Stack aus Punktlösungen zusammen, ein Login je Aufgabe.
Entscheidend ist, wer kauft. HR kauft. Ihre Plattform ist bestenfalls Integrationsziel in einem fremden Marketplace-Eintrag. Und jeder Prozess, den Ihr Produkt schon abbildet – Eintritt, Rollenwechsel, Elternzeit, Austritt – wird in einem zweiten System wiederholt, das Ihr Kunde ebenfalls pflegen muss.
Die Umkehrung: Es geht um den Ort, nicht um den Anbieter
Die Frage erreicht Product meist als Bauen-oder-Empfehlen-Problem. Ein Benefits-Tool empfehlen oder Benefits auf die Roadmap nehmen. Beide Antworten halten den Benefit außerhalb des Produkts.
Es gibt einen dritten Ort: die Infrastruktur einkaufen und den Benefit in der eigenen Oberfläche zeigen, im eigenen Branding, auf den eigenen Stammdaten.
| Dimension | Benefits-Software daneben | Embedded Benefits eingebaut |
|---|---|---|
| Wer entscheidet | HR kauft ein zweites System | Ihr Kunde aktiviert ein Modul |
| Oberfläche für Mitarbeitende | die des Anbieters | Ihre |
| Stammdaten | zweiter führender Datenbestand | einer, bereits Ihrer |
| Abrechnungsrelevante Werte | separater Export, manuell abgeglichen | im Lauf, den Sie ohnehin bedienen |
| Support-Weg | Kunde wird an einen Dritten verwiesen | Ihr 1st Level, 2nd Level beim Anbieter |
| Wertgespräch zur Verlängerung | führt der Anbieter mit Ihrem Kunden | führen Sie |
| Umsatz für Sie | bestenfalls eine Vermittlungsprovision | wiederkehrende Marge je User und Modul |
| Ihr Aufwand | eine Integration oder gar nichts | API-Integration, Oberfläche, Enablement |
Wo das Nebeneinander bricht
Vier Bruchstellen, in dieser Reihenfolge, und keine davon ist exotisch.
Stammdaten laufen auseinander. Zwei Systeme führen dieselbe Belegschaft. Jeder Eintritt, jede Elternzeit, jeder Austritt muss in beiden landen. Angerufen werden Sie von dem System, das am Abrechnungstag falsch stand.
Onboarding läuft zweimal. Ihr Produkt hat einen Onboarding-Flow, das Benefits-Tool auch. Mitarbeitende treffen beide, und die Abschlussquote des zweiten steuern Sie nicht und berichten Sie nicht.
Die Abrechnung braucht eine Datei, nicht zwei. Benefit-Werte fallen monatlich und pro Person an. Ein separates Tool heißt: ein zweiter Export in einen Lauf, den Ihre Plattform ohnehin erzeugt, plus ein Abgleich, den niemand eingeplant hat.
Das Wertgespräch führt ein anderer. Einmal im Jahr erklärt ein Anbieter, den Ihr Kunde separat gekauft hat, den Nutzen eines Produkts neben Ihrem. Genau dieses Gespräch prägt Verlängerungen – dazu Plattform-Churn senken.
Der deutsche Sonderfall: Der Benefit endet in der Lohnabrechnung
In Deutschland ist die Benefit-Schicht kein Marketing-Feature, sondern ein lohnsteuerliches Konstrukt. Mahlzeit, Gutschein, Mobilität und Internetzuschuss hängen jeweils an einer eigenen Rechtsgrundlage mit eigener Bedingung, und jedes Modul produziert monatlich Werte, die in die Lohnabrechnung müssen. Dazu kommt die Belegseite: Ohne geprüfte Belege trägt die Begünstigung nicht.
Damit ist der Benefit strukturell an denselben Lauf gekoppelt, den HRIS-, Payroll- und Workforce-Plattformen ohnehin bedienen. Ein Tool daneben erzeugt also nicht nur einen zweiten Login, sondern einen zweiten Datenpfad in ein Ergebnis, für das Ihr Kunde am Ende Sie verantwortlich macht.
Ein Punkt, der dabei sauber getrennt gehört: Hrmony übernimmt die Haftung beim Modul Mahlzeit und dort ausschließlich für die Belege, die durch die Einzelbelegprüfung gelaufen sind. Bei den übrigen Modulen bleibt die steuerliche Einzelfallverantwortung beim Arbeitgeber. Sie als Plattform tragen sie in keinem der Fälle – das ist der Teil, der intern regelmäßig größer geraten wird, als er ist.
Wann die eigenständige Benefits-Software die richtige Wahl ist
Einbauen ist nicht überall die Antwort. Drei Fälle, in denen Empfehlen oder Integrieren besser trägt:
- Ihr Produkt verwaltet das Arbeitsverhältnis nicht. Keine Stammdaten, keine Nähe zur Abrechnung, keine Lifecycle-Events. Die vier Bruchstellen oben sind das, was Einbauen behebt – ohne sie gewinnen Sie wenig.
- Ihre Kunden sitzen hinter einem gesetzten Stack. Enterprise-Kunden mit bestehender Benefit-Landschaft und festem Beschaffungszyklus wechseln nicht, weil Ihre Oberfläche schöner ist.
- Sie brauchen mehrere Länder gleichzeitig. Deckt Ihr Produkt zehn Märkte ab und der Anbieter einen, ist eine Integration ehrlich und ein eingebettetes Modul ein Versprechen, das Sie nicht halten.
Für Plattformen, die Stammdaten und abrechnungsnahe Prozesse führen, kippt die Rechnung in die andere Richtung – und sie kippt über den Betrieb, nicht über die Positionierung.
Was Einbauen Sie kostet
Einbauen verschiebt Arbeit, es löscht sie nicht. Bei Ihnen liegen API-Integration, die Oberfläche im Produkt, Sales-Enablement und 1st-Level-Support. Beim Anbieter liegen Belegprüfung, Steuer- und Auszahlungslogik, die monatlichen lohnsteuerlichen Reporting-Dateien, regulatorische Updates und 2nd-Level-Support.
Diese Aufteilung ist der eigentliche Gegenstand der Entscheidung Make or buy bei der Benefits-Infrastruktur. Die kommerzielle Hälfte – was ein Modul je User und Monat trägt – steht in Benefits als Umsatzquelle für Plattformen.
Die Entscheidung in einem Durchgang
Vier Fragen, in dieser Reihenfolge:
- Führt Ihr Produkt die Mitarbeiterdaten, die der Benefit braucht?
- Erzeugen oder beliefern Sie die Abrechnung, in der die Benefit-Werte landen?
- Würde das HR-Team Ihres Kunden sich ehrlich in ein zweites System einloggen?
- Wollen Sie das Wertgespräch zu Benefits führen, oder darf das ein anderer tun?
Dreimal Ja und der Wunsch, das Vierte selbst zu halten, heißt: Der Benefit gehört in Ihr Produkt. Wer die Kategorie noch sortiert, beginnt bei Was sind Embedded Benefits. Wer Modulumfang und Integrationsweg sehen will, ist auf der Hrmony-Embedded-Übersicht schneller.