Build vs. buy: employee benefits infrastructure

For most platforms, buying wins. Benefits infrastructure looks like a feature and behaves like an operations department: receipt validation, payout logic, tax liability, and regulatory change all stay with you after launch, every month. Building makes sense in a narrow set of cases – when benefits are your core product, or when you already run a validated receipt pipeline for other reasons. Both are spelled out below.

What you're deciding to own

Four layers are on the table, not one:

1. Product logic – rules, budgets, and limits per module, user management, activation.
2. Money movement – reimbursement, vouchers, or cards. Vouchers and cards sit close to payments regulation; in Germany that means a design compliant with the Payment Services Supervision Act (ZAG, § 2 (1) no. 10).
3. Tax and compliance – valuation, flat-rate taxation, documentation, retention, payroll-ready files.
4. Operations and support – receipt checks, tax questions from your customers, response to legal change.

Product logic is the smallest of the four. Teams that size the project on that layer alone size it wrong.

The four costs that don't go away

Receipt validation

Germany's meal benefit is tied to one main meal per working day. Every receipt has to be checked against date, working day, amount, and plausibility. At 10,000 active users and the customary 15-day month, that's up to 150,000 receipts a month. Automation carries most of it and not the remainder: blurry photos, combined receipts, late submissions, and disputes need a manual path, and a manual path scales with headcount, not with code.

Then there's retention. Accounting documents have to be kept for 8 years (§ 257 (1) no. 4 in conjunction with (4) German Commercial Code, § 147 (3) sentence 1 Fiscal Code – since January 1, 2025; 10 years before that), payroll accounts for 6 years (§ 41 (1) sentence 9 Income Tax Act).

Payout logic

Every module calculates differently, and the differences aren't cosmetic.

• Meal: the official valuation rate of €4.57 plus a tax-free employer top-up of €3.10 gives a daily value of up to €7.67, or up to €115.05 a month. The portion valued at the official rate is subject to wage tax; the employer may settle it at a flat 25% (§ 40 (2) sentence 1 no. 1 Income Tax Act), which also makes it exempt from social security contributions once that flat tax is paid (§ 1 Social Insurance Remuneration Ordinance). Conditions: a working day without travel, one main meal, a receipt.
• Voucher: €50 per calendar month, free of wage tax and social security contributions, but only if granted on top of regular pay (§ 8 (4) Income Tax Act; legal basis § 8 (2) sentence 11). This is an exemption limit, not an allowance – one cent over and the entire amount becomes taxable. No carryover into the next month.
• Internet: up to €50 a month, settled by the employer at a flat 25% (§ 40 (2) sentence 1 no. 5 Income Tax Act). Not tax-free, but net for the employee, and the subsidy may not exceed the costs the employee can document.
• Mobility (public transport): free of wage tax and social security contributions with no cap up to the ticket price, if granted on top of regular pay (§ 3 no. 15 Income Tax Act). In exchange, it reduces the employee's own commuting deduction one for one.

Engineering time goes into the edge cases: mid-month joiners and leavers, part-time, sick leave, corrections after payroll has run. One example every in-house build eventually meets: during the first three months of a business-travel assignment, the meal benefit may not be valued at the official rate for those days. The rule of thumb is that the two instruments alternate by day and never apply to the same calendar day.

Tax liability

The question isn't whether the logic holds in the normal case. It's who pays when a payroll tax audit rejects it. Formally, responsibility for the individual case sits with the employer – your customer. In practice, the faulty valuation came out of your product, which puts the case in your warranty, your support queue, and your customer relationship.

Buying shifts that exposure, but not wholesale. Hrmony assumes liability for the meal benefit, specifically for the receipts checked in its individual receipt review; for the other modules, responsibility for the individual tax case stays with the employer. Any provider promising blanket liability across all modules should put the scope in writing.

Regulatory change

German values move on two clocks. Annually: the official valuation rates are set in October or November for the following year. In 2025 the meal rate was €4.40, the daily value €7.50, the monthly balance €112.50; in 2026 it's €4.57, €7.67, and €115.05. That isn't a number swap, because open balances, receipts still in review, and December's payroll file move with it.

On occasion: the monthly voucher limit went from €44 to €50 on January 1, 2022. The retention period for accounting documents dropped from 10 to 8 years on January 1, 2025. The 2025 tax amendment act set the commuting deduction at €0.38 from the first kilometer – published in the Federal Law Gazette on December 23, 2025, effective January 1, 2026. Nine days between publication and effect, over the holidays. That's the case your roadmap has to absorb.

The country multiplier

Payments infrastructure has a path to scale across the EU through licensing. Benefits tax law has none. The values, conditions, filing formats, and liability rules above are German, and none of them carry over to France, Sweden, or Poland – there the equivalents have different numbers, different conditions, and different documentation.

That changes the arithmetic of a build. One country is a project. Three countries are three tax domains, three legal-monitoring duties, and three sets of edge cases, maintained in parallel, forever. Platforms that sell across Europe rarely price this into the first estimate.

Build vs. buy, side by side

Dimension	Build	Buy (embedded)
Effort to first customer	product logic, money movement, tax logic, and support in parallel	integration via REST API or SDK, sandbox from day one
Ongoing operation	receipt review and support as a standing function, growing with users	with the provider, including second-level support
Tax responsibility	entirely with you and your customer	contractually defined, check the scope per module
Regulatory change	your release, often due January 1	in the provider's operation
Cost structure	engineering plus permanent headcount, largely fixed	fee per user and activated module plus a platform fee, scaling with usage
UI and customer relationship	yours	also yours – that's what separates embedded from a reseller integration
Differentiation	only if benefits are the core product	in the product above the infrastructure
Additional country	a new project each time	a new module in the same integration

When building is the right call

Benefits are your core product. If you're building a benefits platform, the infrastructure is the product. Then in-house isn't a cost question, it's the precondition for having something of your own to sell.

You already run the receipt pipeline. Expense and spend management platforms have OCR, review workflows, audit trails, and payouts in house. For them the most expensive block is already paid for, and the math looks different than it does for an HRIS. What's still new: wage tax valuation and the payroll-ready file.

A narrow scope in a single country. One module without receipt checks is manageable – a public transport subsidy under § 3 no. 15 Income Tax Act, for instance. The payroll file and the documentation duty remain.

What doesn't hold up in any of the three: building because the module logic looks small in the backlog ticket.

Five questions that settle it

1. Are benefits your core product, or a feature of your core product?
2. Do you run a validated receipt pipeline with payouts today, or would it be new?
3. Who carries the payroll tax risk, and does your contract say so?
4. What happens in your roadmap when a value changes in December, effective January 1?
5. How many countries do you sell into, and how many will you sell into in two years?

Three or more answers pointing at "no" or "not settled": buy.

Buy the rails, build the product

With benefits, build vs. buy is rarely a yes/no question. In the embedded model you buy the infrastructure – modules, tax logic, receipt review, operations – and build the product on top: your UI, your branding, your pricing, your customer relationship. For how the category works, start with What are embedded benefits.

If your alternative isn't an in-house build but a benefits administration tool sitting next to your product, this comparison is the better entry point. And if the question is whether the effort pays for itself: Benefits as a revenue stream for platforms.

Which modules, interfaces, and operational services Hrmony Embedded covers is on the Embedded landing page.