{{item.videoDuration}}
{{item.title}}
{{item.text}}
{{item.videoDuration}}
{{item.title}}
{{item.text}}
Jochen Richner
Director, Tax Technology Leader, PwC Schweiz
Jessica Bruhin
Senior Associate Tax Accounting, PwC Schweiz
Regulation-as-Code hat das Ziel, gesetzliche Regelungen nicht nur in menschlich lesbarer, sondern gleichzeitig in maschinen-verarbeitbarer Sprache auszudrücken. In einer aktuellen Fachpublikation haben wir Vor- und Nachteile aufgezeigt. In diesem Blog möchten wir Ihnen nun einen Einblick in konkrete Anwendungsfälle geben.
Einleitung
Um Regelwerke in ein maschinenlesbares Format übersetzen zu können, hat PwC Schweiz Eiger entwickelt. Dabei handelt es sich um eine domänenspezifische Programmiersprache basierend auf Haskell. Erste Erfahrungen anhand von Pillar 2 zeigen, dass Eiger einerseits eine effiziente Übersetzung von in menschlicher Sprache erfassten Regeln in Code durch Steuerspezialisten erlaubt. Dies insbesondere, weil der Eiger-Code für den Benutzer ähnlich funktioniert wie Excel-Formeln mit einfachen, SQL-ähnlichen-Abfragen. Andererseits ermöglicht Eiger einen plattformunabhängigen Einsatz.
Regeln schreiben
Die Methodik, die Eiger zu Grunde liegt, sieht vor , dass eine Steuerexpertin und ein Software-Ingenieur gemeinsam Regeln implementieren. Der Ingenieur stellt Fragen zu den Regeln, welche die Expertin beantwortet. Der Ingenieur schreibt sie dann auf und die Expertin liest sie.
Aber wie sehen in Eiger erfasste Regeln konkret aus? Regeln beziehen sich auf Fakten. Solche können z.B. aus Zahlen, booleschen Bedingungen, Prozentsätzen oder Ähnlichem aber auch aus domänenspezifischen Klassifikationen wie der Typ einer juristischen Person bestehen. Jedes Faktum kann als Eingabewert manuell oder über eine Schnittstelle in einem Vorsystem bereitgestellt werden. Alternativ existieren Regeln, welche die Herleitung des fraglichen Faktums aus anderen Fakten festlegen. Auf diese Weise bilden Fakten und Regeln einen gerichteten azyklischen Graphen. Fakten werden auf der Grundlage ihres Kontexts gruppiert. Beispielsweise kann ein Fakt im Einkommen einer spezifischen juristischen Person in einem Steuerjahr bestehen. Mit anderen Worten: Die Grundstruktur einer in Eiger implementierten Regelung ist ein Entitäts-Beziehungsmodell, in dem Fakten Eigenschaften sind und Entitäten den Kontext für die Fakten liefern.
Ein Bespiel
Am Beispiel von BEPS 2.0 zeigen wir hier einen Ausschnitt des Entitäts-Beziehungsmodells:
Gewisse Fakten, die Jurisdiktionen und Gesellschaften eindeutig beschreiben, sind zwingend als Eingabe erforderlich (Required). Dazu gehören ein eindeutiger Schlüssel (Zeilen 3, 11), das zugehörige Finanzjahr (Zeile 4), die Zuordnung von Gesellschaften zu Jurisdiktionen (Zeile 12) und die Jurisdiktion (Zeile 5). Die als Optional markierten Fakten können (müssen aber nicht) als Eingabe vorhanden sein (Zeile 6, 13).
Für optionale Fakten kann man Regeln definieren. Hier wird z.B. erklärt, wie sich die «jurisdictional_top_up_tax» einer Jurisdiktion berechnet:
In der ersten Zeile verweist ein Kommentar auf den Artikel 5.2.3 der Regulierung. Zeile 2 ist ein Beispiel einer technisch notwendigen Integration, welche die Expertin überliest. Inhaltlich relevant sind die Zeilen 5 bis 7, in denen der Wert anhand von anderen Fakten derselben Jurisdiktion berechnet wird sowie die Zeilen 9 bis 14, in denen dieser Wert, nach unten durch 0 begrenzt, oder aufgrund anderer Fakten derselben Jurisdiktion durch 0 ersetzt wird und somit dem Faktum dies als Ergebnis zuweist. Das ist ein Beispiel einer Excel-artigen Regel.
Anhand der «domestic_top_up_tax» lässt sich eine SQL-artige Regel illustrieren, welche Fakten von Gesellschaften auf Jurisdiktionenebene aggregiert.
In Zeile 3 stellen wir eine Anfrage an alle Gesellschaften, welche in der Eingabe vorliegen. Die Zeile 5 filtert dann die Gesellschaften heraus, die zur vorliegenden Jurisdiktion gehören. Von diesen wird in Zeile 6 ein einzelnes Faktum genommen und in Zeile 7 werden die Werte all dieser Fakten addiert.
Zuletzt bestehen einfache Hilfsfunktionen, die bestimmte Aspekte der Regulierung beschreiben. Zum Beispiel wird hier dargestellt, wie sich der «Payroll Carve-out» über die Jahre hinweg entwickeln wird.
Dieser Code liest sich, mit anfänglicher Erklärung, wie ein Excel-Tabelle. Die Hilfsfunktion kann nun an geeigneter Stelle einfach von einer Regel benutzt werden.
Regulation-as-Code steckt aktuell noch in den Kinderschuhen. Besonders komplexe, internationale Initiativen wie BEPS 2.0, aber auch mannigfaltige ESG-Regulatorien lassen aber das Potential dieses Ansatzes erkennen. Zentral ist, dass Steuerspezialisten und Steuerspezialistinnen «über den eigenen Tellerrand schauen» und sich auf technische Diskussionen mit Ingenieuren einlassen.
Mehr Informationen findenen Sie in unserem Artikel «Regulation as code» in der Februrar Ausgabe des EXPERT FOCUS.
#social#
{{filterContent.facetedTitle}}
{{contentList.loadingText}}
{{contentList.loadingText}}