Automatisierte Generierung von Verrechnungspreisdokumentationen

Zur Bekämpfung künstlicher Verminderungen steuerlicher Bemessungsgrundlagen und grenzüberschreitender Verschiebungen von Unternehmensgewinnen („Base Erosion and Profit Shifting“ bzw. „BEPS“) wurde eine dreistufige Berichtsstruktur geschaffen. Diese setzt sich wie folgt zusammen:

Diese und andere Dokumentationen im Steuerbereich verursachen regelmäßig immense Aufwände. So beziffert bspw. die österreichische Bundesregierung allein die für den CbC-Report pro Unternehmen anfallenden Kosten auf eine Höhe von rund 165.000 Euro. Während für das Master File rund 140.000 Euro und für die erstmalige Erstellung eines Local File mit jeweils 155.000 Euro pro Unternehmen fällig werden [43]. Dies sind Kosten, die je nach Komplexität der Firmenstruktur natürlich auch noch deutlich höher ausfallen können.

Auch wenn regelmäßige Updates nicht so aufwändig sind wie die erstmalige Erstellung, fallen dennoch regelmäßig hohe Kosten an und es braucht entsprechendes Personal, um diesen Dokumentationspflichten nachzukommen. Für multinationale Unternehmen ist es daher unerlässlich, in jedem Land genaue und aktuelle Unterlagen zu führen, in dem diese tätig sind. Sei es nun, um die Verrechnungspreisvorschriften einzuhalten oder ihre Verrechnungspreispraktiken im Falle von Steuerprüfungen bzw. bei Anfragen der Steuerbehörden verteidigen zu können [44].

Dabei erweist sich insbesondere das Local File als besonders aufwändig. Weil es regelmäßigen Änderungen unterliegt und sehr ausführlich alle Transaktionen einer Ländergesellschaft beschreibt. Es enthält detaillierte Informationen über bestimmte konzerninterne Transaktionen, die von der lokalen Einheit in einem bestimmten Land durchgeführt werden. Es enthält Daten über die Art der Transaktionen, die zur Preisermittlung verwendete Methode und alle vergleichbaren Daten oder Benchmarking-Studien, welche die gewählte Preisermittlungsmethode unterstützen. Die benötigten Informationen werden dabei aus unterschiedlichsten Ursprungssystemen und -dateien zusammengetragen, um schließlich in Textdokumenten mit gewissen Strukturen und Textbausteinen integriert zu werden.

Um den zuvor genannten manuellen Aufwand zu minimieren, wurde in Zusammenarbeit mit DFKI, WTS und einer großen deutschen Lebensmitteleinzelhandelsgruppe ein prototypisches KI-Assistenzsystem entwickelt, das Unterstützung bei der Erstellung von Local Files bietet. Als Anwendungsfall wurde dabei die Neuerstellung einer Verrechnungspreisdokumentation für eine neu hinzugekommene Transaktion fokussiert.

Ziel des Assistenzsystems ist hierbei, die relevanten Informationen aus relevanten Eingabedateien zu entnehmen, in ein vordefiniertes Dokumentationsformat anzureichern und entsprechend einzubinden. Insbesondere das Verfassen von Textpassagen in einem professionellen Stil soll dabei abgedeckt werden. In diesem Zusammenhang wurde der Prozess zur Informationsabfrage und insbesondere die Schnittstelle zwischen den einzelnen Ländergesellschaften und der zentralen Steuerabteilung der Dachgesellschaft angepasst bzw. standardisiert.

Schritt 1 – Konzept für ein digitales Formblatt: Konkret wurde ein digitales Formblatt konzipiert, in welchem alle relevanten Informationen von Transaktionsverantwortlichen in den einzelnen Landesgesellschaften eingetragen werden. Hierzu zählen u. a. die stichpunktartige Auflistung der erbrachten Leistungen als Transaktionsbeschreibung, die Funktions- und Risikoanalyse sowie die Auswahl der relevanten Benchmarking-Studien.

Schritt 2 – Erstellung des Local Files: Das erstellte Formblatt dient somit als Ausgangspunkt für den entwickelten Prototypen, welcher nach dem Hochladen des Formblatts ein entsprechendes Local File mit den relevanten Informationen erstellt. Diese Erstellung geschieht zum einen regelbasiert, durch Auswahl relevanter Textbausteine und durch das Einsetzen spezifischer Informationen an der korrekten Stelle. Zum anderen werden mit Hilfe des Luminous-Modells von Aleph Alpha entsprechende Textabschnitte zur Beschreibung der zugrundeliegenden Geschäftsbeziehung sowie der Funktions- und Risikoanalyse generiert.

Schritt 3 – Entwicklung von Prompts: Hierfür wurden diverse Prompts entwickelt, mit denen dem Sprachmodell die Aufgabe nähergebracht und gleichzeitig der notwendige Kontext (wie die eigentliche Transaktionsbeschreibung) mitgeliefert wird. Die Interaktion mit dem Sprachmodell stellt gleichzeitig die Kernkomponente des Prototyps dar.

Schritt 4 – Automatisierte Übersetzung der Inhalte: Eine weitere Funktionalität besteht in der automatisierten Übersetzung der Inhalte mit Hilfe des Sprachmodells, um sowohl die deutsche als auch die englische Variante der Verrechnungspreisdokumentation zu generieren. Dadurch entfällt eine manuelle Übersetzung und/oder die Notwendigkeit eines externen Übersetzungsdiensts.

Schritt 5 – Einbettung des Assistenzsystems: Das Assistenzsystem wurde in einer prototypischen Webanwendung eingebettet, die eine nutzerfreundliche Bedienung des Systems ermöglichen soll und damit den Ablauf zur Erstellung einer Transaktionsbeschreibung maßgeblich optimiert. Innerhalb dieser Webanwendung kann der Endanwender die Eingabedateien hochladen, anhand derer die einzelnen Textbausteine generiert werden. Bei Bedarf lassen sich die generierten Inhalte im Anschluss dann anpassen, z. B. durch die manuelle Korrektur der generierten Formulierungen. Abschließend kann das finale Textdokument heruntergeladen und schlussendlich in die Gesamtdokumentation eingebunden werden.

Es hat sich gezeigt, dass das Sprachmodell bereits ohne weiterführendes Fine-Tuning für diesen Anwendungsfall geeignet ist. Ebenfalls konnten auch mit einem Zero-Shot-Learning-Ansatz, d.h. dass dem Modell keine Beispiele für produzierende Texte (bspw. die textuellen Darstellungen einer Transaktionsbeschreibung) bereitgestellt werden, bereits gute Ergebnisse erzielt werden. Allerdings muss ein entsprechend hoher Aufwand betrieben werden, um die Prompts so zu gestalten, dass die gewünschten Ergebnisse in zufriedenstellender Qualität produziert werden (Stichpunkt Prompt Engineering).

Grundsätzlich bieten große Sprachmodelle eine wesentliche Hilfestellung bei Aufgaben wie der Texterstellung. Gleichzeitlich lassen sich aber auch diverse Herausforderungen feststellen, wie etwa die Anfälligkeit zu halluzinierenden textuellen Darstellungen die sich nur in einem begrenzten Umfang (bspw. Anpassung der Parameter zur Textgenerierung) umgehen lassen. Ebenfalls besteht eine Limitation im beschränkten Weltverständnis der Sprachmodelle bezüglich der Steuerdomäne, sofern kein Fine-Tuning mit steuerbezogenen Daten stattfindet.

Die daraus resultierenden Texte, bspw. Darstellungen im Rahmen der Funktions- und Risikoanalyse, warum beteiligte Gesellschaften bei einer gewissen Transaktion Risiken tragen, sind daher oft eher oberflächlich. Aber auch hier lassen sich Maßnahmen ergreifen, welche diese Beobachtungen reduzieren können: Bei den Entwicklungen wurden bspw. den Prompts die Transaktionsbeschreibungen als zusätzlichen Kontext bereitgestellt und seitens des Modells gefordert, sich auf die jeweiligen Inhalte zu beziehen. Damit konnte ermöglicht werden, dass die resultierenden Texte einen stärkeren Bezug zur jeweiligen Domäne aufweisen.

Insgesamt betrachtet lässt sich festhalten, dass der Einsatz von großen Sprachmodellen für Aufgaben wie die Erstellung der Verrechnungspreisdokumentation als ersten Formulierungsentwurf verstanden werden sollten. Diese Entwürfe sollten anschließend manuell korrigiert und verfeinert werden, um die Sprachqualität, aber vor allem auch inhaltliche Aussagekraft zu verbessern. Nichtsdestotrotz ermöglichen sie eine erhebliche Reduzierung des Aufwands zur Erstellung von Verrechnungspreisdokumentationen.