Data Regulation Satellites: Statutory Values Outside the Code

Statutory Values Are Not Code

Every payroll system depends on a set of numbers that come from outside the organization: the income tax brackets published by the tax authority, the social security contribution ceiling set by the labor ministry, the minimum wage enacted by parliament, the employer contribution rates defined in statutory instruments. These numbers are not business logic. They are not internal policy decisions. They are externally mandated parameters that the payroll system must apply correctly, and they change on a schedule that the payroll system does not control.

Despite this, the standard approach in payroll software is to embed these values directly in application code. A tax rate becomes a constant in a source file. A contribution ceiling becomes a conditional check in a function. A minimum wage becomes a hardcoded threshold in a validation routine. When the value changes — and it will, because legislation doesn't care about software release cycles — the change requires a code modification, a build, a test cycle, and a deployment.

This works when you have one country and one annual update. It becomes untenable when you operate across multiple jurisdictions with different legislative calendars:

• Germany publishes the PAP (income tax algorithm) and SV-Rechengrößenverordnung (social security thresholds) in November for January 1 effect.
• United Kingdom sets new PAYE thresholds, NIC rates, and the National Minimum Wage for the April 6 tax year start.
• Spain publishes BOE changes throughout the year — IRPF table revisions, social security base updates, convenio salary table renewals.
• France adjusts the PASS (Plafond Annuel de la Sécurité Sociale) annually, but can change PAS (prélèvement à la source) rates by decree at any time.

A provider covering five countries faces a continuous stream of statutory value changes, each on its own timeline, each requiring a code deployment in the traditional model. The deployment risk compounds: a January update for Germany might conflict with a code change made for the UK's April update. A mid-year Spanish BOE change arrives while the team is still testing the French PASS update.

This is the premise of data regulation satellites: externalize statutory values into versioned lookup tables that the calculation logic references at runtime, rather than embedding them in the application source.

How Data Regulation Satellites Work

A data regulation satellite is a structured data file — JSON — containing lookup tables with statutory values. Each lookup table is a set of key-value pairs representing a specific parameter domain: tax thresholds, social security rates, allowance limits, or minimum wage tiers. The satellite is imported into the payroll system as a regulation layer, just like a country regulation containing wage types and cases.

The critical feature is validFrom versioning. Every data regulation satellite carries a date that marks when its values become effective. A satellite with validFrom = 2026-01-01 contains the 2026 statutory values. A satellite with validFrom = 2025-01-01 contains the 2025 values. Both coexist in the system simultaneously.

When a wage type calculation needs a statutory value — say, the social security contribution ceiling — it issues a lookup with the payroll period's start date as the reference. The lookup mechanism finds the satellite whose validFrom date is the most recent one that doesn't exceed the period start date. A January 2026 payroll resolves to the 2026 satellite. A retro correction re-running January 2025 resolves to the 2025 satellite — automatically, without any special retro-correction logic in the calling code.

What a Satellite Contains

A typical data regulation satellite is a set of named lookups, each containing the statutory values for a specific parameter domain. The structure is uniform across countries, though the content varies by jurisdiction:

Each lookup entry has a key (the parameter name), a value (the statutory amount or rate), and optionally a range structure for progressive or threshold-based lookups (tax brackets, contribution tiers). The wage type calculation references the lookup by name and key — it never references a specific year or a specific value directly.

The Decoupling Effect

This structure creates a clean separation between what changes annually (the values) and what changes rarely (the calculation logic). A wage type that computes the employee's pension contribution says: "look up the pension ceiling, look up the pension rate, cap the gross at the ceiling, multiply by the rate." It never says: "the pension ceiling is 96,600." The value 96,600 lives in the 2026 data satellite. The 2025 satellite has a different number. The 2027 satellite will have another. The wage type formula doesn't change.

This means an annual regulatory update — for the data satellite layer — is a matter of creating a new satellite file with the new values and a new validFrom date. No code change. No recompilation. No change to the wage type definitions, the case model, or the collector structure. The calculation logic picks up the new values on the effective date.

Real Example: Germany's Annual SV Update

To make this concrete, consider how Germany's social security parameter update flows through the data regulation satellite model.

The Legislative Timeline

In November of each year, the German federal government publishes the Sozialversicherungs-Rechengrößenverordnung (SV-RechenGrößenV) in the Bundesgesetzblatt. This statutory instrument sets the social security parameters for the following year: the contribution assessment ceilings (Beitragsbemessungsgrenzen) for pension, health, unemployment, and nursing care insurance; the reference values (Bezugsgrößen) used for voluntary insurance and Midijob thresholds; and the income thresholds that determine insurance obligation.

These numbers are non-negotiable. Every employer in Germany must apply them starting January 1. A wrong ceiling means wrong contributions — for every employee, every month, until corrected.

The Data Satellite Response

When the SV-RechenGrößenV is published, the compliance team creates a new data regulation satellite — a JSON file containing the updated lookup values. The satellite's validFrom is set to 2026-01-01. The values are verified against the official Bundesgesetzblatt publication. The satellite is imported into the regulation package.

That's it. No wage type formulas are modified. No case definitions change. No collector assignments are updated. The pension contribution wage type still says "look up the pension ceiling, look up the pension rate, cap and multiply." The lookup now resolves to 2026's values instead of 2025's.

What Doesn't Change

The wage type that calculates the employee's pension contribution has the same formula in 2025 and 2026. The wage type that calculates the employer's health insurance share uses the same logic year over year. The Midijob reduced-contribution formula, the marginal-employment exemption check, the nursing care surcharge for childless employees — all of these reference lookups that resolve to the correct year's values based on the payroll period.

The only artifact that changes is the data satellite. One JSON file with verified statutory values. One validFrom date. Deployed as a data import, not a code release.

Multiple Satellites per Country

Statutory values don't all come from the same source, and they don't all change at the same time. A country's payroll parameters are published by different authorities, under different legal instruments, on different schedules. The data regulation satellite model reflects this by supporting multiple independent satellites per country, each covering a distinct parameter domain.

Germany: Four Parameter Domains

Germany's payroll parameters come from at least four distinct legislative sources:

Each satellite is independently versioned. The 2026 tax parameters (Data.LSt.2026) can be finalized and deployed before the 2026 social security parameters (Data.SV.2026) are published. The surcharge limits (Data.Zuschlaege) might not change at all in a given year — in which case, no new satellite is needed; the lookup resolves to the most recent validFrom entry.

Why Separate Satellites Matter

The alternative — a single monolithic parameter file per country per year — creates unnecessary coupling. If the income tax parameters are finalized in September but the social security parameters aren't published until November, a monolithic approach forces you to wait for the last parameter before publishing any of them. Or worse, it forces you to publish a partial file and update it later, introducing versioning ambiguity.

With separate satellites, each parameter domain is self-contained. The tax satellite can be published, tested, and deployed as soon as the BMF publishes the PAP. The social security satellite follows when the SV-RechenGrößenV is published. Each satellite has its own validFrom date, its own verification trail, and its own test surface. A bug in the social security satellite doesn't affect the tax satellite, and vice versa.

This independence also maps naturally to the compliance verification process. The person verifying tax parameters against the BMF publication doesn't need to coordinate with the person verifying social security parameters against the Bundesgesetzblatt. Each satellite has a clear source, a clear verifier, and a clear audit trail.

The Same Pattern, Every Country

The multi-satellite pattern applies uniformly across all supported countries. The number and content of satellites varies — the US has separate satellites for federal income tax, FICA, and garnishment; the UK separates PAYE thresholds from NIC rates and pension parameters — but the mechanism is identical. Every country's statutory values are externalized into independently versioned lookup tables, resolved at runtime by period date.

Compliance Verification

Data regulation satellites contain the most consequential numbers in the payroll system. A wrong contribution ceiling means every employee above the threshold pays incorrect social security contributions. A wrong tax bracket boundary means incorrect income tax withholding for every employee whose income falls near the boundary. A wrong minimum wage means non-compliance with labor law.

Integration tests catch calculation errors — a formula that subtracts instead of adds, a lookup that references the wrong key, a rounding error in the contribution calculation. But integration tests cannot catch wrong statutory values. If the pension contribution ceiling is entered as 95,600 instead of 96,600, the pension calculation will run correctly — it will cap at the wrong ceiling, apply the correct rate to the wrong base, and produce a precisely wrong result that passes every test.

The Verification Process

Before any data regulation satellite is published, every value must be verified against the official source — the government gazette, the tax authority publication, the social security administration bulletin. The verification follows a strict sequence:

1. Identify — List every value in the satellite that needs verification. This is every numeric entry: rates, thresholds, ceilings, allowances, brackets.
2. Verify — Check each value against the official online source. No training data, no memory, no "I think it's." The source URL and legal basis must be recorded.
3. Report — Produce a verification table documenting every value, its source, and its legal basis.
4. Write — Only after verification is complete, the satellite values are finalized.

The verification table follows a standard pattern:

Common Failure Patterns

Experience with multi-country compliance audits has revealed a set of recurring failure patterns in statutory value management. These are not hypothetical — they are errors that have been discovered and corrected through systematic verification:

• Carried-forward values from prior year. A rate that changed between 2025 and 2026 is copied forward without updating. The old value passes all tests because the tests were built against the old value.
• Swapped values. Two related parameters — say, the employer's health insurance flat rate and the employer's pension flat rate for marginal employment — are entered in the wrong fields. Each value is correct; they're just in the wrong position.
• Outdated legal basis. A parameter was changed by legislation several years ago, but the satellite still carries the pre-change value because the update was missed.
• Structural changes not reflected. A tax bracket table gains a new tier, but the satellite only updates the existing tiers' boundaries without adding the new one.
• Precision errors. An official value is given per year, but the satellite needs the monthly equivalent. Naive division (annual / 12) produces a different result than the official monthly figure published separately.

None of these errors are caught by integration tests. All of them produce incorrect payslips. The only defense is systematic verification against the authoritative source — the gazette, the decree, the official rate table — for every value, every year, every country.

Why validFrom Makes Retro Corrections Safe

Retro correction is one of the most error-prone operations in payroll. An employee's salary changes retroactively — an approved raise effective three months ago, a tax class change reported late, a social security reclassification applied mid-year. The payroll system must re-run the affected periods with the correct inputs and calculate the delta between the original result and the corrected result.

The challenge is parameters. When re-running January's payroll in April, the system must use January's tax rates, January's contribution ceilings, January's minimum wage. If the system uses April's values — because those are the current values at the time of the re-run — the retro correction produces a wrong delta, and the corrective payment or deduction on the next payslip is incorrect.

The Problem Without Versioned Values

In a system where statutory values are hardcoded, retro correction requires one of two approaches, both problematic:

1. Snapshot approach: The system takes a snapshot of all parameters at the end of each period and stores them alongside the payroll results. Retro correction retrieves the snapshot. This works but requires maintaining a parallel parameter history for every period, duplicating data that already exists in legislation.
2. Code-version approach: The system retains the old code alongside the new code, so retro correction can "run the old version." This leads to maintaining multiple code paths, branched logic based on period dates, and progressively more complex test matrices.

Both approaches are workarounds for a missing abstraction: time-versioned parameter resolution.

The Solution: Period-Based Lookup

With validFrom-versioned data regulation satellites, retro correction is straightforward. The satellite lookup takes the period start date as input and returns the values that were effective for that period. No snapshots needed — the satellite history is the parameter history. No branched code — the calculation logic is the same for every period; only the resolved values differ.

Consider a concrete scenario: an employee's salary is retroactively increased from January 1, and the retro correction runs in April.

The April re-run of January uses January's parameters because the lookup resolves by period date, not by query date. If a mid-year change had occurred — say, a UK April update — then the January retro run would still use pre-April values, and an April retro run would use post-April values. The satellite versioning handles the boundary automatically.

Cross-Year Retro Corrections

The most demanding case is a retro correction that spans a year boundary. An employee's December salary is corrected in February of the following year. The December re-run must use the prior year's parameters — different tax brackets, different contribution ceilings, different minimum wage. Without versioned satellites, this requires explicit logic to determine which year's values to use. With versioned satellites, the lookup resolves December's period start date to the prior year's satellite. No special case handling required.

This is particularly important for countries with significant year-over-year parameter changes. Germany's pension contribution ceiling, for example, can change by several thousand euros between years. Using the wrong year's ceiling in a retro correction means every pension contribution for the corrected period is wrong — and the delta payment or deduction is wrong by a corresponding amount.

Audit Trail

Because data regulation satellites are versioned artifacts — JSON files with explicit validFrom dates, imported into the system with timestamps — they provide a complete audit trail. If an auditor asks "what pension ceiling did you use for January 2024?", the answer is: the value in the Data.SV satellite with validFrom ≤ 2024-01-01, which is the 2024 satellite, which contains the value published in the 2023 Bundesgesetzblatt. The chain from payslip to satellite to official gazette is traceable and documented.

This traceability is not a feature added on top of the system — it is a natural consequence of the architecture. When statutory values live in versioned, externalized data files rather than embedded in application code, the provenance of every number used in every calculation is inherently recorded.