Was die Umsetzung von Gesetzen wirklich kostet

Wenn ein Gesetz beschlossen wird, rechnet die Politik durch, was es Bürgerinnen und Bürger, Unternehmen und Verwaltung kosten wird. Eine Kostenposition fehlt in fast jeder dieser Rechnungen: der Aufwand, das Gesetz in Software zu übersetzen, und zwar nicht einmal, sondern in jeder Behörde, jedem Softwarehaus und jedem Unternehmen, das es anwenden muss. Dieser Beitrag macht sie sichtbar: Er definiert die Verwaltungslast der Gesetzesumsetzung, rechnet sie am Beispiel der oberösterreichischen Tourismusabgabe für fünf Umsetzungsarchitekturen in Personentagen durch und zeigt, warum ein zentral gepflegter Gesetzeszwilling sie um rund das 35-Fache senkt.

Eine Kostenposition, die in keinem Budget steht

Folgenabschätzungen erfassen, was ein Gesetz kostet: Personal in der Verwaltung, Erfüllungsaufwand der Unternehmen, Informationspflichten. Was sie nicht erfassen, ist der Weg vom kundgemachten Text in die Systeme, die ihn anwenden. Dag Wiese Schartum hat diesen Weg 2020 in „From Legal Sources to Programming Code“ als eigenen Transformationsprozess beschrieben: Juristinnen und Juristen legen die Regeln aus und formulieren sie, Informatikerinnen und Informatiker übersetzen sie in Modelle und Programme, das Ergebnis wird getestet, und am Ende prüfen wieder Juristinnen und Juristen, ob die Software dem Gesetz entspricht. Dieser Prozess läuft in jeder Organisation, die das Gesetz umsetzt, von vorne ab.

In unserer Forschung am Institut für Wirtschaftsinformatik – Data & Knowledge Engineering der Johannes Kepler Universität Linz definieren Christoph Schütz und ich die Verwaltungslast der Gesetzesumsetzung deshalb als den kumulierten Aufwand, eine Rechtsregel über alle Beteiligten hinweg zu interpretieren, zu kodieren und zu warten. Bei n getrennten Implementierungen wächst diese Last mit jeder weiteren Organisation und mit jeder Novelle. Drei Kostentreiber stecken darin:

• Redundanz. Dieselbe Formel wird in hunderten IT-Abteilungen parallel gebaut.
• Inkonsistenz. Jede Übersetzung enthält eigene Auslegungen und eigene Fehler. Zwei Betriebe in identischer Lage zahlen unterschiedliche Beträge, weil ihre Software unterschiedlich programmiert wurde. Diese Kosten erscheinen später als Nachforderungen, Einsprüche und Prüfaufwand.
• Wartung. Sätze werden angepasst, Freibeträge valorisiert, Ausnahmen ergänzt. Jede Änderung löst eine Kaskade von Updates in allen Systemen aus, die die alte Regel enthalten; wer zu spät nachzieht, rechnet weiter nach altem Recht.

Im ersten Beitrag dieser Serie, Digitale Gesetzeszwillinge: was ein Gesetz als Modell leisten kann, haben wir diesen Zustand als n-fachen Implementierungsaufwand pro Gesetzesänderung beschrieben. Was dort ein Argument war, soll hier eine Zahl werden.

Der Anwendungsfall: eine Abgabe, 29.000 Rechner

Die Tourismusabgabe nach dem Oö. Tourismusgesetz 2018 eignet sich dafür, weil sie typisch ist: Ein Gesetz legt eine Berechnung fest, und viele Beteiligte müssen sie ausführen. Der Beitrag hängt vom beitragspflichtigen Umsatz ab, vom Prozentsatz für die Kombination aus Beitragsgruppe des Betriebs und Ortsklasse der Gemeinde, von einer Obergrenze der Bemessungsgrundlage und von einem Mindestbeitrag. Das Land hebt die Abgabe zentral ein, aber jeder Betrieb muss seinen Beitrag selbst berechnen und erklären. Rund 29.000 Betriebe sind nach Schätzung des Landes beitragspflichtig (Schnitzhofer 2025, ESWC PhD Symposium). Große Unternehmen bilden die Regel in ihrer Buchhaltungssoftware ab, kleine rechnen in Tabellenkalkulationen oder von Hand.

Für ein Belastungsmodell ist nicht jeder dieser Betriebe gleich relevant: Wer von Hand rechnet, verursacht Aufwand, aber keinen Implementierungsaufwand im engeren Sinn. Wir haben das Modell deshalb auf die 231 Unternehmen mit mehr als 100 Millionen Euro Jahresumsatz konzentriert, bei denen eine Umsetzung in eigenen Systemen plausibel ist und die den Großteil der wirtschaftlichen Aktivität abdecken. Die Annahme ist konservativ: Sie lässt tausende kleinere Implementierungen in Steuerkanzleien und Softwarehäusern außer Acht.

Fünf Architekturen, ein Maßstab: Personentage

Wie ein Gesetz umgesetzt wird, ist eine Architekturentscheidung, auch wenn sie heute niemand bewusst trifft. Wir haben fünf Architekturen definiert und für jede den Aufwand über alle Beteiligten in Personentagen geschätzt: den Erstaufwand für Interpretation und Kodierung und den jährlichen Wartungsaufwand für Novellen und Parameteränderungen. Bei den zentralen Varianten zählen auch die Integration bei jedem Beteiligten und der Aufwand mit, den jede Änderung dort auslöst: Abhängigkeit aktualisieren, Regressionstest, Ausrollen.

• A – manuell und dezentral. Der Status quo. Jeder Beteiligte liest das Gesetz und baut seine eigene Implementierung.
• B – werkzeuggestützt und dezentral. Eine halbautomatische Übersetzungspipeline steht allen zur Verfügung, aber jeder Beteiligte erzeugt damit seinen eigenen Code.
• C – manuell und zentral. Eine Stelle, das Land oder ein Anbieter, programmiert von Hand eine Lösung, die alle nutzen: einen Rechner im Web, eine Schnittstelle oder ein Modul in der Buchhaltungssoftware.
• D – Sprachmodell. Kein Code, sondern ein Sprachmodell, dem Gesetzestext und Falldaten vorgelegt werden.
• E – werkzeuggestützt und zentral. Der digitale Gesetzeszwilling: Die Pipeline überführt das Gesetz einmal zentral in die vier Schichten Text, Ontologie, Konfiguration und Logik aus dem Beitrag Von der Prosa zum Modell; das Ergebnis wird als quelloffene Bibliothek und Schnittstelle veröffentlicht, alle Beteiligten binden es ein.

Die Schätzwerte je Indikator stammen aus Einschätzungen von Fachleuten aus dem IT-Management des Landes Oberösterreich, einem Legal-Tech-Unternehmen, einem Softwareunternehmen und einer auf Requirements Engineering und Aufwandsschätzung im öffentlichen Sektor spezialisierten Beratung. Die Architekturen A, B, C und E hat unser Team zudem gebaut und den Aufwand gemessen, um die Schätzungen daran zu prüfen.

Personentage über alle Beteiligten unter den beschriebenen Modellannahmen; Belastungsstudie am Institut für Wirtschaftsinformatik – Data & Knowledge Engineering der JKU Linz, Veröffentlichung in Vorbereitung.

Architektur D fehlt in der Rechnung nicht aus Bequemlichkeit. Ein Sprachmodell verursacht praktisch keinen Kodieraufwand, erfüllt aber die Mindestanforderungen an Korrektheit, Nachvollziehbarkeit und Reproduzierbarkeit nicht, die wir im Beitrag Ontologie oder Sprachmodell beschrieben haben: In unseren Versuchen mit der Tourismusabgabe fielen die Antworten bei identischer Eingabe zwischen den Durchläufen unterschiedlich aus, und die Verweise auf Bestimmungen waren unvollständig oder erfunden. Für eine Architektur, die das Ergebnis nicht verlässlich liefert, lässt sich Aufwand nicht sinnvoll beziffern.

Der Zwilling in Architektur E wurde dagegen gegen 100 repräsentative Testfälle geprüft, deren Beträge und rechtliche Begründung eine befugte oberösterreichische Steuerberatungskanzlei unabhängig bestätigt hat, und lieferte in allen Fällen das Ergebnis der Expertenrechnung. Dasselbe gilt für jede Architektur, in der Fachleute den Code schreiben oder validieren. Der Unterschied zwischen A, B, C und E liegt also nicht in der Korrektheit, sondern im Aufwand, mit dem sie erreicht wird.

Woher die 35 kommen

Das Verhältnis zwischen A und E beträgt im ersten Jahr 4.040 zu 116 Personentage, ein Faktor von 34,7. Was im Ökosystem rund 20 Personenjahre kumulierter Arbeit bindet, ließe sich zentral in weniger als sechs Monaten erledigen. Interessanter als die Zahl selbst ist ihre Zerlegung, weil sie zeigt, welcher Hebel wie viel bewegt.

Der größte Hebel ist die Zentralisierung. Schon der Schritt von A nach C, also eine von Hand programmierte Lösung für alle statt 231 eigener, senkt den Aufwand um rund das 31-Fache. Der Grund ist banal und wird trotzdem übersehen: Die Kosten der Umsetzung sind mit der Zahl der Umsetzenden multipliziert.

Der zweite Hebel ist die Modellierung. Der Schritt von C nach E bringt noch einmal rund elf Prozent, weil das zentrale Team nicht von Hand kodiert, sondern mit einer Pipeline arbeitet, in der Sprachmodelle Ontologie, Parameter, Logik und Tests vorschlagen und Fachleute sie bestätigen oder korrigieren. Wichtiger als der Prozentsatz ist, dass die Modellierung die Wartung verändert. In der Vier-Schichten-Architektur ist eine Satzänderung eine Änderung in der Konfigurationsschicht und kein Eingriff in den Code; die Ontologie hält das Vokabular stabil, sodass angeschlossene Systeme neue Versionen ohne Umbau ihrer Integration übernehmen; und die mitgelieferten Tests ersetzen die Prüfung, die sonst jeder Beteiligte wiederholen müsste.

Der dritte Befund betrifft die Automatisierung ohne Zentralisierung. Architektur B zeigt, dass eine Pipeline, die jeder für sich einsetzt, den Aufwand pro Beteiligtem etwa um das Sechsfache senkt, aber 231 getrennte Codebasen zurücklässt, die bei jeder Novelle einzeln nachgezogen werden müssen.

Die Kosten der Umsetzung sind mit der Zahl der Umsetzenden multipliziert. Werkzeuge senken den Preis jeder Wiederholung; nur eine gemeinsame Implementierung senkt die Zahl der Wiederholungen.

Die Wartung verdient eigene Aufmerksamkeit, weil sie über die Lebensdauer eines Gesetzes die Erstkodierung bei weitem übersteigt. In Architektur A kostet die laufende Anpassung an Novellen und Indexänderungen über alle Beteiligten hinweg 229 Personentage pro Jahr, in Architektur E 34. Vor allem aber ändert sich die Verlässlichkeit: Ein Team aktualisiert den Zwilling, veröffentlicht die neue Version, und alle angeschlossenen Systeme rechnen ab dem Stichtag nach dem neuen Recht. Für den Gesetzgeber heißt das auch, dass er Novellen beschließen kann, ohne der Wirtschaft jedes Mal hohe Anpassungskosten aufzuerlegen.

Zwei Einschränkungen gehören zu dieser Rechnung. Die Zahlen sind Schätzungen aus einem bewusst schlanken Indikatorensatz; ihr Wert liegt im Vergleich der Architekturen, nicht in der Nachkommastelle, und die Abstände blieben bei plausiblen Variationen der Annahmen stabil. Und der Faktor 35 gilt für ein einzelnes Landesgesetz mit einer klar formelhaften Berechnung; bei Bestimmungen mit mehr Ermessen ist der automatisierbare Anteil kleiner, und nur dieser Anteil lässt sich zentral bereitstellen.

Was das für den Staat und für Unternehmen bedeutet

Die Rechnung verschiebt eine politische Frage. Bisher gilt die Umsetzung eines Gesetzes in Software als Sache derer, die es anwenden müssen; die Kosten sind über tausende Organisationen verteilt und deshalb unsichtbar. Sobald man sie summiert, zeigt sich, dass ein zentral gepflegter Zwilling für rund 116 Personentage, Integration bei den Beteiligten eingerechnet, an die Stelle von rund 4.000 Personentagen tritt, die sonst über die Volkswirtschaft verteilt anfallen; und die Ersparnis setzt sich Jahr für Jahr fort, weil die Wartung mitzentralisiert wird. Das ist die Logik eines Straßennetzes: Es wird einmal gebaut, weil das billiger ist, als wenn jeder seinen eigenen Weg pflastert.

Daraus folgen drei Konsequenzen:

• Die Verwaltungslast der Umsetzung messen. Was nicht gezählt wird, wird nicht gesteuert. Folgenabschätzungen sollten ausweisen, wie viele Stellen eine Bestimmung in Software abbilden müssen und was jede Novelle dort auslöst, so wie sie heute Erfüllungskosten ausweisen.
• Ausführbare Fassungen zentral bereitstellen. Für formelhafte Bestimmungen wie Abgaben, Gebühren und Beiträge ist ein amtlicher, quelloffener und mit dem Text synchron gehaltener Zwilling die günstigste Umsetzungsarchitektur. Über die REST-Schnittstelle und das Model Context Protocol, die wir Anfang September beim Developers Workshop der SEMANTiCS 2025 beschrieben haben, können Buchhaltungssoftware, Fachverfahren und Assistenzsysteme dieselbe geprüfte Berechnung nutzen. Der Zwilling für die Tourismusabgabe ist unter lawdigitaltwin.com öffentlich zugänglich.
• Die Vorlaufkosten ehrlich rechnen. Der Zwilling ist nicht kostenlos. Er braucht Fachleute, die die Vorschläge der Pipeline prüfen, eine Stelle, die Versionen verantwortet, und ein Testset, das die Korrektheit belegt. Diese Kosten sind in den 116 Personentagen enthalten, und sie entstehen einmal statt 231-mal.

Für Unternehmen dreht sich der Blick um. Wer Lohn-, Buchhaltungs- oder Fachsoftware betreibt, trägt einen Teil dieser Last, ohne sie je als Position gesehen zu haben, und zahlt sie bei jeder Novelle erneut. Die Frage an die eigene IT lautet künftig, welche Bestimmungen überhaupt selbst kodiert werden müssen und welche sich als geprüfter Dienst beziehen ließen. Für die Kommunalsteuer, den nächsten Anwendungsfall unserer Forschung, steht eine solche Rechnung noch aus; die Dimension ist aber absehbar: Eine bundesgesetzlich geregelte Lohnabgabe, die praktisch jedes Unternehmen mit Beschäftigten in Österreich betrifft, vervielfacht die Zahl der Umsetzenden um Größenordnungen.

Der nächste Schritt

Die Vision hinter dieser Rechnung beschreibt die Seite Digitaler Gesetzeszwilling; die bisher erschienenen Veröffentlichungen finden Sie unter Publikationen. Wer in einer Behörde oder einem Unternehmen eine Bestimmung kennt, die in vielen Systemen parallel gepflegt wird, ist eingeladen, mit uns die Verwaltungslast für diesen Fall durchzurechnen.