Embedded-Benefits-Anbieter auswählen: fünf Prüffelder für Plattformen

Ein Embedded-Benefits-Anbieter wird über fünf Felder ausgewählt: wer die steuerliche Haftung trägt und wie geprüft wird, welche Benefit-Module abgedeckt sind, wie die Integration aussieht, wie tief Enablement und Support gehen, und wie das kommerzielle Modell die Marge verteilt. Oberfläche, Roadmap und Logo-Wand lassen sich später ändern. Diese fünf Felder nicht.

Was Sie einkaufen, ist kein Feature

Ein Benefit-Modul in Ihrem Produkt besteht aus drei Schichten: einer steuerkonformen Prozesslogik, einem Betriebsteil (Belegprüfung, Auszahlung, Lohnreporting) und einer Support-Fläche für Ihre Kunden. Die API ist davon der kleinste Teil – und der einzige, den ein Vergleich üblicherweise anschaut.

Deshalb sortieren erfahrene Auswahlprozesse anders: Erst wird geklärt, welche Verantwortung tatsächlich übergeht, dann die Technik. Ob Sie überhaupt einkaufen oder selbst bauen, ist eine Stufe davor entschieden – dazu der Make-or-buy-Vergleich.

Prüffeld 1: Haftung und Belegprüfung

Ein guter Anbieter nimmt Ihnen echte Arbeit ab: Einzelbelegprüfung, abrechnungsfertige Lohndateien, das Nachziehen geänderter Werte. Genau hier liegt der größte Teil des Nutzens – und die Stelle, an der Angebote am unschärfsten formuliert sind.

Der Grund: Die Regeln unterscheiden sich pro Modul, nicht pro Anbieter. Beim Essenszuschuss wird die Mahlzeit mit dem amtlichen Sachbezugswert von 4,57 € bewertet, dazu kommt ein steuerfreier Arbeitgeberzuschuss von bis zu 3,10 €, zusammen 7,67 € pro Arbeitstag und maximal 115,05 € im Monat. Lohnsteuerlich fällt eine Pauschalsteuer von 25 % nur auf den geldwerten Vorteil an, also auf den mit dem Sachbezugswert bewerteten Anteil abzüglich Eigenanteil (§ 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 je Tag, Beleg pro Tag.

Beim Sachbezugsgutschein gilt eine völlig andere Mechanik: 50 € pro Kalendermonat sind lohnsteuer- und sozialversicherungsfrei, aber als Freigrenze – wird sie überschritten, ist der gesamte Betrag steuerpflichtig. Bedingung ist die Gewährung zusätzlich zum ohnehin geschuldeten Arbeitslohn, Gehaltsumwandlung ist ausgeschlossen (§ 8 Abs. 4 EStG i. V. m. § 8 Abs. 2 S. 11 EStG), ein Übertrag in den nächsten Monat existiert nicht.

Zwei Module, zwei Rechtsgrundlagen, zwei Fehlerquellen. Ein Satz wie „Compliance ist inklusive" kann beides nicht gleichzeitig abdecken. Fragen Sie deshalb:

• Für welche Module gilt die Haftungsübernahme, wörtlich und im Vertrag?
• Welche Prüftiefe steht dahinter – Einzelbelegprüfung oder Stichprobe?
• Wer antwortet, wenn beim Endkunden eine Lohnsteuer-Außenprüfung Fragen stellt?
• Wie werden jährlich angepasste Werte nachgezogen, und wer trägt den Aufwand?

Prüffeld 2: Modul-Abdeckung

Nicht die Anzahl der Module zählt, sondern die Überdeckung mit dem, was Ihre Kunden anfragen. Bei HRIS- und Lohnabrechnungs-Plattformen sind das in der Regel zuerst Essenszuschuss und Sachbezug, weil beide direkt an Daten hängen, die Sie ohnehin führen (siehe Embedded Benefits für HRIS und für Lohnabrechnung).

Zwei Prüfungen lohnen sich hier. Erstens: live oder Roadmap? Ein Modul, das im Portfolio-Chart steht, ist nicht dasselbe wie ein Modul, das produktiv läuft. Zweitens: Was steckt hinter dem Label? „Mobilität" kann einen ÖPNV-Zuschuss meinen, der steuer- und sozialversicherungsfrei ist, solange er zusätzlich zum Lohn gewährt wird und die tatsächlichen Ticketkosten nicht übersteigt (§ 3 Nr. 15 EStG) – und dabei die Entfernungspauschale des Mitarbeitenden mindert. Es kann aber auch ein breit ausgestaltetes Mobilitätsbudget meinen, dessen Besteuerung von der Ausgestaltung abhängt. Für Ihre Produktkommunikation und für Ihren Support ist das ein Unterschied, der später teuer wird.

Prüffeld 3: Integration

Hier geht es um Prüfbarkeit vor der Unterschrift. Belastbare Signale: eine REST-API oder ein SDK, eine Sandbox mit Testdaten, eine Dokumentation, die man ohne Termin lesen kann, und ein Datenmodell, das zu Ihrem passt (Nutzer, Beschäftigungsverhältnis, Abwesenheiten).

Was im Sandbox-Test tatsächlich Aufschluss gibt, sind die Ränder, nicht der Happy Path: Eintritt und Austritt mitten im Monat, Wechsel des Beschäftigungsumfangs, Elternzeit, ein rückdatierter Beleg, ein Monatswechsel bei aktivem Guthaben. Wenn diese Fälle in der Sandbox saubere Antworten liefern, ist die Integration selbst meist der einfache Teil. Klären Sie zusätzlich, wer die Oberfläche besitzt: Bleiben Branding, UI und Kundenbeziehung bei Ihnen, oder taucht der Anbieter im Endkunden-Erlebnis auf?

Prüffeld 4: Enablement und Support-Tiefe

Sobald Benefits in Ihrem Produkt sichtbar sind, landen steuerliche Fragen bei Ihrem Support – nicht beim Anbieter. Das ist der am häufigsten unterschätzte Posten der Kalkulation.

Prüfen Sie, wie die Arbeitsteilung wirklich aussieht: Wer übernimmt First Level, wer Second Level, gibt es Onboarding-Material für Endkunden, und gibt es einen benannten Weg für steuerrechtliche Rückfragen? Dazu die kommerzielle Seite: Bekommt Ihr Vertrieb Produktwissen, Argumentation und Einwandbehandlung, oder müssen Sie das selbst schreiben? Ein Anbieter, der First Level ohne Enablement bei Ihnen lässt, verschiebt Kosten in Ihre Organisation, ohne dass sie im Preis auftauchen.

Prüffeld 5: Kommerzielles Modell und Marge

Das Modell, das für Plattformen funktioniert, ist einfach gebaut: Sie kaufen pro Nutzer und aktiviertem Modul monatlich ein, setzen Ihren eigenen Verkaufspreis, und die Differenz bleibt als wiederkehrende Marge bei Ihnen. Dazu kommt in der Regel eine Zugangs- oder Plattformgebühr für API, Sandbox, Enablement und Betrieb. Konditionen werden individuell verhandelt.

Vier Punkte gehören in den Vertrag statt in die Präsentation: Zählen aktivierte oder angelegte Nutzer? Gibt es Mindestabnahmen? Was passiert mit dem Preis, wenn sich Steuerwerte jährlich ändern? Und wer fakturiert den Endkunden – Sie oder der Anbieter? Die letzte Frage bestimmt, ob Benefits eine eigene Umsatzlinie in Ihrer Bilanz sind oder eine Vermittlungsprovision.

Die fünf Prüffelder als Fragenliste

Prüffeld	Die Frage, die den Unterschied macht	Woran Sie Qualität erkennen
Haftung und Belegprüfung	Für welche Module gilt die Haftung, und in welcher Prüftiefe?	Modul-Scope steht im Vertrag, nicht im Deck
Modul-Abdeckung	Welche Module laufen produktiv, und was bedeutet das Label rechtlich?	Referenzen je Modul, klare Rechtsgrundlage je Baustein
Integration	Bekommen wir Sandbox und Doku vor der Unterschrift?	Testzugang ohne Vertrag, dokumentierte Randfälle
Enablement und Support	Wer beantwortet die Steuerfrage des HR-Admins um 16 Uhr?	Benanntes 2nd Level plus Material für 1st Level
Kommerzielles Modell	Zählen aktivierte Nutzer, und wer fakturiert den Endkunden?	Preislogik und Fakturierung schriftlich, Marge bleibt bei Ihnen

Woran Auswahlprozesse scheitern

Drei Muster wiederholen sich. Erstens die Feature-Liste ohne Scope: viele Module, aber keine Aussage, welche produktiv laufen und wofür gehaftet wird. Zweitens die Sandbox nach Vertragsschluss – dann verhandeln Sie über etwas, das Sie nicht getestet haben. Drittens der Preis pro Nutzer ohne Definition von „Nutzer": Bei angelegten statt aktivierten Nutzern verschiebt sich die Marge deutlich, ohne dass eine Zahl im Angebot falsch wäre.

Wie Hrmony Embedded in diesem Raster steht

Wir halten die Kriterien bewusst neutral, also auch für uns selbst nachprüfbar.

Haftung: Hrmony übernimmt die steuerrechtliche Haftung für das Modul Mahlzeit, und zwar für die im Rahmen der Einzelbelegprüfung geprüften Belege. Für die anderen Module übernehmen wir keine Haftung; die steuerliche Einzelfallverantwortung bleibt beim Arbeitgeber. Das ist eine Antwort, die Sie von jedem Anbieter in dieser Genauigkeit verlangen sollten.

Modul-Abdeckung: Das Modulset umfasst Mahlzeit, Gutschein, Benefit Karte, Mobilität und Internetzuschuss; die aktuelle Liste steht auf der Embedded-Landingpage. „Mobilität" ist bei uns ein ÖPNV-Zuschuss, kein umfassendes Mobilitätsbudget.

Integration: REST-API oder SDK, Sandbox-Umgebung und vollständige Developer-Dokumentation. Backend-Engine für Nutzerverwaltung, Module und Auszahlungslogik; Branding und UI bleiben bei Ihnen.

Enablement und Support: Onboarding-Material für Endkunden, Enablement für Ihr First Level, Second Level bei uns, plus ein Weg für steuerrechtliche Rückfragen und Sales-Material für Ihr Team.

Kommerzielles Modell: Einkauf pro Nutzer und aktiviertem Modul, Ihr Verkaufspreis, Ihre Marge, dazu eine Plattform-Zugangsgebühr. Konditionen verhandeln wir individuell.

Nächster Schritt

Wenn Sie diese fünf Felder in einem Auswahlgespräch durchgehen, brauchen Sie keine Anbieterliste – die Antworten sortieren sich selbst. Falls Sie zuerst die Kategorie einordnen wollen, beginnt das bei Was sind Embedded Benefits. Und wenn Sie unser Raster gegen Ihre Anforderungen legen möchten, finden Sie den Einstieg auf unserer Embedded-Übersicht.