The Municipal Tax as a Test Case

A research program needs use cases that do not go easy on it. After the income tax prototype and the Upper Austrian tourism levy, we at the Institute of Business Informatics – Data & Knowledge Engineering at Johannes Kepler University Linz have chosen the municipal tax (Kommunalsteuer) as the next use case: regulated by federal law, collected by every municipality, and self-assessed every month by practically every employer. This article explains what makes a good test case, how the municipal tax maps onto the four layers of a digital twin of legislation, where its determinism ends, and which method we will use to measure the benefit.

What a test case has to deliver

Choosing a use case is part of the method. We work according to Design Science Research: the artifact, the architecture with its four layers, is built, demonstrated on a real case, and evaluated; the results feed into the next iteration. A case that confirms the architecture without stressing it says little. From the prototypes so far and from our ongoing interview study with experts from public administration, legal scholarship, and software engineering, five requirements for a test case have emerged.

• A deterministic core with clear parameters. The calculation must follow unambiguously from complete case data: rates, allowances, thresholds. Only such provisions belong in a twin; discretion stays with people.
• Many implementers. The benefit of a centrally provided model grows with the number of those who currently re-program the law each for themselves.
• Available ground truth. A model can only be tested if there are decided cases for it to compete against: test cases computed by experts or real data from an authority.
• Edges that stress the architecture. A good case contains places where separating the layers is hard: cross-references to other statutes, several authorities involved, facts that extend across jurisdictions.
• Legal depth. Constitutional competence provisions, referenced statutes, ordinances, decrees, and case law must be captured at least far enough that the twin knows what it refers to and what it does not model.

The tourism levy meets the first three requirements well and the last two only to a limited extent: it is state law, administered by a single authority, and refers little to the outside. The municipal tax meets all five.

What the municipal tax is

The municipal tax under the Austrian Municipal Tax Act 1993 (KommStG 1993) is a levy on wages. It applies to the wages that a business pays in a calendar month to the employees of a permanent establishment located in Austria (§ 1). The tax rate is 3 percent of the assessment base; if the monthly assessment base does not exceed 1,460 euros, an allowance of 1,095 euros is deducted (§ 9). The statute is federal law, but the tax accrues to the municipalities; the municipality in which the permanent establishment is located is entitled to collect it (§ 7). The business calculates the tax itself for each calendar month and pays it by the 15th of the following month (§ 11); an annual return follows by the end of March.

This gives the municipal tax a constellation that is new in our research program: one text, more than 2,000 collecting municipalities (Statistics Austria), practically every employer as a taxpayer, and in between the payroll software that actually performs the calculation. Every amendment, whether a change to the allowance or to the catalog of exemptions, currently has to be replicated in every payroll system, in every municipal levy application, and in every audit routine. That is the n-fold implementation effort we described as the fundamental problem in our paper for the International Legal Informatics Symposium IRIS 2025 in February, only with a very large n.

The municipal tax in four layers

In the second article of this series we described the architecture that separates text, meaning, parameters, and calculation. For the municipal tax, the mapping looks like this:

The calculation itself fits in one sentence: the tax is 3 percent of the assessment base, that is, the sum of wages in the calendar month; if the assessment base of the business does not exceed the threshold, the allowance is deducted first. The logic is stable; what changes are the numbers. That is exactly why rate, allowance, and threshold belong in the configuration and not in the code. In the twin, an adjustment of the allowance would be the change of one value with a reference to the amended provision, not a programming order to thousands of places.

The ontology does more work here than for the tourism levy. The KommStG does not define the term employee on its own but by reference to the Income Tax Act: it covers persons in an employment relationship under § 47 (2) EStG 1988, persons with a substantial shareholding in a corporation under § 22 no. 2 EStG 1988, and temporary agency workers (§ 2 KommStG). The assessment base explicitly excludes certain payments, such as retirement and survivor benefits or wages paid to registered persons with disabilities (§ 5 (2)). The twin of the municipal tax therefore has to import concepts defined in another statute, and it has to know which parts of that other statute it needs for this.

Where determinism ends

The municipal tax has the edges that stress the architecture in three places.

Apportionment. If a permanent establishment extends over several municipalities, the business must apportion the assessment base among the municipalities involved; under § 10, local conditions and the burdens that the existence of the establishment imposes on the municipalities must be taken into account. That is not a formula but an assessment. If municipalities and business cannot agree, the tax office decides by apportionment ruling. A twin can determine the assessment base per permanent establishment and name the municipalities involved; the statute does not prescribe the key for splitting a multi-municipality establishment, so the twin does not prescribe it either.

Exemptions. § 8 exempts, among others, corporations, associations of persons, and estates insofar as they serve charitable purposes or purposes of public benefit in the fields of health care and the care of children, young people, families, the sick, persons with disabilities, the blind, and the elderly. Whether a body meets these conditions is governed by §§ 34 et seq. of the Federal Fiscal Code and is an examination of statutes and actual management, not a calculation. The twin can apply an exemption once it is established as an input, but it cannot decide on it.

The concept of employee. Whether a managing shareholder holds a substantial shareholding, whether after six months of temporary agency work the municipality of the hiring business rather than that of the agency is entitled to collect (§ 7), whether a payment falls under an exception in § 5 (2): these questions are usually clear-cut, but they hang on definitions outside the KommStG. This is where it shows whether the ontology holds.

From the interviews conducted so far in our study, selective automation is emerging as the first design principle: a twin models only deterministic, parameterizable sub-decisions and visibly hands everything else back to people. The municipal tax lets us demonstrate this principle: the calculation can be automated; the apportionment of a multi-municipality establishment and the recognition of public-benefit status cannot.

A test case is not the case that works most easily, but the case that shows most clearly where the model has to stop.

Measuring the benefit: the scenario comparison as a method

For the tourism levy under the Upper Austrian Tourism Act 2018 we built a burden model with five implementation architectures and estimated the effort in person-days: initial implementation plus one year of maintenance, for all stakeholders combined.

1. A: manual and decentralized. The status quo. Every business or its software provider reads the law and programs the calculation itself.
2. B: tool-assisted and decentralized. A translation tool speeds up the work, but everyone still produces their own implementation.
3. C: manual and centralized. One body, an authority or a vendor, hand-codes a solution that everyone uses; the derivation often remains proprietary or hard to trace.
4. D: language model instead of code. The legal text and case data are handed to a language model that is supposed to compute the levy.
5. E: tool-assisted and centralized. A twin is produced once, verified by experts, and made available to all as an open interface.

Of roughly 29,000 businesses liable for the levy in Upper Austria, we considered the 231 largest, for which an implementation of their own is realistic. Under the assumptions of the model, Scenario A adds up to roughly 4,040 person-days and Scenario E to roughly 116, a reduction by a factor of about 35. The larger part of this effect comes from centralization, a smaller part from tool support; in maintenance, the annual effort drops from roughly 229 to roughly 34 person-days. We checked correctness against 100 test cases certified by a tax advisory firm: every expert-approved implementation, whether central or decentralized, was error-free; in our experiments, a language model without a model behind it delivers fluctuating results and unreliable references to the law.

For the municipal tax we will apply the same method with different magnitudes. The n is not the number of businesses in one state but the number of payroll systems, municipal levy solutions, and audit routines across the whole country; the susceptibility to change is higher because the assessment base is coupled to income tax law and every change there passes through. We will not quote numbers until the survey is complete and published.

Partners and approach

A test case with real data needs partners who have it. For the municipal tax we are working with the Federal Chancellery, the City of Linz (Office of the Magistrate Director), Johannes Kepler University Linz, and Binary Growth GmbH. As a collecting municipality, the City of Linz knows the actual cases; the twin will be evaluated against this real data and with expert groups from public administration and tax practice. The Federal Chancellery contributes the perspective of the federal level, whose statute is administered here by more than 2,000 municipalities.

The approach follows the workflow from the second article: delimit, slice into functionalities, fix the concepts, extract the parameters, write and test the logic. For the municipal tax this initially means three functionalities: the calculation per permanent establishment, the exemptions as an input, and the apportionment with its deliberate boundary. Every provision receives a permanent anchor in the Federal Legal Information System (RIS), every ontology class a reference to the passage it comes from, every parameter its source. Language models may make proposals; approval is given by people. As envisaged for the tourism levy, the result is to be made available as open source code with an interface, so that payroll software, municipalities, and auditors call the same calculation instead of rebuilding it.

What I expect from this case is less a confirmation than a refinement. The tourism levy has shown that the architecture holds for a state levy. The municipal tax will show how a twin deals with concepts from other statutes, with several authorities, and with provisions that deliberately leave room for assessment. If the four layers withstand that, the pattern applies to a large part of tax law, and the transition to the automated stage that we described in our book "Der selbstfahrende Staat" (Springer Gabler 2024) gains a robust reference case. If not, we will know where to rework.

The next step

The page Digital Twin of Legislation describes the state of the research program; the papers for IRIS 2025 and the ACM Symposium on Computer Science and Law 2025 can be found under Publications. Municipalities, payroll software vendors, and tax advisory firms that would like to contribute cases or test the twin of the municipal tax early against their own calculation are welcome to contact us.