How to choose an embedded benefits provider

Choosing an embedded benefits provider comes down to five questions: who carries the tax liability and how receipts are reviewed, which modules run in production, what you can test before signing, how support is split between you and the provider, and how the commercial model leaves margin with you. Everything else is a preference. These five are structural.

What you are actually buying

A benefit module inside your product has three layers: a tax-compliant process, an operations layer (receipt review, payouts, payroll reporting), and a support surface your customers will use. The API is the thinnest layer, and usually the only one a vendor comparison examines.

That order matters because the layers fail differently. A weak API costs you engineering weeks. A weak compliance model costs your customer money and you the account. If you are still deciding whether to buy at all, start with build vs. buy.

Start with liability, not features

The strongest reason to buy rather than build is that someone else owns receipt-level review, payroll files, and regulatory updates. So begin the evaluation there – and ask for scope, because scope is where offers get vague.

German benefit rules are per instrument, not per vendor. Take the two modules most platforms start with:

• Meal subsidy. The meal is valued at the official benefit-in-kind rate of €4.57 per working day, plus an employer contribution of up to €3.10 that is exempt from income tax – €7.67 per working day, capped at €115.05 per month. A flat 25% employer tax applies only to the taxable portion, meaning the amount valued at the official rate minus the employee's own contribution (§ 40 (2) sentence 1 no. 1 EStG). That portion is exempt from social security contributions provided the flat tax is actually remitted in the payroll period (§ 1 SvEV). Conditions: working days without off-site work, one main meal per day, one receipt per day.
• Voucher. €50 per calendar month is exempt from income tax and social security contributions, but as an exemption threshold: exceed it and the full amount becomes taxable. It must be granted in addition to regular wages, so salary conversion is ruled out (§ 8 (4) EStG together with § 8 (2) sentence 11 EStG), and unused amounts do not carry over.

Two modules, two legal bases, two different ways to get it wrong. "Compliance included" cannot cover both. What to ask instead: which modules does the liability cover, in writing and in the contract; is the review depth receipt-level or sample-based; who answers when a payroll tax audit at your customer asks questions; and who absorbs the work when annual values change.

Check module coverage per module, not by count

Coverage only counts where your customers ask. For HRIS and payroll platforms, the first two requests are usually the meal subsidy and the voucher, because both attach to data you already hold – see embedded benefits for HRIS and for payroll.

Then run two checks. Is the module in production or on the roadmap? And what does the label actually cover? "Mobility" can mean a public transport subsidy, which is exempt from income tax and social security contributions as long as it is granted on top of wages and stays within the actual ticket cost (§ 3 no. 15 EStG), while reducing the employee's commuting deduction. It can also mean a broad mobility budget, whose tax treatment depends on how it is designed. Your product copy and your support team will inherit that difference.

What to test in the sandbox

Ask for sandbox access before you sign. A provider who grants it is confident in the edges; a provider who does not is asking you to negotiate over something you have not run.

The tests that produce information are not the happy path. Enroll an employee mid-month and remove one mid-month. Change working hours. Start parental leave. Submit a backdated receipt. Cross a month boundary with an unspent balance. Then read the payroll output: is it a file your customer's payroll process can consume without manual work? While you are there, confirm who owns the surface – branding, UI, and the customer relationship should stay with you, with the provider invisible to end users.

Decide who answers the tax question

Once benefits appear in your product, tax questions arrive at your support desk, not the provider's. This is the most commonly underestimated line in the business case.

Ask how the split actually works: who handles first level, who handles second level, whether onboarding material for end customers exists, and whether there is a named path for tax questions. On the commercial side, ask whether your sales team gets product training, argumentation, and objection handling, or whether you write that yourself. A provider who leaves first level with you without enablement moves cost into your organization where no price list shows it.

The commercial model decides whether this is a revenue line

The model that works for platforms is straightforward: you buy per user per activated module each month, you set your own end price, and the difference stays with you as recurring margin. On top of that there is usually an access fee covering the API, sandbox, enablement, and operations. Terms are negotiated individually.

Four details belong in the contract rather than the deck. Does billing count activated or created users? Are there minimum commitments? What happens to pricing when statutory values change each year? And who invoices the end customer? That last question determines whether benefits show up as your own revenue line or as a referral commission.

A scorecard for the evaluation

Criterion	The question that separates providers	Evidence to ask for
Liability and receipt review	Which modules, at what review depth?	Module scope in the contract, not the pitch
Module coverage	Which modules are in production, and what does the label mean legally?	Per-module references and legal basis
Integration	Sandbox and docs before signature?	Test access without a contract, documented edge cases
Support and enablement	Who answers the HR admin's tax question?	Named second level plus first-level material
Commercial model	Activated users, and who invoices the customer?	Pricing logic and invoicing in writing

Where Hrmony Embedded stands, and where it does not

The criteria above are neutral, which means they apply to us too.

Liability. Hrmony assumes tax liability for the Meal module, covering the receipts reviewed as part of its receipt-level check. For the other modules we do not assume liability; responsibility for the individual tax case stays with the employer. Ask every provider for an answer at that resolution.

Module coverage. The module set covers Meal, Voucher, Benefit Card, Mobility, and Internet; the current list lives on the Embedded landing page. Our Mobility module is a public transport subsidy, not a full mobility budget.

Integration. REST API or SDK, a sandbox environment, and complete developer documentation. The backend engine handles user management, modules, and payout logic; branding and UI stay yours.

Support and enablement. Onboarding material for end customers, enablement for your first level, second level with us, a path for tax questions, and sales material for your team.

Commercial model. You buy per user per activated module, set your own price, and keep the margin, alongside a platform access fee. Terms are agreed case by case.

Next step

Work through these five criteria in a vendor conversation and you will not need a shortlist – the answers sort themselves. If you want the category framing first, start with what are embedded benefits. If you would rather hold our answers against your own requirements, the starting point is our Embedded overview.