Teil A: Ganzheitliches VP-Management / 4.4.5 Einsatz von Data & Analytics im VP-Prozess

Autoren: Jörg Hanken, Dr. Alexander Totzek

Big Data und Data & Analytics (‹D&A‹) sind in jedweder strategischen Diskussion in Unternehmen unter den Topthemen. Vereinfachend gesagt geht es dabei um den Prozess der Datenextraktion und -sammlung, das Verständnis und die Aufbereitung sowie um die Analyse und Visualisierung von Daten.

Der Einsatz von D&A führt zu erheblichem Mehrwert in allen Bereichen des Verrechnungspreiszyklus, von der Strategie über die Verrechnungspreissetzung bis hin zur Verteidigung. Auch die Finanzverwaltung setzt D&A-Ansätze ein, um unternehmensinterne, aber auch öffentlich verfügbare Daten über das Unternehmen auszuwerten, und so Rückschlüsse auf die Fremdüblichkeit verrechnungspreisrelevanter Sachverhalte zu ziehen. Auch vor diesem Hintergrund empfiehlt es sich, selbst D&A-Analysen im Vorfeld einer steuerlichen Betriebsprüfung durchzuführen.

Im Folgenden sollen zunächst kurz die wesentlichen D&A-Verfahren dargestellt werden. Der Fokus dieses Abschnitts liegt aber in der Darstellung konkreter D&A-Anwendungsbeispiele entlang des Verrechnungspreiszyklus. Zuvor widmen wir uns aber dem in der Praxis immer wieder unterschätzten Bereich der Datenextraktion und -aufbereitung.

4.4.5.1 Datenextraktion und -aufbereitung

Vor jedweder Analyse steht die i. d. R. deutlich aufwendigere Extraktion und Aufbereitung von Daten. Im Verrechnungspreiskontext wird auf eine Vielzahl unterschiedlicher interner und externer Daten- und Informationsquellen zurückgegriffen, wobei wir uns in den folgenden Kapiteln auf strukturierte Daten fokussieren wollen.

Die folgende Tabelle gibt einen Überblick über die Arten und die Heterogenität der (strukturierten) Daten, die man üblicherweise im VP-Prozess benötigt:

Zweck	Art der Daten	Datenquelle	Intern/extern	Häufigkeit
VP-Dokumentation – Local File – IC-Matrix	Rechnungsdaten: wer verrechnet welche Transaktionsgruppe und in welcher Höhe an wen?	In der Praxis unterschiedlich: Bewegungsdaten aus der GuV (z. B. SAP FI) oder aus den Abrechnungsdaten (z. B. SAP SD) oder Daten aus der Konsolidierung (z. B. SAP SEM BCS) oder aus dem I/C oder der Netting/ Zahlungsabwicklung	Intern	Für VP-Dokumentation: i. d. R. einmal im Jahr Für Monitoring: i. d. R. monatlich oder quartalsweise
VP-Dokumentation – Local File – arm's length test	Margendaten (bei R-, TNMM, C+, Profit Split) oder Artikelpreisdaten (bei CUP)	Die Legal-Entity-GuV wird i. d. R. je trading partner relation bis zum EBIT segmentiert. Z. B. aus SAP CO-PA als Basis, abgestimmt mit SAP SD und FI. Zielmargen-Bandbreiten gem. Benchmarking-Studien. Für Profit-Split-Analysen findet man häufig auch Analysen basierend auf Daten aus dem Management Accounting.	Intern und extern (Benchmarking-Studie, Ziel-IQR)	Für VP-Dokumentation: i. d. R. einmal im Jahr Für Monitoring: i. d. R. monatlich oder quartalsweise
VP-Dokumentation – CbCR	Bilanz-, GuV-, Cashflow- Daten, Anzahl Mitarbeiter, F&R-Daten.	Mapping von diversen Bilanz- und GuV Konten auf die Felder des CbCR-Table 1 (z. B. aus der Konsolidierung, SAP SEM-BCS). Anzahl Mitarbeiter aus dem HR-System. Tax Cash aus dem Tax-Accounting-System oder per Workflow-Tool einsammeln. F&R-Profil/main activities aus den Local Files.	Intern	Für VP-Dokumentation: i. d. R. einmal im Jahr Für Monitoring: i. d. R. monatlich oder quartalsweise
Steuererklärungen – Anlage zu VP[19]	Länderabhängig – i. d. R. Rechnungsdaten: Wer verrechnet welche Transaktionsgruppe und in welcher Höhe und mit welcher VP-Methode an wen? Und: unstrukturierte Daten	Siehe oben ›VP-Dokumentation – Local File – IC Matrix‹	intern	i. d. R. einmal im Jahr
VP-Margenmonitoring	GuV-Daten	Die Legal-Entity-GuV wird i. d. R. je trading partner relation bis zum EBIT segmentiert. Z. B. aus SAP CO-PA als Basis, abgestimmt mit SAP SD und FI. Zielmargen-Bandbreiten gem. Benchmarking-Studien.	Intern und extern (Benchmarking-Studie, Ziel-IQR)	i. d. R. monatlich oder quartalsweise

In Bezug auf ›Daten‹ möchten wir gerne folgende praxisrelevante Aspekte hervorheben:

• Datendefinition (Tabellen, Wertefelder, Konten): Zuerst sollte man die benötigten Daten exakt definieren. Dies ist gar nicht so einfach, weil die Vorgaben der Länder und der OECD oft von Leuten formuliert werden, die keinen täglichen System-/ERP-Kontakt haben. Dadurch werden Begrifflichkeiten verwendet, die ein Controller oder Buchhalter oder Steuerexperte so nicht kennt bzw. so nicht aus dem ERP-System extrahieren kann. Das beste Beispiel ist das CbCR: Wenn dort ›Umsatz‹ abgefragt wird, dann ist nicht naheliegenderweise ›Net Sales‹ gemeint, sondern ›alle Einnahmen außer Dividendenerträge‹^[20]. Auch ›Kapital‹ ist nicht klar definiert. In den OECD-Vorgaben liest man ›full time equivalents‹, im deutschen BMF-Schreiben ›Anzahl Mitarbeiter‹ – zwei sehr unterschiedliche Zahlen u. s. w. Das heißt, letztlich besteht an vielen Stellen Interpretationsspielraum, der durchaus im Sinne des Unternehmens genutzt werden sollte. Wichtig ist nur, dass zeitnah und detailliert dokumentiert wird, wie man welche Daten-Anforderungen interpretiert hat (am besten ...