Electronic Filing: When Payroll Meets Government Systems

The Problem

Electronic filing in payroll isn't simply "export and send." Every country mandates specific machine-readable formats — XML schemas, code tables, identifier systems, and cross-validation rules — that your payroll output must satisfy exactly. A single mismatched code, an identifier in the wrong format, or a total that doesn't reconcile against its line items means rejection. And rejection means penalties.

But the real complexity goes deeper than output formatting. In several countries, government systems feed data back into the payroll calculation itself. The filing isn't just a downstream report — it's an upstream input that drives core tax parameters. This creates a bidirectional dependency between your payroll engine and government infrastructure that most systems handle poorly.

Consider what this means operationally: your payroll system must not only generate correct declarations, but must also consume authority responses and route them into the correct calculation parameters — automatically, reliably, and in time for the next pay run. A late ELStAM response or a stale PAS rate produces incorrect net pay.

Then add schema versioning. The French DSN NEODeS schema changes annually (sometimes mid-year for corrective releases). Germany's ELSTER XML schema follows the annual PAP revision. Spain's Sistema RED updates its ficheros FAN/FDI format with each campaign. The UK's RTI schema tracks HMRC's policy changes. Every January, payroll teams face a compliance cliff where last year's filing format is suddenly rejected.

The scale is staggering. France's DSN alone replaced over 30 separate declarations (DADS-U, DUCS, attestations Pôle Emploi, DPAE, and more) with a single monthly submission containing hundreds of structured blocks. Germany files to three separate authorities — the tax office (LStAnmeldung), the health insurance fund (Beitragsnachweis), and the pension/employment insurance carrier (SV-Meldungen). Each has its own XML schema, its own validation rules, and its own rejection codes.

How It Works

Each country has evolved its own electronic filing architecture, shaped by its administrative traditions, its social security structure, and its political appetite for digital transformation. Here's how the six major systems work in practice.

France: DSN (Déclaration Sociale Nominative)

The DSN is the most ambitious electronic payroll filing system in Europe. Introduced progressively from 2013 and mandatory since 2017, it replaced over 30 separate declarations with a single monthly submission to the NEODeS platform (Norme d'Échanges Optimisée de Données Sociales).

A monthly DSN contains:

• Rubriques — individual data blocks per employee (S21.G00.51 for remuneration, S21.G00.78 for bases, S21.G00.81 for contributions)
• CTP codes (Code Type de Personnel) — 3-digit codes identifying the contribution type and rate basis (e.g., CTP 100 for general URSSAF contributions)
• OPS blocks (Organisme de Protection Sociale) — identifies which fund receives each contribution, with SIRET + code institution
• Aggregate totals — S21.G00.23 blocks with bordereaux that must reconcile against the sum of individual rubriques

The filing deadline is the 5th or 15th of the following month (depending on company size — fewer than 50 employees file on the 15th, 50+ on the 5th). Late filing triggers a penalty of 1.5% of the monthly social security ceiling per employee, per month of delay (§ L133-5-3 Code de la Sécurité Sociale).

Critically, the DSN isn't just output. The DGFIP (Direction Générale des Finances Publiques) responds with the employee's PAS rate — the withholding rate for income tax. This rate flows back into the next payroll calculation. If an employee's life situation changes (marriage, birth), the new PAS rate arrives via DSN retour and must be applied from the following pay period.

Germany: Three authorities, three schemas

Germany's electronic filing landscape reflects its fragmented social security architecture. Employers file to three separate systems:

The LStAnmeldung (§ 41a EStG) aggregates all employees' income tax, solidarity surcharge, and church tax into a single periodic declaration. Filing frequency depends on prior-year tax volume: monthly if > EUR 5,000, quarterly if EUR 1,080–5,000, annually if < EUR 1,080.

The Beitragsnachweis must arrive at the Krankenkasse by the second-to-last banking day of the current month — meaning it must be filed before the month ends, based on estimated wages. The estimated values are reconciled in the following month's filing.

ELStAM: The upstream feed

Germany's ELStAM system (§ 39e EStG) is the canonical example of filing-as-input. When an employer registers an employee, the Finanzamt returns electronic tax deduction characteristics:

• Steuerklasse (tax class I–VI)
• Kinderfreibeträge (child allowances — 0.5 per child)
• Kirchensteuer-Merkmal (church tax denomination)
• Freibetrag / Hinzurechnungsbetrag (annual tax allowance / addition amount)
• PKV Jahresbeitrag (private health insurance annual premium — since PAP 2026)
• Pflegepflichtversicherung Jahresbeitrag (private long-term care annual premium — since PAP 2026)

These values feed directly into the PAP algorithm. The PKV data path (introduced with PAP 2026 per BMF circular of 14.8.2025) means that for privately insured employees, the actual insurance premiums — not a calculated proxy — determine the Vorsorgepauschale. A stale or missing ELStAM response produces an incorrect tax calculation.

United Kingdom: RTI (Real Time Information)

The UK's RTI system, mandatory since April 2013, requires employers to report pay information to HMRC at or before the time of payment — not monthly, not annually, but in real time. Two main submissions:

• FPS (Full Payment Submission) — filed on or before each payday, containing gross pay, tax deducted (PAYE), National Insurance contributions, student loan deductions, and pension contributions for every employee paid in that period
• EPS (Employer Payment Summary) — filed monthly by the 19th, containing employer-level adjustments (statutory pay recoveries, Employment Allowance claims, CIS deductions)

HMRC enforces strict timeliness. An FPS filed after the payment date triggers a late filing penalty: GBP 100 per 50 employees per month for the first year, escalating to 5% of tax/NI due for persistent non-compliance (Taxes Management Act 1970, § 98A).

The RTI schema includes over 90 data fields per employee per submission. Tax codes (driven by HMRC's coding notices) operate as calculation input — a new P9 coding notice changes the employee's tax-free allowance and must be reflected in the next FPS.

Spain: Modelo 111 + Sistema RED

Spain's filing architecture separates tax and social security into distinct systems with different periodicities:

• Modelo 111 — quarterly IRPF retention declaration (filed by April 20, July 20, October 20, January 20) to the AEAT, aggregating all employee withholdings for the quarter
• Modelo 190 — annual informative declaration (filed by January 31) containing per-employee detail of all IRPF retentions and payments in kind for the prior year
• Sistema RED — monthly social security filing (Remisión Electrónica de Datos) to the TGSS, containing bases de cotización, worker types (CCC codes), contract types, and contribution group codes

The Sistema RED uses fichero FAN (Fichero de AFiliación y Altas de Nómina) for workforce movements and fichero FDI (Fichero de conceptos retributivos Detallado Individual) for detailed contribution bases. Each fichero has strict code tables: over 200 claves de contrato, 11 grupos de cotización, and situational codes for ERTE, partial retirement, and disability.

Netherlands: Loonaangifte

The Dutch Loonaangifte is notable for combining tax and social security into a single monthly submission to the Belastingdienst. Filed by the last day of the month following the pay period, it contains:

• Loonbelasting/premie volksverzekeringen (income tax + national insurance)
• Premies werknemersverzekeringen (employee insurance contributions — WW, WIA, WAO)
• Inkomensafhankelijke bijdrage ZVW (income-dependent health insurance contribution)
• Sector codes and risk group classifications

The Loonaangifte uses a fixed-format record structure (not XML) with field positions defined in the Handboek Loonheffingen. Each employee record includes an BSN (Burger Service Nummer), employment code (code soort inkomstenverhouding), and insurance indicators (verzekeringsindicaties) that determine which premiums apply.

Luxembourg: Déclaration Annuelle + Nachweis Frontalier

Luxembourg's filing requirements reflect its unique cross-border workforce (over 200,000 frontaliers commute from France, Germany, and Belgium):

• Déclaration Annuelle des Rémunérations (RTS) — annual declaration to the ACD (Administration des Contributions Directes) per employee, detailing gross salary, tax withheld, social advantages, and deductions
• Nachweis Frontalier — certificate for cross-border workers confirming income earned in Luxembourg, used by the worker's home-country tax authority to apply the correct exemption or credit method under the applicable double tax treaty
• CCSS declarations — monthly contribution statements to the Centre Commun de la Sécurité Sociale

The frontalier certificate requires precise allocation of working days — days worked in Luxembourg vs. days worked from home (relevant since post-COVID teleworking agreements with France, Belgium, and Germany introduced specific day thresholds: 34 days for FR, 34 days for BE, 19 days for DE).

Where It Gets Tricky

Filing as calculation input: the bidirectional trap

The fundamental architectural challenge is that some filings aren't downstream reports — they're upstream inputs. This creates circular dependencies that sequential batch processing cannot resolve cleanly.

France PAS rate flow: You calculate net pay → generate DSN → submit to NEODeS → DGFIP responds with updated PAS rate → you apply the new rate in the next calculation. But what if the rate arrives mid-month? What if the response is delayed? What if the rate conflicts with the employee's declaration? The DSN cahier technique (v2024.1) specifies priority rules: authority rate > individualized rate > neutral rate (taux neutre). But integrating these rules into a payroll engine requires treating the filing response as a first-class case value with its own effective dating.

Germany ELStAM feedback: When an employee changes their tax class (e.g., after marriage — Steuerklasse IV → III), the new characteristics arrive via ELStAM. The employer must apply the change from the next available pay period. But ELStAM responses can be delayed by weeks. If the January payrun runs before the December ELStAM response arrives, January uses stale parameters. February must then handle the correction — either retroactively adjusting January or applying the new class prospectively from February. § 39e Abs. 6 EStG requires application from the next pay period after receipt, not retroactively.

Cross-validation between declarations

Authorities don't just validate individual declarations — they cross-check between related submissions. In France, the DSN aggregate totals (bloc S21.G00.23) must equal the sum of individual rubriques. But the rounding rules differ: individual contributions are rounded per employee, then summed. The aggregate is not simply a re-rounding of the total. A EUR 0.01 discrepancy between the two methods triggers a rejection code 00L ("Anomalie de cohérence des montants").

In Germany, the monthly Beitragsnachweis (contribution proof) must reconcile against the individual SV-Meldungen filed for the same period. The Beitragsnachweis contains aggregate contribution amounts by Beitragsgruppe (contribution group). If an employee's Personengruppe changes mid-month (e.g., from regular employment to Midijob), the filing must split their contributions across two Beitragsgruppen — and both must reconcile against the total.

Annual schema changes

Every country updates its filing schemas annually, typically effective January 1 (or April 6 in the UK). The changes range from trivial (new code values) to structural (new mandatory blocks, changed cardinalities, removed fields).

Recent breaking changes by country:

Real-time vs. periodic deadlines

The UK's RTI model is fundamentally different from continental periodic filings. An FPS must be filed on or before each payday — not monthly, not by a deadline, but in real time. For a weekly payroll with 500 employees, that's 52 FPS submissions per year, each subject to the late-filing penalty regime.

This creates operational pressure that monthly filing systems don't face. A payroll calculation error discovered after the FPS is submitted requires an Additional FPS or an EYU (Earlier Year Update if it crosses the tax year). The correction must reference the original submission and explain the variance. Late corrections accumulate penalty risk.

Meanwhile, Germany's Beitragsnachweis operates on a quasi-real-time basis — due by the second-to-last banking day of the current month, it must estimate wages not yet paid. The Schätzverfahren (estimation procedure) compares last month's actual against this month's estimate, with reconciliation in the next period. This forward-filing requirement means the contribution proof is inherently provisional.

How PE Solves It

Payroll Engine's filing architecture is built on four design principles that separate declaration logic from calculation logic while maintaining full traceability.

1. Report architecture with endExpressionFile

Each electronic filing is implemented as a PE Report with an endExpressionFile — a C# script that executes after the payrun completes, with full access to all calculated wage type results. The report script queries the payrun results, transforms them into the target schema, and produces the filing output.

This architecture means filing logic is completely decoupled from calculation logic. The wage type chain runs independently; the report script consumes its results. When a schema changes, only the report script is updated — the underlying calculation remains untouched. When a new filing element is added, the report script simply queries additional wage types.

The endExpressionFile pattern provides full .NET capability: XML serialization, schema validation, digital signature preparation, and file output — all within PE's sandboxed scripting environment. Complex transformations (like mapping 200+ CTP codes to contribution types) are handled via lookups that the script queries at runtime.

2. FastReport templates for formatted output

For declarations that require specific visual layouts (LStAnmeldung PDF, employee payslips, Modelo 190 annual summary), PE uses FastReport .NET templates. The report script populates a DataSet with structured data; the FRX template handles presentation, pagination, and format-specific output (PDF, XML, CSV).

This separation means the same underlying data can produce multiple output formats from a single payrun — an XML filing for the authority and a human-readable PDF for the employer's records — without duplicating calculation or transformation logic.

3. XML generation via report scripts

For machine-readable filings (DSN, ELSTER, RTI), the report script generates well-formed XML directly using .NET's XDocument / XmlWriter APIs. The script handles namespace declarations, element ordering, code lookups, and aggregate calculations — all validated against the target schema before output.

A typical DSN generation script follows this flow:

1. Query all employees in the payrun period with their wage type results
2. For each employee, map wage types to DSN rubriques (S21.G00.51 blocks) using a CTP lookup table
3. Generate OPS blocks by grouping contributions by fund (URSSAF, Agirc-Arrco, Prévoyance)
4. Calculate aggregate totals (S21.G00.23) by summing individual blocks
5. Validate cross-totals (sum of rubriques = aggregate) before finalizing
6. Write the complete XML to the output file with NEODeS-compliant encoding and headers

4. Data regulation satellites for schema parameters

Filing-specific parameters — CTP codes, OPS identifiers, Beitragsgruppe mappings, RTI field codes — live in dedicated data regulation satellites with annual validFrom versioning. When Spain adds a new ERTE situational code for 2026, it's a new entry in the data satellite — not a code change in the report script.

This pattern handles the annual schema change problem elegantly: the report script logic remains stable across years, while the lookup data it queries is versioned by tax year. A 2026 payrun automatically resolves 2026 codes; a retro correction for 2025 resolves 2025 codes — same script, different parameters.

5. Authority response as case values

For bidirectional systems (ELStAM, PAS), PE treats authority responses as case values with effective dates. An incoming ELStAM response creates a new case value for the affected fields (Steuerklasse, PKV Jahresbeitrag, Freibetrag) with a start date corresponding to the effective period. The next payrun automatically picks up the new value through PE's standard time-segmented case resolution.

This means no special "ELStAM handler" code exists in the calculation chain. The PAP algorithm simply reads PKV Jahresbeitrag as a case field — it doesn't know or care whether the value was entered manually or arrived via ELStAM. The filing response is normalized into the same data model as all other inputs.

Test Case References

The following integration tests validate the electronic filing scenarios described in this article: