No-Code Regulation Development: From Spreadsheet to Production

The Regulation Development Bottleneck

Every January, payroll providers face the same problem. Tax rates change. Contribution ceilings shift. Social security algorithms get revised. The statutory gazette publishes new numbers, and someone has to turn those numbers into working payroll calculations.

In traditional payroll software, that someone is a developer. A payroll consultant reads the gazette, interprets the legal text, writes a specification document, hands it to a developer, and waits. The developer translates the specification into code, makes assumptions about edge cases the spec didn't cover, and delivers a build. The consultant tests it, finds discrepancies, writes corrections. The cycle repeats until the numbers match — or until the deadline arrives and everyone agrees to ship what they have.

This is the regulation development bottleneck, and it's the single biggest cost driver in payroll compliance maintenance. Not the complexity of the law itself — the translation layer between the people who understand the law and the systems that execute it.

Consider what happens when Germany publishes a new PAP (Programmablaufplan) for income tax calculation. The algorithm changes how the Vorsorgepauschale is computed — a deduction for health insurance and pension contributions that affects every employee's tax withholding. A payroll consultant reads the PAP and understands the change immediately. But implementing it requires modifying C# code inside a proprietary payroll engine, which requires a developer, a build, a test cycle, and a deployment.

The delay isn't in understanding the change. It's in getting the change into production. And that delay — typically weeks, sometimes months — is what creates compliance risk. The January gazette is published, the rates take effect on January 1, and the software is still running last year's calculations while the development team catches up.

What if the person who understands the change could also be the person who implements it?

The No-Code Model: Tokens and Actions

Payroll Engine uses a declarative model for regulation logic called valueActions. Instead of writing C# code to compute a wage type's value, a regulation author writes a sequence of token expressions that describe the calculation in a readable, auditable syntax.

The core idea is simple: every piece of data the regulation needs — an employee's salary, a tax rate from a statutory table, another wage type's result, a running total from a collector — has a token prefix that tells the engine where to find it. No imports, no object initialization, no method calls. Just a token and a name.

The Token System

A wage type that computes an employer health insurance contribution might look like this in the regulation JSON:

{
  "wageTypeNumber": 6000,
  "name": "HealthInsuranceEmployer",
  "valueActions": [
    "^^GrossIncome * ^#ContributionRates(PeriodStartYear, 'HealthEmployer')"
  ]
}

That's the entire calculation. No class, no method, no using statements, no build process. The expression reads: "Take the employee's gross income, multiply it by the employer health insurance rate from the contribution rates lookup table for the current year." A payroll consultant can read this and verify it against the gazette in seconds.

Expressions can be chained. A wage type can apply multiple actions in sequence — setting a base value, applying caps, applying floors, rounding — each as a separate, readable step:

"valueActions": [
  "^^MonthlySalary * ^^WorkingDaysRatio",
  "? ^| > ^#Thresholds(PeriodStartYear, 'Ceiling') : ^#Thresholds(PeriodStartYear, 'Ceiling')",
  "Round(^|, 2)"
]

Line one computes the base. Line two caps the result at a statutory ceiling (the ? prefix marks a conditional action). Line three rounds to two decimal places. Each line is independently readable and independently testable.

The token model covers the majority of payroll calculations. Contribution rates applied to a base, caps at statutory ceilings, conditional rules based on employee attributes (tax class, marital status, state), accumulation into collectors for reporting — all of this works with token expressions alone. No developer needed. No build process. No deployment pipeline beyond updating a JSON file.

When No-Code Isn't Enough: Custom Actions

Token expressions are powerful for declarative calculations — applying rates, caps, floors, and conditions. But payroll isn't only simple arithmetic. Some calculations require iterative logic, progressive tax algorithms, multi-step interpolation, or complex decision trees that can't be expressed in a single token chain.

Germany's income tax algorithm (the PAP) is a good example. It's a multi-page decision tree published annually by the Federal Ministry of Finance. It involves iterative calculation of the Vorsorgepauschale, progressive tax brackets with rounding rules at each step, solidarity surcharge with a mitigation zone, and church tax applied as a percentage of the income tax. Expressing this as token arithmetic would produce an unreadable wall of conditional expressions that no consultant could verify.

For these cases, Payroll Engine provides Custom Actions: C# methods that implement complex logic and are called from the same valueActions array as token expressions.

A custom action is a C# method decorated with the [WageTypeValueAction("name")] attribute. It lives in a script file alongside the regulation JSON. It has full access to the Payroll Engine scripting API — reading case values, querying lookup tables, accessing other wage types, navigating periods. But from the regulation's perspective, it's just another action in the sequence:

{
  "wageTypeNumber": 5100,
  "name": "IncomeTax",
  "valueActions": [
    "DECalculateIncomeTax('DE.TaxClass', 'DE.ChurchTaxState')"
  ]
}

The regulation JSON is still declarative — it says what to calculate and which parameters to pass. The how lives in the custom action script, where a developer implements the PAP algorithm in full C#. The separation is clean: the regulation author decides which custom action to call and with what parameters. The developer implements the algorithm.

The Custom Action API

Inside a custom action, the developer has access to the complete Payroll Engine scripting environment:

This is still scripting, not application development. There's no database access, no HTTP calls, no file I/O. The script runs inside the Payroll Engine's Roslyn scripting sandbox with access only to payroll data. It's C# — but it's contained C#, purpose-built for statutory calculations.

The key architectural benefit is that custom actions are called by name from the declarative valueActions array. A payroll consultant can look at the regulation JSON and see: "Wage type 5100 calls DECalculateIncomeTax with parameters tax class and church tax state." They don't need to read the C# to understand what the wage type does. They only need the C# when they need to understand how the algorithm works — which is a debugging concern, not a regulation authoring concern.

The Regulation Is JSON, Not Code

Here's the part that changes the operational model. A Payroll Engine regulation isn't a compiled DLL. It's not a set of C# source files that need to be built. It's JSON.

Every component of a regulation is defined in structured JSON files:

• Wage types — number, name, value actions, collectors, cluster membership
• Cases and case fields — the data model for employees, companies, and employment relationships
• Collectors — named accumulators that track running totals across wage types
• Lookups — versioned reference tables with threshold or progressive semantics
• Data regulations — annual statutory parameters (tax rates, contribution ceilings, thresholds) with validFrom dates

This JSON-first model has consequences that go beyond syntax preference.

Version control becomes meaningful. A regulation stored as JSON can be diffed in Git the same way source code is diffed. When Germany's January update changes the health insurance contribution ceiling from 66,150 EUR to 69,300 EUR, that change shows up as a one-line diff in a data regulation file. A reviewer can see exactly what changed, verify it against the gazette, and approve it. No reading through compiled code to figure out where the number lives.

Export and import become trivial. The exchange JSON format lets a regulation be exported from one Payroll Engine instance, transferred as a file, and imported into another. This is how regulations move between development, testing, and production environments. It's also how regulations are distributed — as versioned JSON packages, not as installers or compiled binaries.

Auditors can read the regulation. A statutory auditor verifying that your payroll system correctly implements German income tax law doesn't need to read C# source code. They can read the regulation JSON — the wage type definitions, the lookup tables with tax rates, the case field model. The token syntax (^^GrossIncome * ^#ContributionRates(2026, 'HealthEmployer')) is more readable than the equivalent C# method, and it's the authoritative source. There's no "compiled form" that might differ from the source.

Non-developers can modify the regulation. When a contribution rate changes, a payroll consultant can open the data regulation JSON, find the lookup table, change the number, and submit the change for review. No IDE, no build, no compiler. The change process is the same as editing a configuration file — because that's exactly what it is.

This model also enables something that proprietary payroll systems make difficult: layered override. A company regulation can override specific wage types or case fields from the country regulation without modifying the country regulation itself. The override is a separate JSON file that gets stacked on top. When the country regulation updates in January, the company override remains intact — it only touches what the company has customized.

The Migration: From Low-Code to No-Code

This model didn't start as no-code. It evolved into it through deliberate migration — and the story of that migration illustrates why the no-code approach matters.

When PayrollEx's German regulation (DE.Entgeltabrechnung) was first built, most wage types used valueExpression — inline C# code that ran in the Roslyn scripting engine. A wage type calculating employer health insurance contribution might have looked like this:

"valueExpression": "var gross = GetCaseValue<decimal>(\"DE.SvBrutto\");
var rate = GetLookupField<decimal>(\"ContributionParameter\", PeriodStart.Year.ToString(), \"KvAgSatz\");
return Math.Round(gross * rate, 2);"

This works. The calculation is correct. But it's opaque to anyone who isn't a C# developer. A payroll consultant looking at this sees syntax — curly braces, angle brackets, semicolons — not a calculation. They can't verify it against the gazette. They can't suggest corrections. They can't review it for a compliance audit without developer translation.

The migration — internally designated Phase 2.5 — replaced every valueExpression with equivalent valueActions using the token syntax. The same calculation became:

"valueActions": [
  "^^SvBrutto * ^#ContributionParameter(PeriodStartYear, 'KvAgSatz')",
  "Round(^|, 2)"
]

Same logic. Same result. But now a payroll consultant can read it: "Social insurance gross times the employer health insurance rate, rounded to two decimals." The token names match the domain language. The structure matches the calculation sequence. No C# knowledge required.

What Stayed as Code

Not everything migrated. The German regulation still has custom actions for genuinely complex logic:

• The PAP income tax algorithm — a multi-step decision tree that can't be reduced to token arithmetic
• The Gleitzone (Midijob) interpolation formula — a statutory interpolation between mini-job and regular contribution calculation that involves iterative computation
• Garnishment priority logic — where multiple creditors compete for a share of disposable income, subject to protected amounts that depend on the number of dependents

These remain as custom actions — C# scripts called from valueActions. But they're the exception. In the German regulation, roughly 85% of wage types are now pure token expressions. The C# that remains is genuinely algorithmic, not boilerplate rate-times-base calculations.

Who Benefits

The no-code regulation model shifts who can do what in payroll compliance maintenance. The impact varies by role.

Payroll Consultants

The most direct beneficiary. A payroll consultant who understands German or Dutch or Spanish tax law can now read the regulation that implements it. They can verify that a wage type correctly applies the statutory rate. They can trace a calculation from gross income to net pay through the wage type chain. They can review a data regulation update and confirm that the new contribution ceiling matches the gazette.

This isn't just about reading. Consultants can author regulation changes. When France adjusts the prélèvement à la source rates in January, a consultant who understands the change can modify the data regulation JSON, update the lookup table with new rates, and submit the change. The development team's role shifts from "implement the change" to "review and test the change." The domain expert drives. The developer validates.

Providers and Bureaus

For payroll providers serving multiple countries, the no-code model changes the annual update cycle. Instead of mobilizing developer teams for each country's January changes, providers can delegate data regulation updates to payroll domain experts — either internal compliance staff or the PayrollEx regulation maintenance service. Developer resources stay focused on platform features and infrastructure, not statutory parameter updates.

The JSON-first approach also means regulation updates are deployable artifacts, not code releases. A new German data regulation for 2027 is a versioned JSON package that gets imported into the running system. No recompilation, no service restart, no downtime. The engine picks up the new parameters based on validFrom dates.

Auditors and Compliance Officers

Regulatory audits in payroll are about one question: does the system calculate correctly according to the current statutory rules? Answering that question in a proprietary system means trusting the vendor's documentation. Answering it in a no-code regulation model means reading the regulation JSON and comparing it to the gazette.

Every wage type's logic is visible. Every statutory parameter is stored in a versioned lookup table with a clear validFrom date. Every calculation step is traceable through the token chain. When an auditor asks "How does the system compute the employer's pension contribution?" — the answer is a specific line in a specific JSON file, not a pointer to a compiled binary.

Integration tests serve as compliance artifacts. Each test is a documented scenario — specific employee parameters, specific statutory values, specific expected results with step-by-step arithmetic. The tests ship with the regulation. An auditor can review the test scenarios and verify that the expected results match their own calculations. If they disagree, they can point to the specific line where the divergence occurs.

The "Regulator" Role

PayrollEx defines three operational roles: Provider (runs payroll as a service), Regulator (builds and maintains regulations), and Automator (integrates and deploys). The no-code model is specifically designed for the Regulator role — and the key insight is that a Regulator doesn't need to be a developer.

A Regulator reads statutory gazettes, understands payroll law, and translates legal requirements into regulation definitions. In a no-code model, that translation is direct: legal text becomes wage type definitions, statutory tables become lookup data, and calculation rules become token expressions. The Regulator authors the regulation in the same language the law is written in — domain language, not programming language.

This changes who can fill the role. Instead of requiring a rare combination of payroll expertise and software development skill, the Regulator role requires payroll expertise and the ability to work with structured data. Those are different people — and there are more of them.

The bottleneck doesn't disappear entirely — custom actions still require developers, complex regulations still require deep expertise, and testing infrastructure still requires engineering investment. But the bottleneck narrows. The 80% of regulation work that is parameter updates, rate changes, and straightforward calculation rules moves from developer-dependent to domain-expert-driven. That's the shift.