Why the Engine Is Open Source (and the Regulations Are Not)

The Deliberate Split

Open source in payroll sounds like a contradiction. Payroll is compliance-heavy, liability-loaded, and deeply regulated. Why would anyone open-source the engine that runs it?

The answer requires separating two things that are usually bundled together: the calculation infrastructure and the compliance content.

The calculation infrastructure is what Payroll Engine provides. It's the framework layer: tenant management, period logic, case value history, retro correction mechanics, the scripting runtime, result storage, the REST API, and the payrun execution pipeline. It handles how payroll calculations are structured, stored, versioned, and executed. It's a general-purpose engine — it can run German payroll, Dutch payroll, or any other country's payroll, but it contains no statutory values itself. No tax rates. No contribution ceilings. No social security thresholds.

The compliance content is what sits on top. Country regulations — the wage types, case models, data regulations, lookup tables, custom action scripts, and integration tests that implement a specific country's statutory payroll rules. Germany's PAP algorithm, the Netherlands' loonbelasting tables, Spain's IRPF brackets, the UK's PAYE thresholds. These are maintained by payroll domain experts, updated annually (or more frequently), and verified against official statutory gazettes.

Payroll Engine, the infrastructure layer, is MIT-licensed and open source, available at payrollengine.org. Country regulations, consolidation packages, the write-capable MCP Server Pro, and system adapters are commercial products, available through PayrollEx.

This isn't a compromise or a marketing strategy. It's an architectural decision rooted in three arguments about how payroll infrastructure should work: auditability, ecosystem health, and lifecycle resilience.

Infrastructure Should Be Auditable

Payroll calculations affect people's income. Not in the abstract — in the direct, tangible sense that an incorrect tax withholding means an employee either pays too much or too little, and both create real problems. An incorrect social security contribution means the employer is either under-reporting (regulatory risk) or over-paying (financial waste). An incorrect net pay means the employee's bank account receives the wrong amount, and the payroll provider's client receives a complaint.

When something goes wrong — and in payroll, something always eventually goes wrong — the first question is: why did the system produce this result?

In a proprietary payroll engine, the answer to that question is mediated by a vendor. You submit a support ticket. You wait for an engineer to investigate. You receive an explanation that you have to trust, because you can't verify it yourself. The calculation logic is a black box. You can see the inputs and the outputs, but the path between them is opaque.

This is how most payroll systems work, and it functions well enough — until it doesn't. Until an auditor asks you to demonstrate that your system correctly implements the current statutory rules. Until a retro correction produces unexpected results and you need to trace the calculation through three historical periods to find the discrepancy. Until a new country regulation ships and you need to verify it before deploying it to production.

An open-source calculation engine changes the dynamic. When a calculation produces an unexpected result, a provider's engineering team can trace the execution path through the engine source code. They can set breakpoints, inspect intermediate values, and identify exactly where the calculation diverges from expectations. They don't need the vendor's cooperation. They don't need to wait for a support response. They can diagnose the problem themselves, on their own schedule.

This capability matters most in edge cases — the scenarios that occur once in a thousand employees and aren't covered by standard test suites. A part-time employee in Saxony (special PV contribution rules) with church tax (variable by state) and a company car (Geldwerter Vorteil) and a mid-month salary change (time-segmented calculation). No vendor test suite covers every permutation. But an open-source engine lets you trace the specific permutation that produced an unexpected result and understand why.

Trust in payroll infrastructure shouldn't be "believe the vendor." It should be "verify for yourself." Open source makes that possible. It doesn't make it easy — reading engine code requires engineering skill. But it makes it possible, and that possibility is the foundation of genuine compliance confidence.

Infrastructure Shouldn't Be a Moat

The traditional payroll software model treats everything as proprietary: the calculation engine, the regulatory content, the API, the data model. Switch vendors and you lose everything — your configuration, your historical data, your regulatory setup, your integration logic. The switching cost is so high that most providers stay with their vendor long after the product stops meeting their needs.

This lock-in is usually justified as "protecting intellectual property." But it's worth asking: what's actually proprietary in a payroll calculation engine? The ability to multiply a salary by a tax rate? Period-based data storage? Retro correction logic? These are well-understood patterns, documented in accounting textbooks and implemented in every payroll system since the 1970s. The engine infrastructure isn't novel. It's necessary.

The actual differentiator in payroll isn't the engine. It's the quality, completeness, and maintenance cadence of the compliance regulations. Can the vendor's German regulation handle the 2026 PAP changes correctly? Does their Dutch regulation implement the new arbeidskorting tiers? Is their Spanish regulation updated for the annual Orden PJC bases de cotización? These are hard problems that require deep domain expertise, continuous monitoring of statutory changes, and rigorous testing against official sources. That's where the value is — and that's what customers pay for.

Open-sourcing the engine makes this explicit. The engine is shared infrastructure. Anyone can use it, inspect it, extend it, build on it. The regulations — the compliance content that requires expert maintenance — are the commercial offering. Providers don't pay for the ability to run payroll calculations. They pay for the assurance that those calculations are correct, current, and maintained by domain experts who monitor statutory changes across eleven countries.

This model also benefits the ecosystem. A payroll provider building on Payroll Engine can hire their own developers to extend the engine, build custom integrations, or develop company-specific features. They're not dependent on the vendor's roadmap for infrastructure improvements. If they need a feature the engine doesn't have, they can build it — or contribute it back.

For EOR platforms and HCM vendors embedding payroll into their products, the open-source engine means no API lock-in. If PayrollEx as a company were to disappear tomorrow, the engine would still be available on GitHub under the MIT license. The regulations would need a new maintenance provider — but the infrastructure layer would remain stable and available. That's a fundamentally different risk profile than depending on a proprietary vendor whose engine disappears when the company does.

The Long Lifecycle Argument

Payroll has a temporal property that most software doesn't: historical calculations must remain reproducible for years.

When an employee's 2026 payroll is audited in 2031, the auditor needs to see not just the results that were produced in 2026 — they need to verify that those results are correct according to the rules that were in effect in 2026. That means the calculation logic, the statutory parameters, and the engine that executed them all need to be available and functional five years later.

For retro corrections, the requirement is even more immediate. A salary change discovered in March that affects January's calculation needs to be recalculated using January's parameters and January's rules — not March's. The engine must be able to execute a calculation for any historical period using the parameters that were in effect during that period.

This is a lifecycle problem, and it's one where open source has a structural advantage over proprietary software.

Vendor continuity risk. Proprietary payroll vendors get acquired, pivot, discontinue products, or go out of business. When they do, their customers face a migration — and migrating a payroll system with years of historical data and country-specific configuration is one of the most painful projects in enterprise software. An open-source engine doesn't have this risk. The source code is on GitHub. It's MIT-licensed. It can be forked, maintained, and operated by anyone, regardless of what happens to the original maintainer.

Version availability. When you need to reproduce a 2026 calculation in 2031, you need the 2026 version of the engine and the 2026 version of the regulations. Open-source version history is permanent — every tagged release of Payroll Engine will remain available on GitHub indefinitely. You can check out the exact commit that was running in production in January 2026 and execute the calculation. Proprietary vendors may not maintain access to five-year-old binaries.

Regulatory preservation. Payroll regulations change annually. Germany's 2026 PAP is different from the 2025 PAP, which is different from the 2024 PAP. Each version needs to be preserved and executable for the historical periods it covers. The versioned data regulation model — where each year's statutory parameters are stored in a separate regulation with a validFrom date — handles this at the content level. The open-source engine handles it at the infrastructure level: the execution framework remains available, auditable, and reproducible across the full lifecycle.

This matters most for providers who run payroll for others — bureaus, EOR platforms, HCM vendors. They carry compliance liability for their clients' payroll. If a 2026 calculation is challenged in 2029, the provider needs to demonstrate correctness — not by asserting that the vendor was reliable, but by re-executing the calculation and showing the result. An open-source engine with versioned regulations makes that demonstration possible.

What's Open Source (and What's Not)

The line between open source and commercial follows the infrastructure-versus-content boundary. Everything that constitutes the calculation framework is open. Everything that constitutes compliance content or operational tooling is commercial.

The pattern is consistent. The engine, the API, the frontend, the CLI, the client libraries, the read-only MCP server, and the AI context — everything a developer needs to build on the platform — is open source. The compliance content, the write-capable operational tools, and the system integrations — everything a provider needs to run payroll in production — is commercial.

This split means a developer can download the complete Payroll Engine stack, build a custom regulation, run calculations, test results, and develop integrations — all without a commercial license. They can evaluate the platform fully before committing. They can build prototypes, run proofs of concept, and validate the architecture against their requirements.

What they can't do without a commercial license is deploy a compliant German or Dutch or Spanish payroll regulation. For that, they need the maintained, tested, annually updated regulation packages that PayrollEx provides. The engine is the foundation. The regulations are the product.

The Business Model

Software companies that open-source their core product face a legitimate question: how do you sustain the business? The answer for PayrollEx is straightforward, because payroll compliance has a built-in maintenance requirement that doesn't exist in most software domains.

The engine is free. The regulations are the product.

Every country's payroll regulations change every year. Germany publishes a new PAP (income tax algorithm) every December, effective January 1. The Netherlands updates loonbelasting tables, arbeidskorting tiers, and social security premiums annually. Spain revises IRPF brackets and bases de cotización. The UK adjusts PAYE thresholds, NI rates, and pension auto-enrollment minimums. France updates prélèvement à la source rates and cotisations sociales ceilings.

These aren't minor patches. Germany's 2026 PAP restructured the Vorsorgepauschale calculation, added an AV component to the deduction ceiling, and introduced a new ELStAM data path for private health insurance. The Netherlands' 2026 update added new arbeidskorting tiers and adjusted all WML-linked thresholds. Each of these changes requires statutory analysis, regulation modification, integration test updates, and compliance verification against official sources.

That continuous maintenance — performed by payroll domain experts who read statutory gazettes, understand contribution formulas, and verify calculations against official tables — is what customers pay for. It's not a one-time purchase. It's an annual service, because the regulatory landscape changes annually.

The business model aligns incentives correctly. PayrollEx has no reason to make the engine proprietary — doing so wouldn't increase regulation sales, and it would reduce adoption. Providers adopt the engine because it's open, auditable, and risk-free to evaluate. They buy regulations because maintaining eleven countries' statutory compliance in-house is more expensive and more risky than subscribing to a maintained service.

No Engine Lock-In

This is the part that makes the model work for providers. Because the engine is open source, a provider's investment in Payroll Engine — their integrations, their company regulations, their test infrastructure — isn't at risk. If they choose to stop purchasing regulation maintenance from PayrollEx, they keep the engine. They keep their company regulations. They keep their historical data and calculation results. They lose the annual regulatory updates — which means they'd need to maintain statutory compliance themselves — but they don't lose the platform.

This is fundamentally different from proprietary payroll vendors, where stopping payment means losing access to the engine, the API, and potentially the historical data. In the PayrollEx model, the engine is an asset the provider owns (under MIT license), not a service they rent.

The result is a relationship based on value, not dependency. Providers continue purchasing regulation maintenance because it's worth more than the cost of doing it themselves — not because they have no alternative. That's a healthier dynamic for both sides, and it's only possible because the engine is open source.

For providers evaluating PayrollEx, the question isn't whether open source is viable for payroll — it's whether the alternative (proprietary everything) serves their interests better. When the alternative means vendor lock-in, opaque calculations, and dependency on a single company for both infrastructure and compliance content, the open-source foundation starts looking less like a risk and more like the only responsible choice.