Embedded benefits for payroll platforms
· Roland Völkel
Summary
- Embedded benefits let a payroll platform offer benefits inside its own product while a provider owns valuation, receipt checks, payout, and monthly payroll tax reporting.
- A benefit is not a perk to payroll – it is a set of pay elements per employee per month, each with its own tax status, social security status, and legal basis.
- Benefit tax logic is jurisdiction-specific. In Germany, four modules follow four different rules, from official valuation rates to a monthly exemption limit to employer-paid flat-rate tax.
- The split is clean: you keep the customer relationship, the interface, and the pricing, while the provider owns valuation, receipt review, payout, archiving, and the monthly payroll tax file – delivered already mapped onto the pay elements your customer set up.
- Values move every year, and the update is a standing roadmap item – which is the core of the build-versus-buy question for any platform running payroll in more than one country.
What a benefit becomes once it reaches payroll
To a payroll platform, a benefit is not a perk. It is a set of pay elements: a tax-free amount, a flat-rate taxed amount, or a taxable non-cash benefit – per employee, per period, each resting on a specific legal basis. Embedded benefits mean the platform offers those benefits through its own product while a provider owns valuation, receipt checks, payout, and monthly payroll tax reporting. It is the benefits side of what embedded finance did for payments; the category is laid out in what are embedded benefits.
Payroll has a shorter path here than any other platform segment. An HRIS holds the master data a benefit depends on, which is why embedded benefits for HRIS platforms is the obvious first case. Payroll holds the output as well: pay elements, contribution calculation, statutory filings, year-end statements. A separate benefits vendor recreates that output and hands it over as a file someone has to import, check, and reconcile against the run they already closed.
Tax logic is per jurisdiction, and that is the build cost
Take Germany as the worked example. Four modules, four different mechanics, with 2026 values as of June 2026:
| Module | Income tax | Social security | Condition | Legal basis |
|---|---|---|---|---|
| Meal | Valued at the official rate, €4.57 for lunch or dinner in 2026; employer top-up tax-free up to €3.10, daily value up to €7.67. The taxable benefit can be settled at a flat 25%, paid by the employer | flat-rate portion exempt if the flat-rate tax is remitted in the pay period | one main meal per working day without off-site duty; taxable benefit = official rate minus the employee's own contribution, so no flat-rate tax once that contribution reaches the official rate | § 8 (2) EStG, § 40 (2) sentence 1 no. 1 EStG, § 2 (1) SvEV, R 8.1 (7) no. 4 LStR |
| Voucher | tax-free up to €50 per calendar month | exempt within that limit | granted on top of salary, salary conversion excluded; an exemption limit, so exceeding it makes the full amount taxable; no carry-over to the next month | § 8 (2) sentence 11 EStG, § 8 (4) EStG |
| Internet | up to €50 per month, settled by the employer at a flat 25% – net for the employee, not tax-free | exempt if the flat-rate tax is remitted | granted on top of salary; the subsidy may not exceed the documented costs, and the employee's declaration must be retained | § 40 (2) sentence 1 no. 5 EStG, R 40.2 (5) LStR |
| Mobility (public transport) | tax-free up to the actual ticket cost, no fixed ceiling | exempt | granted on top of salary; the tax-free subsidy reduces the employee's commuter deduction one-to-one. Alternatively flat 15% with that offset, or 25% without the offset and without the on-top requirement | § 3 no. 15 EStG; § 40 (2) sentence 2 no. 1 (b) EStG or § 40 (2) sentence 2 no. 2 EStG |
None of this is tax advice, and responsibility for the individual case stays with the employer. The point for a product team is the shape, not the figures: four modules, four rule sets, one country. Add a second country and you add another set, not another config flag.
Two distinctions are worth building into the UI rather than the FAQ. Tax-free and flat-rate taxed are not the same thing – flat-rate items are technically taxable and still net for the employee because the employer pays the tax. And the meal allowance runs on the official valuation rate while the voucher runs on the monthly exemption limit; two separate pools that must never be netted against each other.
What payroll actually needs, per pay period
The deliverable a platform has to produce is narrower than it first looks. Per employee and per period:
- the tax-free portion
- the taxable non-cash benefit with its flat-rate percentage and who carries it
- any fully taxable remainder
- the figures that carry beyond the month, such as a tax-free public transport subsidy that reduces the employee's commuter deduction
- the file itself, in the target system's format, split by benefit and mapped onto the pay elements the customer set up
That last line is where most of the operational work sits, and it is the reason a benefits export from a separate vendor rarely feels finished.
Values move, and someone owns the update
The official valuation rate is reset every year, with new figures published in October or November of the preceding year. In 2025 it was €4.40, a daily value of €7.50 and €112.50 a month. In 2026 it is €4.57, €7.67 and €115.05 at 15 working days – up to €1,380.60 a year.
The retention rules moved too: since January 1, 2025, accounting vouchers in Germany are kept for eight years rather than ten, while payroll accounts stay at six (§ 41 (1) sentence 9 EStG; § 257 (1) no. 4 with (4) HGB, § 147 (3) sentence 1 AO). Documentation written before that change is now wrong, and it is exactly the kind of detail that surfaces during an audit at your customer, not during your sprint review.
That is the honest version of build versus buy: not one integration, but an annual maintenance commitment per module and per country. Build vs. buy: employee benefits infrastructure works through the trade-off.
What you keep, what the provider owns
Pay-element mapping is where three parties meet, and it is worth naming precisely. The pay element itself is created by the employer or their tax advisor inside the payroll system, with the tax treatment that applies there – for a non-cash benefit exempt up to €50 in Germany, a dedicated pay-element number based on the corresponding standard element. Which value maps onto which number, and in which format the file is produced, is configured in the benefits infrastructure: it delivers the file already mapped, in the target system's format, split by benefit. The platform surfaces that configuration in its own interface and keeps the customer relationship, the branding, and the pricing. What reaches the customer is an import, not a reconciliation. The file itself is retrospective by design – it is produced once the month is closed and the receipts are reviewed, in the first working days of the following month.
The provider owns valuation per module, individual receipt review – automated plus manual verification –, payout, the monthly payroll tax files, archiving, and regulatory updates. With Hrmony that also covers onboarding material, enablement for your first-level support, and second-level support, so tax questions do not queue up in your product team. Liability is taken on for the meal allowance, for the receipts checked under the individual receipt review; for the other modules, responsibility for the individual case remains with the employer. Stating that boundary plainly holds up better in a partnership discussion than a blanket promise.
Commercially, this is recurring revenue on a user base you already bill monthly, with no benefits engineering of your own – the mechanics are in benefits as a revenue stream for platforms, and the evaluation criteria in how to choose an embedded benefits provider.
If you want to see how this maps onto your own pay run, the module and integration overview sits at Hrmony Embedded.