Die Verrechnungspreisdokumentation hat den Ruf einer Schreibübung: Einmal im Jahr stellt jemand ein Master File und einen Stapel Local Files zusammen, aktualisiert das Benchmarking und legt das Paket ab für den Tag, an dem eine Steuerbehörde danach fragt. Der Ruf ist veraltet. Die Dokumente folgen weiterhin der OECD-Action-13-Architektur aus Master File, Local File und CbCR, aber die Arbeit dahinter ist zu einem Datenpipeline-Problem geworden, und der Druck auf diese Pipeline steigt aus zwei Richtungen zugleich.
Die erste Richtung ist regulatorische Konvergenz auf dieselben zugrunde liegenden Daten. Pillar Two verpflichtet Konzerne, Verrechnungspreisdaten, CbCR-artige Daten und die Inputs des GloBE Information Return in Einklang zu bringen; eine Compliance-Checkliste von 2026 formuliert es schlicht: Pillar-Two- und CbCR-Daten früh abgleichen und die Transitional Safe Harbours prüfen, bevor man annimmt, dass sie greifen. Amount B fügt für Basisvertriebe ein Scoping-Overlay hinzu, das jährlich beobachtet werden muss, während sich die OECD-Leitlinien bewegen. Ein Local File, das dem CbCR widerspricht, oder ein CbCR, das dem GloBE Return widerspricht, ist keine Peinlichkeit mehr, die Jahre später entdeckt wird; es ist ein Cross-Check, den eine Steuerbehörde beim Eingang laufen lassen kann.
Die zweite Richtung ist die Einreichungsmechanik. Das Modell der Dokumentation auf Anforderung erodiert Jurisdiktion für Jurisdiktion. Rumäniens ANAF-Verordnung Nr. 828/2026 hat die Dokumentationsregeln für Transaktionen ab 2026 überarbeitet und verlangt von großen Steuerpflichtigen die jährliche elektronische Einreichung über SPV, statt die Dokumentation für einen Prüfer bereitzuhalten, der vielleicht nie kommt. Jährliche elektronische Einreichung verwandelt die Verrechnungspreisdokumentation von einer Eventualität in eine Einreichung, mit der Fristendisziplin einer Einreichung.
Was die Automatisierung tatsächlich leistet
Der Anbietermarkt hat sich auf eine konsistente Form eingependelt, und die Konsistenz ist aufschlussreich. KPMG beschreibt seine Engine als Automatisierung von Datensammlung, Benchmarking-Analysen, Review und Berichtserstellung an einem Ort. EYs Lösung befüllt OECD-konforme Local-File-Vorlagen über dynamische Platzhalter und erzeugt daraus das Einreichungspaket. Deloitte und andere beschreiben äquivalente Generierungs-Workflows für globale Verrechnungspreisberichte. Zusammen gelesen definieren die Aussagen die aktuelle Automatisierungsgrenze: Erstentwurfserzeugung, Datenextraktion, beschleunigtes Benchmarking und kontrollierte Zusammenstellung der Dokumentationsmodule. Keiner behauptet autonomes Sign-off, und diese Auslassung ist der ehrliche Teil.
Die Pipeline hinter diesen Aussagen läuft in erkennbaren Schritten:
- Daten beschaffen. Intercompany-Transaktionsdaten, Summen- und Saldenlisten, Segmentinformationen, Verträge und Einheiten-Metadaten aus dem ERP und angrenzenden Systemen ziehen. Schnittstellen zu ERP-Systemen und Datenbanken sind inzwischen Standard-Produktfeatures statt Integrationsprojekte, was zählt, weil die manuelle Datensammlung historisch der Ort war, an den die meisten Stunden gingen.
- Normalisieren und abstimmen. Stammdaten standardisieren, Rechtseinheiten und Transaktionen mappen und Verrechnungspreis-Inputs mit statutarischen und Management-Konten abstimmen. Dieser Schritt entscheidet alles Nachgelagerte: Ein Local File auf Transaktionsdaten, die sich nicht mit den Konten abstimmen lassen, ist ein Defense File, das sich selbst widerlegt.
- Benchmarken. KI-gestützte Vergleichssuchen, Unterstützung bei der Funktions- und Risikoanalyse und Margenberechnung komprimieren Arbeit, die Spezialistenwochen verbrauchte. Die menschliche Durchsicht bleibt bei Methodenwahl und Vergleichbarkeitsanpassungen, wo die Analyse Argument ist statt Arithmetik.
- Entwerfen. Jurisdiktionsspezifische Local-File- und Master-File-Vorlagen aus den strukturierten Daten befüllen, mit Platzhalterbibliotheken und Vorjahresdokumenten als Extraktionsquellen. Der Entwurf erbt seine Zahlen aus dem abgestimmten Datensatz, sodass eine Zahl, die in drei Dokumenten erscheint, aus einer Quelle kommt.
- Pillar Two und Amount B überlagern. Testen, ob derselbe Datensatz CbCR, den GloBE Return, die Bewertung der Transitional Safe Harbours und das Amount-B-Scoping für qualifizierende Vertriebe trägt. Das Overlay ist der Punkt, an dem Einzweck-Dokumentationstools ihre Grenzen zeigen, denn der Wert liegt darin, dass ein Datensatz mehrere Regime kohärent bedient.
- Paketieren. Arbeitspapiere, Verträge, Abstimmungen, Benchmarking-Ergebnisse und Versionshistorie in einem indexierten Defense File bewahren.
Konsistenz ist der neue Liefergegenstand
Die tiefere Verschiebung 2026 betrifft den Zweck des Outputs. Als die Dokumentation in der Schublade lag, war interne Inkonsistenz ein latentes Risiko. Jetzt, da Behörden CbCR erhalten, zunehmend die Dokumentation selbst erhalten und GloBE Returns erhalten werden, die aus benachbarten Daten gebaut sind, ist Konsistenz über das Paket hinweg das Erste, was eine automatisierte Durchsicht auf Behördenseite testen wird.
Das rahmt den Business Case der Automatisierung neu. Schnelleres Entwerfen ist wertvoll, aber der Unterschied liegt darin, ob das System ERP-Daten, Benchmarking, Action-13-Dokumentation, Pillar-Two-Inputs und Amount-B-Scoping zu einem kontrollierten Prozess verbindet, sodass eine Änderung der zugrunde liegenden Daten überall dorthin propagiert, wo sie hingehört. Ein Konzern, der seine Local Files aus einem Extrakt entwirft, sein CbCR aus einem anderen und seine GloBE-Berechnungen aus einem dritten, hat die Produktion von Widersprüchen automatisiert.
Das Transaktionsinventar verdient als Schlüsseldatensatz besondere Aufmerksamkeit. Jeder dokumentierte konzerninterne Fluss sollte an die Bücher, die relevanten Verträge und die Richtlinie gebunden sein, die ihn bepreist. Wo das Inventar abgestimmt und aktuell ist, ist der Rest der Pipeline Zusammenbau. Wo es jährlich aus Gedächtnis und E-Mails neu aufgebaut wird, rettet kein Entwurfstool die Dokumentation, die darauf sitzt.
Kontrollen, Versionierung und das Defense File
Weil der Output dieser Pipeline das ist, was der Konzern einer Steuerbehörde im Streitfall übergibt, sehen die Engineering-Prioritäten wie Prüfungsprioritäten aus. Versionskontrolle auf Dokumentationsmodulen, damit die 2029 verteidigte Dokumentation nachweislich die 2026 erstellte ist. Kontrollierte Evidenz: Arbeitspapiere, Verträge und Abstimmungen, indexiert gegen die Aussagen, die sie stützen. Ein aufgezeichneter Review-Trail, der zeigt, welcher Spezialist welches Modul durchgesehen hat, was sich zwischen Entwurf und Final geändert hat und wer die Freigabe erteilt hat. Anbieter bauen das zunehmend ein, und es ist das Feature-Set, das bei der Auswahl am stärksten gewichtet werden sollte, noch vor der Eloquenz des Entwurfs.
Generierter Text braucht seine eigene Kontrolle. Ein Modell, das Funktionsanalyse-Narrative aus Vorjahresdokumenten und Verträgen entwirft, wird gelegentlich flüssige Behauptungen produzieren, die die Evidenz nicht stützt, und in einem Verrechnungspreisstreit ist eine unbelegte Behauptung Munition für die Gegenseite. Dieselbe Regel, die für Zahlen gilt, sollte für Prosa gelten: Tatsachenaussagen in der Dokumentation führen auf eine Quelle im Defense File zurück, und der Review-Schritt prüft diese Spur bei wesentlichen Aussagen, nicht nur die Grammatik.
Die operative Realität ist, dass der Großteil der Programmkosten vor dem Entwerfen sitzt: Einheiten-Stammdaten, Transaktionsmapping, Abstimmung mit den statutarischen Konten und die jährliche Pflege der Benchmarking- und Scoping-Logik, während sich die OECD-Leitlinien bewegen. Konzerne, die das Entwurfstool finanzieren und die Datenschicht aushungern, bekommen den charakteristischen Fehlschlag von 2026: schön formatierte Local Files, schnell produziert, auf Zahlen ruhend, die niemand mit den Konten verknüpfen kann. Die Konzerne, die es richtig machen, behandeln die Dokumentation als sichtbaren Output eines governten Datensatzes und die jährliche Einreichungsfrist, wo es sie inzwischen gibt, als Regressionstest der Pipeline.
Häufige Fragen
Können KI-generierte Local Files ohne Spezialistendurchsicht eingereicht werden?
Nein, und die Anbieter behaupten es selbst nicht. Die glaubwürdige Automatisierungsgrenze 2026 liegt bei Erstentwurf, Datenzusammenstellung und beschleunigtem Benchmarking, während Methodenwahl, Vergleichbarkeitsurteile und Sign-off bei Menschen bleiben. Der praktische Gewinn ist, dass Spezialisten einen befüllten, evidenzverknüpften Entwurf durchsehen statt einen zusammenzustellen, was verschiebt, wohin ihre Stunden gehen, nicht ob sie gebraucht werden. Eine Dokumentation, die ohne dokumentierte menschliche Durchsicht eine Steuerbehörde erreicht, ist ein Governance-Versagen, unabhängig von ihrer Qualität.
Wie bereiten wir uns auf Jurisdiktionen vor, die von Dokumentation auf Anforderung zu jährlicher elektronischer Einreichung wechseln?
Als Änderung der Fristenarchitektur behandeln. Rumäniens Regeln von 2026, nach denen große Steuerpflichtige die Verrechnungspreisdokumentation jährlich elektronisch über SPV einreichen müssen, sind ein frühes Beispiel: Dokumentation, die bisher fertiggestellt werden konnte, wenn der Prüfungsbescheid kam, muss jetzt jedes Jahr produktionsreif sein. Das zieht Datensammlung, Abstimmung und Entwurfsarbeit in den jährlichen Compliance-Kalender neben die gesetzlichen Abschlüsse und bestraft Prozesse, die auf einem Endspurt beruhen. Konzerne mit Einheiten in solchen Jurisdiktionen sollten die Verrechnungspreisdokumentation wie eine Einreichung terminieren, nicht wie eine Eventualität.
Wo passt Amount B in einen automatisierten Dokumentationsprozess?
Als Scoping- und Richtlinien-Overlay, nicht als separater Arbeitsstrang. Für qualifizierende Basisvertriebsaktivitäten sollte der Prozess Einheiten jährlich gegen die Scoping-Kriterien testen, den vereinfachten Ansatz anwenden, wo er trägt, und die Scoping-Analyse samt Ergebnissen im Defense File aufbewahren. Weil sich die OECD-Leitlinien weiterentwickeln, braucht die Scoping-Logik einen Verantwortlichen und eine jährliche Überprüfung, und die in jedem Jahr angewendete Regelversion sollte mit der Dokumentation, die sie geprägt hat, festgehalten werden.