Benefits as a revenue stream for platforms

Embedded benefits give a platform a revenue line, not just a feature. You buy individual benefit modules as an API service, resell them to your own customers under your own name, and keep the difference between what you pay and what you charge. Because benefits run monthly, that difference recurs – it shows up in MRR, not as one-time revenue. For the category itself, start with what embedded benefits are; this piece is about the commercial side.

How a benefit module becomes a revenue line

Three parts: what you pay, what you charge, what stays.

What you pay comes in two positions. A monthly platform fee covers API access, the sandbox, enablement, and ongoing operations. On top of that sits a fee per activated module, per user, per month. The first stays flat; the second grows with usage.

What you charge is yours to decide. There is no price binding and no mandated retail price. For the common modules – Meal, Voucher, Mobility – the going market price sits at roughly double the wholesale fee.

What stays is a resale margin, not a commission split and not revenue share. You invoice your customer; the module fee is your cost of goods.

Position	Set by	Behavior
Platform fee for API access	Infrastructure provider	fixed monthly, independent of user count
Module fee	Infrastructure provider	variable, per activated module and user
Retail price	You	free, inside your own pricing model
Margin	You	retail price minus module fee, recurring monthly

Why it lands on the users you already have

This is expansion revenue, not new business. Acquisition cost for these accounts is already paid, the contract exists, and employee records are already in your system. What is missing is one module switched on.

That changes which number the revenue tracks. It scales with activated users, not with contracts signed:

activated users × margin per user per module × modules per user × 12 = additional ARR

Run that against your own base rather than a model platform. Two factors matter more than price: your activation rate and how many modules a single user carries. A second and third module raise margin per user with no new integration and no new sales motion – which is what separates this from a feature that lifts price once and then disappears into the plan.

What you don't build

The revenue arrives without benefits engineering on your side. The infrastructure provider owns:

• checking submitted receipts,
• payout and balance logic per module,
• payroll tax treatment and payroll-ready reporting files,
• the annual update of statutory values. Germany's official benefit-in-kind value for meals, for instance, is reset every year, usually in October or November for the year ahead – build the logic yourself and you maintain it yearly.

One point deserves precision: Hrmony assumes tax liability for the Meal module, specifically for receipts checked in its individual review process. For the other modules, case-by-case tax responsibility stays with the employer. How effort and risk split between building and buying is worked through in build vs. buy for benefits infrastructure.

Three ways to price it

The mechanics produce the margin; your pricing model decides where it shows up.

As a per-user add-on. The module carries its own price beside your core product. Margin is directly measurable, adoption is slower, because every customer makes a separate buying decision.

Bundled into a higher tier. Benefits become part of a larger package and lift its price. The margin disappears into package margin but pulls upgrades from lower tiers.

Included at no extra charge. No direct margin, but an argument against leaving. How much weight that argument actually carries is covered in reduce platform churn.

For a first business case, the add-on route holds up best, because it keeps the margin measurable on its own. Bundling remains available later.

What eats into the margin

Three places where the math gives way, all of them on your side:

Activation. Sold is not activated. A customer with the module in the contract but no rollout produces no margin, because the module fee tracks active users. Activation belongs in onboarding, not in the contract.

Sales. Your team sells something it did not build and gets asked tax questions. Enablement, playbooks, and second-level support come from the provider; the customer conversation is yours.

Support. Individual receipt questions reach you first. Without a clean escalation path, that effort consumes the margin of your first cohort.

One market at a time

Benefits do not travel the way payments do. A payment product built to European rules can be passported across borders; a benefit module cannot, because what makes it worth more than its cash equivalent is national tax law. The commercial mechanic – wholesale fee, own price, recurring margin – is the same anywhere. The tax logic underneath is not.

For a platform serving several countries, that has a practical consequence: the business case starts with the German portion of your book, not with your total user count. That is also the sequence to plan integration in, and it is the number to put in the model. Payroll systems have the cleanest starting position here, since the data and the monthly cycle already exist – see embedded benefits for payroll.

Questions to settle before the business case

• What share of your customers employs people in Germany? The margin exists only where the tax logic does.
• Which modules fit your user base, and which data do you already hold for them?
• How many modules per user are realistic within twelve months?
• Who sells: account management, customer success, or self-serve inside the product?
• Where does the line item sit – add-on, tier, or retention argument?

If you want to run the math against your own user base, the modules, the integration path, and a contact are on the Hrmony Embedded page.