What Implementing Legislation Really Costs

When a law is passed, policymakers calculate what it will cost citizens, businesses, and the administration. One cost item is missing from almost every one of these calculations: the effort of translating the law into software, and not once, but in every public authority, every software vendor, and every company that has to apply it. This article makes it visible: it defines the administrative burden of law implementation, works it out in person-days for five implementation architectures using the Upper Austrian tourism levy as the example, and shows why a centrally maintained twin of legislation reduces it roughly 35-fold.

A cost item that appears in no budget

Impact assessments record what a law costs: staff in the administration, compliance costs for businesses, information obligations. What they do not record is the path from the promulgated text into the systems that apply it. Dag Wiese Schartum described this path in 2020 in "From Legal Sources to Programming Code" as a transformation process in its own right: lawyers interpret the rules and put them into words, computer professionals translate them into models and programs, the result is tested, and at the end lawyers check again whether the software matches the law. This process runs from the beginning in every organization that implements the law.

In our research at the Institute of Business Informatics – Data & Knowledge Engineering at Johannes Kepler University Linz, Christoph Schütz and I therefore define the administrative burden of law implementation as the cumulative effort required to interpret, code, and maintain a legal rule across all stakeholders. With n separate implementations, this burden grows with every additional organization and with every amendment. Three cost drivers are contained in it:

• Redundancy. The same formula is built in parallel in hundreds of IT departments.
• Inconsistency. Every translation contains its own interpretations and its own errors. Two businesses in identical situations pay different amounts because their software was programmed differently. These costs appear later as additional assessments, appeals, and audit effort.
• Maintenance. Rates are adjusted, allowances are indexed, exemptions are added. Every change triggers a cascade of updates in all systems that contain the old rule; whoever updates late keeps calculating under the old law.

In the first article of this series, Digital Twins of Legislation: What a Law Can Do as a Model, we described this state as an n-fold implementation effort per legislative change. What was an argument there is to become a number here.

The use case: one levy, 29,000 calculators

The tourism levy under the Upper Austrian Tourism Act 2018 is suitable for this because it is typical: a law defines a calculation, and many stakeholders have to carry it out. The contribution depends on the assessable revenue, on the percentage rate for the combination of the business's contribution group and the municipality's location class, on a cap on the assessment base, and on a minimum contribution. The province collects the levy centrally, but every business has to calculate and declare its own contribution. According to the province's estimate, roughly 29,000 businesses are liable for the levy (Schnitzhofer 2025, ESWC PhD Symposium). Large companies model the rule in their accounting software; small ones calculate in spreadsheets or by hand.

For a burden model, not all of these businesses are equally relevant: anyone calculating by hand incurs effort, but not implementation effort in the narrower sense. We therefore focused the model on the 231 companies with annual revenue above 100 million euros, for which an implementation in their own systems is plausible and which cover the bulk of economic activity. The assumption is conservative: it disregards thousands of smaller implementations in tax advisory firms and software vendors.

Five architectures, one yardstick: person-days

How a law is implemented is an architectural decision, even if nobody consciously makes it today. We defined five architectures and, for each, estimated the effort across all stakeholders in person-days: the initial effort for interpretation and coding, and the annual maintenance effort for amendments and parameter changes. For the centralized variants, the integration at each stakeholder and the effort that every change triggers there are counted as well: updating the dependency, regression testing, redeploying.

• A – manual and decentralized. The status quo. Every stakeholder reads the law and builds their own implementation.
• B – tool-assisted and decentralized. A semi-automated translation pipeline is available to everyone, but every stakeholder uses it to generate their own code.
• C – manual and centralized. One body, the province or a vendor, hand-codes a solution that everyone uses: a calculator on the web, an interface, or a module in accounting software.
• D – language model. No code, but a language model that is given the statutory text and the case data.
• E – tool-assisted and centralized. The digital twin of legislation: the pipeline transforms the law once, centrally, into the four layers of text, ontology, configuration, and logic from the article From Prose to Model; the result is published as an open-source library and interface, and all stakeholders integrate it.

The estimates for each indicator come from assessments by experts from the IT management of the Province of Upper Austria, a legal-tech company, a software company, and a consultancy specializing in requirements engineering and public-sector effort estimation. Our team also built architectures A, B, C, and E and measured the effort in order to check the estimates against it.

Person-days across all stakeholders under the model assumptions described above; burden study at the Institute of Business Informatics – Data & Knowledge Engineering at JKU Linz, publication in preparation.

Architecture D is not missing from the calculation out of convenience. A language model incurs practically no coding effort, but it does not meet the minimum requirements for correctness, traceability, and reproducibility that we described in the article Ontology or Language Model: in our experiments with the tourism levy, the answers to identical input differed between runs, and the references to provisions were incomplete or invented. For an architecture that does not reliably deliver the result, effort cannot be meaningfully quantified.

The twin in architecture E, by contrast, was checked against 100 representative test cases whose amounts and legal justification a licensed Upper Austrian tax advisory firm had independently confirmed, and it returned the expert result in every case. The same holds for every architecture in which experts write or validate the code. The difference between A, B, C, and E therefore lies not in correctness but in the effort with which it is achieved.

Where the 35 comes from

The ratio between A and E in the first year is 4,040 to 116 person-days, a factor of 34.7. What ties up roughly 20 person-years of cumulative work across the ecosystem could be done centrally in less than six months. More interesting than the number itself is its decomposition, because it shows which lever moves how much.

The biggest lever is centralization. The step from A to C alone, that is, one hand-coded solution for everyone instead of 231 separate ones, reduces the effort roughly 31-fold. The reason is banal and is nevertheless overlooked: the costs of implementation are multiplied by the number of implementers.

The second lever is modeling. The step from C to E brings a further eleven percent or so, because the central team does not code by hand but works with a pipeline in which language models propose the ontology, parameters, logic, and tests and experts confirm or correct them. More important than the percentage is that modeling changes maintenance. In the four-layer architecture, a rate change is a change in the configuration layer and not an intervention in the code; the ontology keeps the vocabulary stable, so that connected systems can adopt new versions without rebuilding their integration; and the tests that ship with it replace the checking that every stakeholder would otherwise have to repeat.

The third finding concerns automation without centralization. Architecture B shows that a pipeline everyone uses on their own reduces the effort per stakeholder by roughly a factor of six but leaves behind 231 separate code bases that have to be updated individually with every amendment.

The costs of implementation are multiplied by the number of implementers. Tools lower the price of each repetition; only a shared implementation lowers the number of repetitions.

Maintenance deserves attention of its own, because over the lifetime of a law it far exceeds the initial coding. In architecture A, keeping up with amendments and index adjustments costs 229 person-days per year across all stakeholders; in architecture E, 34. Above all, however, reliability changes: one team updates the twin, publishes the new version, and all connected systems calculate under the new law from the effective date. For the legislature this also means that it can pass amendments without imposing heavy adjustment costs on the economy every time.

Two caveats belong to this calculation. The figures are estimates from a deliberately lean set of indicators; their value lies in the comparison of the architectures, not in the decimal place, and the gaps remained stable under plausible variations of the assumptions. And the factor of 35 applies to a single provincial law with a clearly formulaic calculation; for provisions involving more discretion, the automatable share is smaller, and only that share can be provided centrally.

What this means for the state and for companies

The calculation shifts a political question. Until now, implementing a law in software has been regarded as the business of those who have to apply it; the costs are spread across thousands of organizations and are therefore invisible. As soon as they are added up, it becomes clear that a centrally maintained twin, at around 116 person-days including integration at the stakeholders, takes the place of around 4,000 person-days that would otherwise be spread across the economy; and the savings continue year after year, because maintenance is centralized along with it. That is the logic of a road network: it is built once because that is cheaper than everyone paving their own path.

Three consequences follow:

• Measure the administrative burden of implementation. What is not counted is not managed. Impact assessments should state how many bodies have to model a provision in software and what every amendment triggers there, just as they state compliance costs today.
• Provide executable versions centrally. For formulaic provisions such as levies, fees, and contributions, an official, open-source twin kept in sync with the text is the cheapest implementation architecture. Through the REST interface and the Model Context Protocol, which we described in early September at the Developers Workshop of SEMANTiCS 2025, accounting software, specialized government applications, and assistant systems can use the same verified calculation. The twin for the tourism levy is publicly accessible at lawdigitaltwin.com.
• Account for the upfront costs honestly. The twin is not free. It needs experts who check the pipeline's proposals, a body that is responsible for versions, and a test set that proves correctness. These costs are included in the 116 person-days, and they arise once instead of 231 times.

For companies, the perspective is reversed. Anyone operating payroll, accounting, or specialized software carries part of this burden without ever having seen it as a line item, and pays it again with every amendment. The question for one's own IT going forward is which provisions have to be coded in-house at all and which could be obtained as a verified service. For the municipal tax, the next use case of our research, such a calculation is still outstanding; the dimension, however, is foreseeable: a payroll levy regulated by federal law that affects practically every company with employees in Austria multiplies the number of implementers by orders of magnitude.

The next step

The vision behind this calculation is described on the page Digital Twin of Legislation; the papers published so far can be found under Publications. Anyone in a public authority or a company who knows a provision that is maintained in parallel in many systems is invited to work through the administrative burden for that case with us.