Payroll Compliance Infrastructure: What It Is, What It's Made Of, and Why Open Source Matters

Not a Feature — Infrastructure

The phrase "payroll infrastructure" gets used loosely. Most of the time it means nothing more than "payroll software." But there's a real distinction worth making — one that shapes every architectural decision in how PayrollEx is built.

Infrastructure, in the engineering sense, is the layer that other systems build on top of. It's stable, versioned, and independently testable. It handles concerns that shouldn't be reinvented by every application sitting above it. The classic examples are databases, message queues, and identity services. Payroll compliance belongs in the same category — but almost no one treats it that way.

Instead, payroll logic is typically embedded inside HR platforms as proprietary code. It's tightly coupled to the product, untestable in isolation, and replaced wholesale when the vendor changes. This works when you operate in one country and your regulatory surface is stable. It breaks down the moment you cross a border, add a second country, or need to verify that last year's calculation was correct.

What It's Made Of

PayrollEx is built as four separable layers. Each layer has a clear responsibility and can be updated independently. A change to German income tax rates in January doesn't require touching the calculation engine. A new country regulation doesn't require changes to the consolidation layer.

Layer 1 — The Calculation Engine

At the base is Payroll Engine — an open-source .NET framework for building and running payroll regulations. It handles the infrastructure concerns: tenant management, period logic, case value history, result storage, retro correction mechanics, forecast isolation, and the scripting runtime that executes regulation code.

The engine itself contains no statutory values. No tax rates, no social security thresholds, no contribution ceilings. Those belong to the regulations, not the engine. This separation is what makes compliance updates safe: you update a data file, not the engine code.

Layer 2 — Country Regulations

A country regulation is a structured package of:

• Wage types — the calculations (gross pay, tax withholding, social security contributions, employer costs, net pay)
• Cases and case fields — the employee and company data model (tax class, social insurance number, benefit elections, employment type)
• Data regulations — versioned statutory values with validFrom dates (tax tables, contribution rates, thresholds)
• Integration tests — verified calculations against known scenarios, run on every change

PayrollEx currently covers eleven countries across Europe and North America: Germany, Austria, Switzerland, Belgium, Netherlands, Luxembourg, France, Spain, Portugal, United Kingdom, and United States.

Each regulation is maintained as an independent package. Germany's PAP 2026 update — new Vorsorgepauschale algorithm, AV component in the deduction ceiling, PKV data via ELStAM — ships as a versioned data regulation update, not a code change. The calculation engine picks up the new parameters automatically on January 1.

Layer 3 — Consolidation

Running payroll in eleven countries produces eleven separate result stores. For a provider, that's not enough — they need cross-country views: total employer cost per region, headcount trends by country, tax withholding comparisons across subsidiaries.

The consolidation layer provides this. Each country regulation includes a set of consolidation wage types (WT 7000–7030) that expose a uniform interface: gross pay, tax withholding, social security (employee and employer), and total employer cost. Any country can be queried against this interface without knowledge of the country-specific internals.

For regional consolidation — DACH (DE/AT/CH), Benelux (BE/NL/LU), Iberia (ES/PT) — there's a multi-tenant query layer that aggregates across separate tenant databases. Cross-currency results (EUR and CHF in one report) are handled with period-specific exchange rates.

Layer 4 — Adapters

Payroll data doesn't originate in a payroll system. Employee records, salary changes, benefit elections, and employment start dates live in HR platforms — Personio, Sage, AFAS, Silae. Getting that data into Payroll Engine cleanly, on a defined schedule, is the adapter layer's job.

Adapters are bidirectional connectors: they import master data from a source system into Payroll Engine's case model and can export computed results to ERP/finance systems. They handle authentication (OAuth 2.0, API key, token), pagination, delta sync (only changed records), and field mapping. The core adapter framework is a NuGet package; each provider adapter is a deployable unit that runs on the Adapter Console or Adapter Service host.

How It Fits Together: Composable Regulation

The four layers interact through a composable regulation model. Every tenant — every company running payroll — has a payroll configuration that stacks regulations in layers:

1. Country regulation — the statutory base (DE, NL, UK, …)
2. Industry regulation — sector-specific rules (IT collective agreement, public sector, financial services)
3. Company regulation — tenant overrides (custom benefits, company-specific allowances, local pay components)

Each layer can override or extend the layer below it. A company running German payroll with a car allowance adds a company regulation with a car allowance wage type. The statutory DE layer stays unchanged — it gets updated annually as German law changes. The company layer stays stable — it's maintained by the company.

A provider serving 200 companies across five countries has 200 payroll configurations, each with a different company layer, all sharing the same statutory country regulations. When Germany's January update ships, all 200 German tenants pick it up. No per-tenant intervention required.

Why Open Source at the Foundation

The calculation engine — Payroll Engine — is open source (MIT license, available at payrollengine.org). The country regulations and commercial products above it are not. This split is intentional and worth explaining.

Infrastructure should be auditable. Payroll calculations affect people's income, taxes, and statutory contributions. When a calculation produces an unexpected result, a provider needs to understand why — without depending on a vendor to explain their proprietary black box. An open-source engine means the calculation logic is inspectable, verifiable, and independently testable.

Infrastructure shouldn't be a moat. Locking payroll infrastructure behind a proprietary API creates dependency without benefit. The differentiator isn't the calculation engine — it's the quality, breadth, and maintenance of the compliance regulations on top of it. Open-sourcing the engine lets the ecosystem build on a shared foundation.

Infrastructure has a long lifecycle. Payroll calculations need to produce the same result in 2031 that they did in 2026 — for audit, for retro correction, for historical reporting. Open source ensures that the engine remains available and auditable for that entire lifecycle, independent of commercial decisions.

The commercial regulations — the actual country compliance logic — require continuous expert maintenance. That's what PayrollEx provides: a curated, tested, annually updated compliance layer on top of a stable open-source engine.

Who It's For

PayrollEx is built for operators who run payroll as a service or as infrastructure for others — not as an end-user payroll application. Three roles benefit directly:

For all three, the value proposition is the same: instead of maintaining country-specific payroll logic as proprietary application code, they embed a compliance infrastructure layer that handles the statutory complexity independently.

This shifts the operational model. Annual regulatory updates — new German PAP, UK April NIC changes, Spanish IRPF table revisions — become package deployments, not development projects. Compliance testing is a verified artifact, not a manual QA process. And the audit trail — every calculation, every parameter version, every retro delta — is built into the infrastructure, not bolted on later.