Multi-State / Multi-Canton: One Employee, Multiple Tax Jurisdictions

The Problem

Payroll is straightforward when one employee works in one place and lives in the same jurisdiction. The complexity explodes when any of these conditions break: an employee lives in New Jersey but commutes to New York. A Swiss worker resides in Zürich but works in Zug. A UK employee is paid under Scottish tax rates while their employer is in England. A Portuguese employee on the Azores gets a 20.2% reduction on mainland IRS rates.

The fundamental question — which jurisdiction has the right to tax which portion of this employee's income? — has no universal answer. Each country (and often each sub-national entity) has its own allocation rules:

• Domicile-based: You pay taxes where you live, regardless of where you work (Switzerland's default model for resident employees)
• Work-location-based: You pay taxes where you physically perform work (US multi-state withholding for non-resident employees)
• Employer-location-based: The employer's registered jurisdiction determines the withholding regime (partially true in Belgium)
• Hybrid: A combination of all three, with reciprocity agreements, commuter credits, and local tax overlays stacked on top (the US model in its full complexity)

These rules interact with each other. A US employee living in New Jersey and working in New York is subject to NY non-resident withholding, gets a credit on their NJ return for taxes paid to NY, and may owe NJ the difference — or get a refund if NJ's rate is lower. This is one employee, two states, one pay period. Scale it to an employer with employees across 15 states, and you have 15 different withholding regimes running simultaneously.

And then there's currency. A European employer with employees in Switzerland and Germany must consolidate EUR and CHF results. The exchange rate used matters — is it the rate on the payroll date, the period-end rate, or the monthly average? The choice affects every aggregated number in the consolidation report.

How It Works

Let's examine the specific multi-jurisdiction models in each country. The structural differences are profound — from the US's employer-driven withholding allocation to Switzerland's 26-canton tariff matrix.

United States: Multi-state withholding + local taxes

US multi-state payroll is arguably the most complex sub-national tax allocation system in the world. The core rules:

1. Work state withholding: The state where work is physically performed generally has the first right to withhold income tax.
2. Resident state credit: The employee's resident state allows a credit for taxes paid to work states — but only up to the resident state's own rate.
3. Reciprocity agreements: Some state pairs have agreements that exempt non-residents from work-state withholding entirely. Example: NJ residents working in PA are exempt from PA withholding and only owe NJ taxes.
4. Local taxes: Some cities and municipalities levy their own income taxes independent of state taxes. Philadelphia's wage tax (3.75% for residents, 3.44% for non-residents), New York City income tax, and Ohio municipal taxes all stack on top of state taxes.

Consider a concrete scenario: an employee lives in Connecticut, works three days a week in New York, and two days a week from their home office in CT.

The payroll system must calculate NY withholding on 60% of wages, CT withholding on 100% of wages, and then determine the net CT liability after the NY credit. If NY's effective rate on the allocated portion exceeds CT's rate, the employee may owe nothing additional to CT for the NY-sourced income — but still owes CT tax on the remaining 40%.

Now add a three-state reciprocity scenario. An employee living in West Virginia, working in Maryland, with occasional travel to Virginia: MD-WV have a reciprocity agreement (no MD withholding required), but VA-WV do not. The system must withhold VA taxes for Virginia workdays, skip MD withholding entirely due to reciprocity, and calculate WV resident tax with a credit only for VA taxes paid — not for any MD taxes, because none were owed.

Switzerland: 26 cantons × tariff codes × monthly tables

Swiss payroll taxation operates on a cantonal basis. Each of the 26 cantons sets its own income tax rates, applies its own tariff codes (A through H, based on marital status, number of earners, and dependents), and publishes its own monthly withholding tables (Quellensteuer tariff tables).

The sheer data volume is staggering: 26 cantons × 8+ tariff codes × 12 months × hundreds of income brackets = tens of thousands of individual tax rate entries per year. Each canton's tables are independently published, typically in late December for the following year, and must be loaded into the payroll system before January processing begins.

The allocation rule is relatively clean for domestic cases: the employee's canton of residence determines the withholding tariff (§ 107 DBG for Quellensteuer). An employee living in Zürich and working in Zug pays Zürich cantonal rates — not Zug's. But cross-cantonal commuters interact with the Wochenaufenthalt (weekly residence) rules, and international cross-border commuters (Grenzgänger) from France, Germany, Italy, or Austria are subject to bilateral agreements that override the standard domicile rule.

United Kingdom: Devolved tax rates + NI categories

The UK's four nations create a multi-rate income tax system within a single PAYE framework. Since 2017 (Scotland) and 2019 (Wales), tax codes encode the applicable jurisdiction:

National Insurance (NI) remains UK-wide — it does not vary by devolved nation. But NI has its own complexity: 13 NI category letters (A through M, plus special cases) that determine rates based on employee age, pension status, and veteran status. An employee might have tax code S1257L (Scottish income tax) with NI category A (standard) — two independent jurisdictional parameters applied to the same payslip.

The employer's location is irrelevant: an English employer with a Scottish employee applies Scottish rates. The tax code communicated by HMRC determines the jurisdiction, not the employer's registered address.

Germany: Kirchensteuer by Bundesland

Germany's multi-jurisdiction issue is narrower but still important: Kirchensteuer (church tax) varies by federal state. Bavaria and Baden-Württemberg apply 8%, while all other states apply 9% (§ 51a EStG in conjunction with state church tax laws). The rate is determined by the employee's tax office registration, which is tied to their residence.

This creates a straightforward but easily overlooked allocation: an employee who moves from Bavaria (8%) to North Rhine-Westphalia (9%) mid-year must have their church tax rate updated. The ELStAM system (electronic wage tax deduction features) communicates this automatically, but the payroll system must apply the correct rate per period — not retroactively recalculate prior months at the new rate.

Belgium: Regional opcentiemen

Belgium's three regions — Flanders, Wallonia, and Brussels-Capital — levy opcentiemen (additional centimes) on top of the federal Bedrijfsvoorheffing (BV). The rate of opcentiemen varies by municipality within each region, creating a three-tier tax structure: federal BV rate → regional surcharge → municipal surcharge.

The complexity is moderate for payroll purposes because the Bedrijfsvoorheffing tables published by the FOD Financiën already incorporate the regional and municipal components. However, the correct table must be selected based on the employee's commune of residence — and Belgium has 581 communes, each potentially with a different opcentiemen rate.

Portugal: Autonomous regions

Portugal's Azores and Madeira autonomous regions enjoy reduced IRS (income tax) rates relative to mainland Portugal. The Azores applies a 20.2% reduction to mainland rates (Decreto Legislativo Regional), while Madeira applies a 30% reduction. This means the withholding tables for an employee on the Azores produce different results from the same salary on the mainland — even though the federal IRS structure is identical.

The consolidation dimension

For employers operating across these models, consolidation — producing unified reports that aggregate results across jurisdictions — is the final and often most challenging layer. The consolidation problem has four distinct dimensions:

Each dimension requires different consolidation logic. Country-level consolidation is a simple aggregation of wage types within a single regulatory tenant. Regional consolidation (e.g., DACH region: Germany, Austria, Switzerland) requires querying across separate tenants with different currencies and different wage type structures. Global consolidation adds the full currency conversion problem and must normalize fundamentally different tax concepts (progressive income tax, flat withholding, cantonal tariffs) into comparable categories.

Where It Gets Tricky

US multi-state withholding allocation

The core allocation question — how many workdays in each state? — sounds simple but creates cascading complexity. Some states use a "convenience of the employer" doctrine (New York), where remote work from home doesn't count as work in the home state unless it's for the employer's convenience, not the employee's. This means a NY-based employer with an employee working from home in NJ three days a week may still owe NY withholding on 100% of wages if the remote work is for the employee's convenience.

Reciprocity agreements add another layer. There are approximately 30 reciprocity agreements between US states, each with specific conditions. Some are symmetric (PA-NJ: neither state withholds from the other's residents); some are asymmetric (MD-DC: DC residents working in MD are exempt from MD withholding, but MD residents working in DC still owe DC taxes). The payroll system must know every applicable reciprocity agreement and apply it correctly based on the specific work-state/resident-state pair for each employee.

Local taxes compound the problem further. An employee working in Philadelphia owes the Philadelphia wage tax regardless of where they live. An employee living in Philadelphia but working in the suburbs owes the lower non-resident rate (or nothing, depending on the suburb's reciprocity with Philadelphia). These local taxes operate independently of state taxes and have their own registration, withholding, and reporting requirements.

Swiss cantonal data volume

The practical challenge in Switzerland isn't conceptual — the domicile rule is clear — it's data management. Twenty-six cantons publishing independent tariff tables annually means the regulation must store and correctly resolve tens of thousands of bracket entries. A lookup for "Zürich, tariff code B, monthly income CHF 8,450" must find the correct row in the Zürich B-tariff table, which may have 200+ brackets.

Cantonal table formats are not fully standardized. Some cantons publish rounded annual rates; others publish exact monthly amounts. Some publish effective rates; others publish cumulative tax amounts per bracket. The payroll system must normalize these different formats into a consistent calculation model — or maintain separate calculation engines per canton.

Reciprocity agreement edge cases

Reciprocity agreements don't just determine whether to withhold — they affect which form the employee files, which registration the employer needs, and which state receives the quarterly report. An employer with employees in five states, three of which have reciprocity agreements with each other, must maintain registrations in all five states but may only actively withhold in three. The two exempted states still require annual reconciliation filings even though no withholding occurred.

The edge cases multiply when an employee changes their resident state mid-year. If an NJ resident working in PA (reciprocity: no PA withholding) moves to NY mid-year (no reciprocity with PA), the system must start PA withholding from the move date. The YTD allocations for the year are now split: Q1–Q2 under NJ-PA reciprocity, Q3–Q4 under NY-PA non-reciprocity. Two different withholding regimes for the same employee at the same employer in the same calendar year.

Local tax stacking

In states like Ohio and Pennsylvania, local income taxes create a third layer below federal and state. Ohio has approximately 600 municipalities that levy local income taxes, each with its own rate and credit structure. An employee working in Columbus (2.5% rate) but living in a suburb (1.5% rate) pays 2.5% to Columbus and owes the difference (1.0%) to their home municipality — unless the home municipality offers a full credit, in which case they owe nothing additional.

Pennsylvania's Earned Income Tax (EIT) adds a similar layer, with rates varying by school district and municipality. The maximum combined EIT rate is capped at a percentage set by the Tax Reform Code, but the actual rate depends on the specific combination of municipality and school district where the employee resides. The payroll system must know both the work-location rate and the resident-location rate, apply credits correctly, and remit to the correct collector.

How PE Solves It

Payroll Engine's multi-jurisdiction architecture rests on four pillars: jurisdiction-aware case fields, cantonal and state-level lookup tables, a uniform consolidation interface, and cross-tenant query capability.

1. Multi-state case fields

For US payroll, the employee record carries jurisdiction-specific case fields: WorkState, ResidentState, FilingStatus per state, and optionally WorkState2 / WorkState3 for employees working in multiple states within a single period. These fields are Period time-typed, meaning they can change mid-period: an employee who moves from NJ to NY on March 15 has two active ResidentState values in March — NJ for the first half, NY for the second.

The wage type logic reads the current WorkState and ResidentState values, determines whether a reciprocity agreement applies (via a dedicated lookup table), and calculates the appropriate withholding. For multi-state employees, the system runs the state withholding calculation once per active work state, allocating wages by workday proportion.

2. Cantonal and state-level lookup tables

Switzerland's cantonal tariff tables and US state tax brackets are stored as regulation lookups with composite keys. A Swiss lookup might be keyed on (Canton, TariffCode, Month) and return the applicable withholding amount for a given income bracket. The lookup is a threshold lookup — it finds the bracket that matches the income level and returns the corresponding tax amount or rate.

This structure scales to any number of cantons or states without changing the calculation logic. Adding a new canton (or updating a canton's tariff for a new year) means adding or updating lookup entries — not modifying code. The same applies to US state tax tables: each state's bracket structure is a separate lookup, selected at runtime based on the employee's WorkState value.

3. Consolidation wage types 7000–7030

Payroll Engine defines a uniform consolidation interface through wage types 7000 through 7030, all tagged with the Consolidation cluster. These wage types represent standardized payroll aggregates — gross pay, net pay, total employer cost, total employee tax, total social security — in a structure that is identical across all country regulations.

When a German payroll calculates WT 7010 (consolidated gross), it maps the German gross wage types to the standard structure. When a Swiss payroll calculates WT 7010, it maps the Swiss equivalents. The consolidation consumer doesn't need to know whether the source is German or Swiss — it queries WT 7010 and gets a comparable number.

This uniform interface enables three consolidation patterns:

• Country-level: A single-tenant query that aggregates WT 7000–7030 across all employees within one country regulation. No currency conversion needed.
• Regional: A multi-tenant query (e.g., DACH region) that uses ExecuteConsolidatedQuery to aggregate WT 7000–7030 across the German, Austrian, and Swiss tenants. Currency conversion (CHF → EUR) is applied using the period exchange rate from the consolidation configuration.
• Global: A full multi-tenant, multi-currency query across all country tenants, producing a single consolidated view in the reporting currency.

4. ExecuteConsolidatedQuery for cross-tenant reporting

The ExecuteConsolidatedQuery API is the technical backbone of multi-tenant consolidation. It accepts a list of tenant identifiers, a wage type filter (typically the 7000–7030 range), a period range, and an optional currency conversion configuration. The API queries each tenant independently, converts results to the target currency, and returns a unified result set.

This approach avoids the need for a shared database or a master tenant that contains all data. Each country regulation operates in its own tenant with its own data isolation. The consolidation layer sits above the tenant boundary and reaches across it only at query time, using read-only access. This preserves data sovereignty (Swiss employee data stays in the Swiss tenant) while enabling cross-country reporting.

For US multi-state consolidation, the same mechanism works within a single tenant. The US regulation stores per-state results as separate wage types or with state-tagged collectors. A consolidation query filtered by state produces per-state aggregates without needing a separate tenant per state.

5. Period exchange rates for multi-currency

Multi-currency consolidation uses period-specific exchange rates stored in the consolidation configuration. The system supports three rate modes: period-start, period-end, and period-average. The rate mode is set per consolidation report, not per query — ensuring consistency within a single report even when the report spans multiple periods.

For a DACH regional report covering Q1 2026, the system queries the German tenant (EUR), the Austrian tenant (EUR), and the Swiss tenant (CHF). Swiss results are converted to EUR using the configured rate for each month (January, February, March). If the period-average mode is selected, the average CHF/EUR rate for each month is applied to that month's results before aggregation.

Test Case References

The following integration tests validate the multi-jurisdiction scenarios described in this article: