The Composable Regulation Model: Country, Industry, Company

The Problem with Monolithic Payroll

Most payroll platforms start the same way. A team builds payroll for one country. It works. They sign a second client, and because the second client has a slightly different benefit structure — a different car allowance rule, a company pension that follows a non-standard formula — they fork the codebase. Now there are two copies. By the time they reach the fifth country and the fiftieth client, they've accumulated dozens of parallel codebases, each drifting from the original.

The math is straightforward. A provider running 200 companies across five countries is maintaining up to 1,000 separate configurations. Each country regulation changes at least once a year — Germany on January 1, the UK in April, Spain whenever the Boletín Oficial del Estado publishes a new IRPF table. That means hundreds of manual patches every year, applied to hundreds of forks, each with its own history of customizations.

This is not a hypothetical failure mode. It is the default architecture of most payroll platforms built in the last twenty years. And it fails in predictable ways:

• Compliance drift. Fork number 147 misses the January update because the patch didn't merge cleanly with a client-specific modification from March.
• Regression blindness. A fix to the social security calculation in the master branch breaks a custom wage type in a client fork — but nobody runs the client's tests against the master, because the client's tests live in the fork.
• Update paralysis. Providers delay annual updates because patching 200 forks is a two-month project. Payslips run on outdated rates until the backlog clears.
• Onboarding cost. Every new client requires a new fork, a new set of customizations, and a new entry in the update pipeline. The marginal cost of adding client 201 is nearly the same as adding client 1.

What's needed is a model where the statutory base is maintained once and consumed many times, where industry conventions are shared across all companies in a sector, and where company-specific rules are isolated in a layer that never interferes with the compliance logic below it. That's what the composable regulation model provides.

The Three-Layer Regulation Stack

The composable regulation model separates payroll logic into three distinct layers. Each layer has a clear scope, a clear owner, and a clear update cycle. They stack — each layer can extend or override the layer below it — but they never merge into a single artifact.

Layer 1: Country Regulation

The country regulation is the statutory base. It contains everything required by law: income tax withholding (the German PAP algorithm, the UK PAYE tables, the French PAS calculation), social security contributions (employee and employer shares, contribution ceilings, reduced rates for specific employment types), and statutory minimums (minimum wage, mandatory vacation accrual, statutory sick pay rates).

This layer is maintained centrally by compliance specialists. It is updated when the law changes — annually for most countries, more frequently for countries with mid-year legislative cycles. A provider consuming this layer does not modify it. They receive it as a versioned package, and their payroll configurations reference it by version.

The country regulation also includes data regulation satellites — versioned JSON lookup tables containing statutory values (tax brackets, contribution rates, thresholds) that change independently of the calculation logic. These satellites carry validFrom dates, which means a retro correction for January 2024 will automatically use January 2024 values, even when queried in 2026.

Layer 2: Industry Regulation

Many countries have sector-specific rules that sit between national law and individual company policy. In Spain, convenios colectivos define salary tables, overtime supplements, and seniority bonuses by industry sector. In the Netherlands, collective labor agreements (CAO) specify sector pension contributions, holiday allowance percentages, and shift premiums. In Germany, Tarifverträge establish industry-wide pay scales and additional leave entitlements.

The industry regulation captures these rules. It is shared across all companies operating in that sector — every IT company in Spain covered by the same convenio references the same industry regulation. When the collective agreement is renegotiated, the industry regulation is updated once and all companies under that agreement pick up the change.

An industry regulation never duplicates the country regulation. It only adds sector-specific wage types, cases, and overrides. If the Spanish IT convenio specifies that the waiting period for sickness benefit is one day instead of three, the industry regulation overrides that single parameter. Every other statutory calculation — IRPF, social security, employer cost — remains untouched in the country layer.

Layer 3: Company Regulation

The company regulation is the tenant-specific layer. It contains rules that apply to one company and no other: a custom car allowance formula, company-specific meal voucher deductions, a supplementary pension scheme, a performance bonus structure, or an equity compensation plan.

This layer is maintained by the company itself or by the provider on the company's behalf. It is the only layer that varies per tenant. And critically, it has no effect on the statutory calculations below it — a company regulation can add wage types and cases, but the override mechanism controls exactly which properties of existing wage types can be modified downstream.

The layering is strict. A company regulation can reference wage types from the country or industry layer (for example, basing an employer contribution on the statutory gross pay), but it cannot redefine how income tax is calculated. Override keys — declared at the wage type level — control exactly which properties can be modified by downstream layers. If a country regulation marks a tax calculation wage type as non-overridable, no industry or company layer can change it.

How Overrides Work in Practice

The override mechanism is what makes the composable model safe. Without it, any downstream layer could modify any upstream calculation — and the statutory guarantees of the country regulation would be meaningless. With it, each layer declares exactly what it exposes for customization, and downstream layers can only operate within those boundaries.

Adding a New Wage Type

The simplest case: a company needs a wage type that doesn't exist in the country or industry regulation. A German company wants to add a company car benefit calculated under the 1% rule (Firmenwagen 1%-Regelung). The company regulation adds a new wage type — say, WT 8010 — that calculates the taxable benefit based on the car's list price. This wage type feeds into the existing gross pay collector, which means it is automatically included in the tax and social security calculations defined in the country layer.

No change to the country regulation. No fork. No patch. The company layer adds its wage type, declares its collector group membership, and the country layer's tax and social security calculations consume it through the collector interface.

Overriding an Existing Parameter

A more nuanced case: an industry regulation needs to change a specific parameter defined in the country layer. The Spanish IT convenio specifies that the sickness waiting period is one day, not the statutory three days. The country regulation's sickness wage type declares the waiting-period parameter as overridable. The industry regulation provides an override that sets it to one. Every company under that convenio automatically uses the one-day waiting period without any company-level configuration.

The key constraint: the override only works if the country regulation has explicitly declared that parameter as overridable via an override key. If the parameter is locked — as tax rates and social security contribution percentages typically are — no downstream layer can modify it. This is how the system prevents an industry or company regulation from accidentally (or intentionally) changing a statutory calculation.

Collector Groups and Automatic Membership

When a company adds a new wage type, that wage type often needs to be included in multiple collectors — gross income, taxable income, social-security-liable income, employer cost. Manually assigning every collector would be error-prone and fragile: if the country regulation adds a new collector in next year's update, existing company wage types would miss it.

Collector groups solve this. The country regulation defines groups like "taxable income" and "social-security-liable income." Collectors declare their group membership. When a company wage type declares membership in a collector group, it is automatically included in every collector that belongs to that group — including collectors added in future country regulation updates.

This means a company's car allowance wage type, declared as a member of the "taxable income" group, will automatically be included in the income tax calculation, the solidarity surcharge calculation, and any other collector that belongs to that group — without the company regulation knowing which specific collectors exist in the country layer.

The Annual Update: One Change, All Tenants

The annual regulatory update is where the composable model pays for itself. Here's what happens in a traditional monolithic architecture versus the layered model.

The Monolithic Approach

January 1: Germany publishes the PAP 2026 algorithm with a new Vorsorgepauschale calculation. The provider's compliance team builds the update in the master branch. Then they begin the merge cycle: 200 German client forks, each with its own customizations. Some merge cleanly. Some don't — a client modified a related wage type last April, and the merge conflicts with the new algorithm. The team resolves conflicts manually, runs each client's test suite (if one exists), and deploys fork by fork. The process takes weeks. Some clients run on the old rates until February.

The Composable Approach

January 1: the updated country regulation package is published. It contains the new PAP algorithm, updated data regulation satellites with the 2026 tax parameters and social security thresholds, and updated integration tests verifying the new calculations. All 200 German tenants reference the country regulation by version. When the provider updates the version reference — one configuration change — all 200 tenants pick up the new statutory calculations.

The company layers are untouched. They contain company-specific wage types (car allowance, meal vouchers, custom bonuses) that interact with the country layer through collector groups and override keys. None of those interfaces changed. The car allowance wage type still feeds into the taxable income collector group. The country layer's new tax algorithm consumes it the same way the old algorithm did.

There is no merge. There is no per-tenant patch. There is no conflict resolution. The statutory base changed; the company additions did not; and the interface between them remained stable.

Mid-Year Changes

Not every country updates on January 1. The UK's tax year starts in April. Spain publishes BOE changes throughout the year. France adjusts social security ceilings independently of income tax parameters.

The composable model handles mid-year changes the same way. The country regulation's data regulation satellites carry validFrom dates. A UK April change ships as a new data satellite entry with validFrom = 2026-04-06. Payrun jobs for March use March's values; payrun jobs for April use April's values. No code deployment required — just a new versioned data entry.

For retro corrections, this is critical. Re-running a January payroll in June must use January's parameters. The validFrom versioning guarantees that — the lookup mechanism resolves values based on the period start date, not the query date.

Testing Across Layers

A layered architecture is only as reliable as its testing strategy. If a change in the country layer can break an industry or company layer without detection, the composability is theoretical, not practical. The testing model must match the architectural model: each layer is independently testable, and cross-layer interactions are verified at the integration boundaries.

Country Layer Testing

Each country regulation ships with a comprehensive integration test suite. These tests verify statutory calculations against known values — specific employee scenarios with defined inputs (salary, tax class, contribution group, employment type) and verified expected outputs (income tax, social security contributions, net pay). The tests are run on every change to the country regulation, and all tests must pass before a version is published.

The test count varies by country and coverage depth. A mature regulation with full coverage — tax, social security, employer cost, special cases (part-time, Midijob, multiple employment), and retro correction scenarios — carries hundreds of integration tests. These are not unit tests of isolated functions; they are full payrun simulations that exercise the entire calculation chain from gross input to net output.

Industry Layer Testing

Industry regulations are tested against the country layer they extend. The tests verify that sector-specific overrides produce the expected results without breaking statutory calculations. If an industry regulation overrides a sickness waiting period, the test suite verifies that (a) the override is applied correctly, (b) the sickness benefit calculation uses the overridden value, and (c) all other statutory calculations — tax, social security, employer cost — remain correct.

This cross-layer testing is the safety net. An industry regulation that accidentally interferes with a statutory calculation will fail at the integration test level, before it reaches production.

Company Layer Testing

Company layers are tested using preview payrun jobs. A preview job runs the full calculation chain — country regulation, industry regulation (if any), company regulation — against current employee data, produces results, but does not persist them. Preview jobs serve as CI gates: before a company regulation change is deployed, a preview job verifies that the change doesn't produce unexpected results.

The critical property: a company regulation's tests do not need to re-verify statutory correctness. That's the country layer's responsibility, and the country layer's tests already cover it. Company tests only need to verify that company-specific additions produce the expected values and interact correctly with the upstream layers through collector groups and override keys.

The Provider Math

Let's return to the numbers from the opening. A provider with 200 companies across five countries. In the monolithic model, that's up to 1,000 separate configurations, each requiring individual attention during every annual update.

In the composable model, the math changes fundamentally:

The annual update cycle becomes: five country regulation updates (one per country), a handful of industry regulation updates (when collective agreements change), and zero mandatory changes to the 200 company regulations. The company layers only change when the company's own policies change — not when the law changes.

This transforms the provider's operational model. Annual regulatory updates become a compliance team task measured in days, not a development project measured in months. Adding a new client is a configuration task — assign the correct country and industry regulations, add company-specific wage types if needed — not a fork-and-customize project. And onboarding a new country means adding one country regulation to the stack, not rebuilding the payroll engine.

The Scaling Curve

In the monolithic model, the cost of annual updates scales linearly with the number of clients. Client 201 adds the same maintenance burden as client 1. At some point — typically around 50 to 100 clients per country — the update backlog becomes the provider's primary engineering expense.

In the composable model, the cost of annual updates is constant per country, regardless of client count. The country regulation is updated once. Whether 20 tenants or 2,000 tenants consume it, the update effort is the same. The variable cost — company regulation maintenance — is proportional to the number of company-specific customizations, which is typically a small fraction of the total payroll logic.

This is the difference between a product that works at 50 clients and one that works at 5,000. The monolithic approach can be made to work at small scale through manual effort. The composable approach is the only model that scales without linear growth in compliance engineering headcount.

What Doesn't Change

The composable model doesn't eliminate all complexity. Country regulations still need expert maintenance — tax algorithms change, social security thresholds shift, new statutory requirements emerge. Industry regulations require sector expertise and monitoring of collective agreement negotiations. Company regulations need someone who understands the company's specific benefit structure.

What changes is where that complexity lives and how it propagates. In the monolithic model, every change touches every client. In the composable model, each change is scoped to its layer and propagates through defined interfaces. The work doesn't disappear — it becomes manageable.