Das Corporate Treasury erfüllt im Einklang mit der Unternehmensstrategie eine Vielzahl von Funktionen. Basierend auf dem verabschiedeten Treasury Richtlinienwerk erstrecken sich die klassischen Aufgaben vom Cash- und Liquiditätsmanagement über die Investitions- und Finanzierungsverwaltung bis hin zur Absicherung der finanziellen Risiken. Darüber hinaus verantworten viele Treasury Einheiten weitere Teilbereiche wie zum Beispiel das Versicherungsmanagement oder das Pensionsmanagement. Um Transparenz über die aktuelle Situation zu erlangen und auch zukünftige Entwicklungen abschätzen zu können, bedarf es einer klar strukturierten Reportinglandschaft sowie einer detaillierten Planung auf unterschiedlichen Ebenen. In Abhängigkeit der Verwendung differenziert die Praxis hier das operative Reporting, das Management Reporting sowie das regulatorische Reporting. Im Wesentlichen verbirgt sich hinter dieser Aufteilung neben unterschiedlichen Empfängerkreisen auch jeweils andere fachliche Anforderungen. Darüber hinaus spielt bei der Berichtskonzeption und -umsetzung die Systemlandschaft eine wesentliche Rolle.

Dieser Artikel gibt einen Überblick über die eingesetzte Software in Abhängigkeit der Art des Reportings und der Planung. 

Operatives Reporting: Elementares Steuerungselement der täglichen Aufgaben im Treasury 

Im täglichen „Treasury Doing“ wird eine Vielzahl von Aktivitäten durchgeführt. Die täglichen Aktivitäten und Prozesse laufen auf dem implementierten Treasury Management System (TMS). Die operativen Reports und Dashboards befassen sich hierbei thematisch mit der aktiven Steuerung der Finanzmittel, Monitoring der Linien oder dem Bestand im Treasury Nebenbuch. Somit werden die vorhandenen Daten aus dem transaktionalen System, dem eingesetzten TMS, genutzt. Typischer Weise wird innerhalb des Systems mit den zur Verfügung stehenden Bordmitteln die operative Berichterstattung über sogenannte Standard Reports umgesetzt. Aus diesen Standard Reports können dann auch direkt Aktivitäten angestoßen werden. In der Regel sind die fachlichen Anforderungen technisch zum größten Teil in den Standard Reports umgesetzt und ein individueller Aufbau ist hier nicht gefordert. Im SAP S/4 HANA Umfeld sind das zum Beispiel die Fiori-App „Cashflow Analyse“ oder die Fiori-App „Treasury Bestandsnebenbuch“. In der Praxis hat sich in Transformationsprojekten jedoch bewährt, bereits zu Beginn sicherzustellen, dass das ausgewählte TMS die fachlichen Anforderungen an das operative Reporting vollumfänglich umsetzen kann. Eine 1:1 Abstimmung zwischen den aktuellen Reports mit deren Anforderungen und zukünftigen Reports kann hier ein Ansatz sein. Das operative Reporting hat für manche Funktionen auch Überschneidungen mit dem Management Reporting. 

Management Reporting: Adressatengerechtes Reporting an die Unternehmensleitung  

Viele Treasury Einheiten berichten im monatlichen Turnus an die Geschäftsleitung im Rahmen des Treasury Reports. Auch Ad-Hoc Anfragen können aus der Geschäftsleitung kommen und stellen in Abhängigkeit des Reifegrads der Treasury-Reporting Landschaft eine kleinere oder größere Herausforderung für die Verantwortlichen dar. In zukunftsgerichteten Treasury Abteilungen werden mit Hilfe entsprechender Business Intelligence (BI) Tools auch dem Management eigene Dashboards zur Verfügung gestellt. Hierbei kann das Management dynamisch und interaktiv die relevanten Informationen zu einem gewissen Grad selbstständig generieren und die nötige Detailtiefe über Drill-Down-Funktionalitäten definieren. Die Herausforderung beim Management Reporting ist sehr häufig, dass die relevanten Daten in einer Vielzahl von Systemen abliegen und die für Reportingzwecke zunächst in einem spezifischen Data Warehouse konsolidiert und aggregiert werden müssen. Das können ausgelagerte Themenbereiche in Drittsystemen sein, wie zum Beispiel Trade Finance, Liquiditätsmanagement, Pensionen, finanzielle Anlagen an einen Vermögensverwalter. Ein konkretes Beispiel ist hier die Auslastung von Kreditlinien und deren Ausnutzung. Diese können in Abhängigkeit der Systemlandschaft zum Beispiel in einer Trade Finance Lösung wie GTC geführt werden, wobei die allgemeinen Kontokorrentlinien der Tochtergesellschaften zum Beispiel in SAP TRM dargestellt werden. Um diese Fragmentierung der Daten zu überwinden und zu konsolidieren werden in der Regel die relevanten Daten und Tabellen aus den Systemen extrahiert und in einem Data Ware House übergeben. Die Datenbank steht dann im Mittelpunkt des ETL (Extract, Transform, Load) Prozesses. Die Daten werden dann in unterschiedlichen Stages transformiert, gegebenenfalls auch mehrere Zwischenrechnungen durchgeführt und dann in einer Darstellungslösung, wie zum Beispiel SAP Analytics Cloud oder Microsoft Power BI präsentiert. Die Ausgestaltung des berichts- und analysespezifischen Datenmodells und der technischen Infrastruktur steht hierbei im Fokus bei der Konzeption. Eines der Ziele in diesen Projekten ist es dem End User und somit dem Treasury Anwender eine hohe Flexibilität bei der Konzeption neuer Berichte und Ad-hoc-Analysen zu ermöglichen, ohne dabei abhängig von der IT-Abteilung zu sein. 

Die bisher beschriebene Vorgehensweise für das Management Reporting gilt auch für den Spezialbereich der Liquiditätsplanung. Eine finale Planung der Liquidität in einem transaktionalen System führt basierend auf unterschiedlichen Erfahrungswerten aus der Praxis nicht zum gewünschten vollumfänglichen Bild. Eine Klassifizierung von Ist-Cashflow Daten wird in der Regel in den ERP-Systemen oder anhand von Kontoauszugsdaten erstellt, welche dann für den weiteren ETL Prozess extrahiert werden. Bei der BI-gestützten Umsetzung des Planungsprozesses sollte darauf geachtet werden, dass weiterhin eine hohe Flexibilität – zum Beispiel durch finale manuelle Anpassungen der Planungsdaten auf unterschiedlichen Ebenen – erhalten bleibt und die Daten im Back End entsprechend angepasst werden. Häufig eingesetzte Lösungen sind hierbei die SAP Analytics Cloud sowie Microsoft Power BI. Diese BI-Reporting Systeme bieten neben einer Vielfalt von Möglichkeiten zur Datenintegration, eine flexible, schnelle und adressatengerechte Datenaufbereitung und insbesondere eine automatisierte Berichtserstellung.

Regulatorisches und vertragliches Reporting: Meldeverpflichtungen als systemseitiger Flickenteppich 

In Abhängigkeit des Umfanges der Funktionen einer Treasury Abteilung ergeben sich regulatorische und vertragliche Meldeverpflichtungen, welche klassischerweise unter dem Begriff des regulatorischen Reportings gefasst werden. Die gängigen Beispiele sind hier die European Market Infrastructure Regulation (EMIR), Dodd-Frank Act Verpflichtungen oder auch die Meldeformulare für das Außenwirtschaftliche Meldewesen (AWV und Z4, Z5 etc.). In der Praxis beobachtet man hier keine einheitliche Vorgehensweise. Für das EMIR Reporting gibt es in der Regel Lösungsansätze aus dem Treasury Management System heraus, welches aber auch an die jeweilige Bank ausgelagert werden kann. Die Meldungen im Rahmen der Außenwirtschaftsverordnung können auch über Standard-Programme direkt aus dem ERP erfolgen, zum Beispiel bei SAP S/4 HANA. Für bestimmte vertragliche Verpflichtungen werden auch Eigenentwicklungen genutzt oder auf Drittanbieter, wie zum Beispiel Finastra, zurückgegriffen. 

Die Anforderungen an das Treasury Reporting werden immer dynamischer und komplexer. Eine Einteilung in die Bereiche operatives Reporting, Management Reporting und Regulatorisches Reporting ist erfahrungsgemäß sinnvoll. Die unterstützende Systemarchitektur für das Reporting lässt sich durch diese fachliche Einteilung sehr gut konzipieren und umsetzen. In den derzeitigen Transformationsprojekten lohnt es sich während der Einführung von Treasury Systemen bereits in die Konzeption und Umsetzung des entsprechenden Reporting zu investieren. 

Quelle: KPMG Corporate Treasury News, Ausgabe 121, Mai 2022
Autoren:
Börries Többens, Partner, Finance and Treasury Management, Corporate Treasury Advisory, KPMG AG
Mattis Schwind, Manager, Finance and Treasury Management, Corporate Treasury Advisory, KPMG AG