Im Kontext einer Produktkonsolidierung und der für 2025 angekündigten Einstellung des Supports für den Bank Analyzer wurde bei SAP das klassische SAP Nebenbuchprodukt Smart AFI durch SAP FPSL (Financial Product Subledger) ersetzt. Als zentrales Nebenbuch (Subledger) sorgt dieses zukünftig für die Verwaltung und Bewertung diverser Finanzinstrumente (und Versicherungsverträge). Der vorliegende Artikel konzentriert sich auf die Einführung und Verwendung von SAP FPSL als Nebenbuch für Finanzinstrumente.

Welche Vorteile ergeben sich aus der Einführung von SAP FPSL für Banken?

In den letzten Jahren wurden Banken durch sich regelmäßig ändernde Accounting Standards und andere Regularien vor große Herausforderungen gestellt. Eines der prominentesten Beispiele war die Umstellung zur Kategorisierung und Bewertung von Finanzinstrumenten von IAS 39 auf IFRS 9. Dies ist jedoch nicht die letzte Anstrengung im Accounting gewesen. Auch zukünftig müssen neue Standards, Änderungen bestehender Standards (wie z.B. IAS 37) und Regularien, wie die des Basler Ausschusses, in einer dynamischen Bankenwelt implementiert werden. Neben Anpassungen im Fachbereich müssen diese Neuerungen auch in der sich stetig wandelnden IT umgesetzt werden. Somit können auch überschaubare Änderungen, wie zuletzt bei der Umsetzung von IFRS 15 und 16, mit enormem Aufwand verbunden sein.

Dieser hohe Implementierungsaufwand ist nicht nur auf die Komplexität der abzubildenden Finanzinstrumente und Sachverhalte in der Finanzbranche zurückzuführen, sondern vor allem auf den Anpassungsbedarf in den vorhandenen Banksystemen. Diverse Produkte verlangen nach spezialisierten Systemen und führen daher oft zu einer sehr heterogenen und zumeist zersplitterten Systemlandschaft, dessen Grundstein oftmals ein eher statisches Kernbankensystem bildet.

Dies hat zur Folge, dass produktübergreifende regulatorische Anforderungen in einzelnen Systemen getrennt zu implementieren und zu testen sind. Jedes System benötigt dabei Ressourcen und Expertenwissen, wodurch hohe Kosten verursacht werden. Hinzu kommt, dass das Expertenwissen über die komplexen Kernbankensysteme über die Jahre abnimmt (z.B. aufgrund von Personalfluktuation oder internen Umstrukturierungen) und veraltete Programmiersprachen und Systemeigenschaften Neuimplementierungen erschweren oder sogar unmöglich machen. Aus diesen Gründen werden die Anpassungen eines Kernbankensystems häufig als zu riskant erachtet.

Für Banken ist es daher attraktiv in einem eigenen System produktübergreifend das Nebenbuch zu führen. Hierdurch müssen Accounting-Anforderungen nicht mehr dezentral in den bestandsführenden Systemen implementiert werden. Stattdessen ist eine zentrale Umsetzung im konsolidierten Nebenbuch möglich.

Als Lösung hierfür bietet sich SAP FPSL als System zur Führung des Nebenbuchs an. SAP FPSL ermöglicht es mehrere Vorsysteme an ein zentrales Nebenbuch anzuschließen und bietet dabei den Vorteil, dass neue Accounting-Anforderungen produkt- und systemunabhängig im zentralen Nebenbuch implementiert werden können.

Darin liegt jedoch nicht der einzige Vorteil, der bei einer Einführung eines zentralen Nebenbuchs entsteht. Im folgenden Abschnitt werden zunächst die einzelnen Vorteile und Möglichkeiten genauer betrachtet. Im zweiten Abschnitt werden die technischen Gegebenheiten und Voraussetzungen näher erläutert. Zudem wird anhand eines Best Practice Beispiels die mögliche Anbindung von Loan IQ an SAP FPSL beschrieben.

Flexibilität der IT-Architektur

Die sich schnell ändernden Anforderungen verlangen nach einer flexiblen und agilen IT-Infrastruktur. Neue Buchungs- oder Bewertungslogiken sollten produkt- und systemübergreifend, möglichst kostengünstig, implementiert werden können.

Hierfür bietet sich SAP FPSL als Lösung an und schafft die Möglichkeit, die Daten mehrerer produktspezifischer Systeme in einem Subledger zu vereinen. Der Vorteil hierbei liegt nicht nur in der Vereinheitlichung der heterogenen Datenbestände aus den Quellsystemen, sondern auch darin, neue Anforderungen direkt auf der Subledger-Ebene umzusetzen.

Konkret bedeutet dies, dass die Quellsysteme von der Implementierung der neuen Logik unberührt bleiben können. Somit wird auch ermöglicht, dass veraltete Systeme den heutigen Anforderungen gerecht werden. Dadurch kann gegebenenfalls eine teure und risikobehaftete Kernbankensystemablöse abgewendet werden.

Erzeugung von Synergien und Kostensenkung

Das Implementierungen auf zentraler Ebene umgesetzt werden können, bringt jedoch nicht nur Flexibilität in die IT-Architektur, sondern birgt auch großes Potential, Effizienzen zu steigern und Kosten zu minimieren.

Die Effizienzsteigerung rührt vor allem daher, dass die Umsetzungsmaßnahmen zentralisiert auf SAP FPSL-Ebene anhand von bereits standardisierten Daten stattfinden. Dadurch wird sowohl der Implementierungsaufwand als auch der Testaufwand zentralisiert und deutlich reduziert.

Ohne die Verwendung eines systemübergreifenden Subledgers müsste die Implementierung pro System vorgenommen und getestet werden. Dazu benötigen die Experten bei der Umsetzung nicht nur Produkt- und Fachwissen, sondern meist auch systemspezifische und technische Kenntnisse. Dies führt oft zu einem sogenannten Silo-Denken. Hierbei besteht die Gefahr, dass Maßnahmen in den produktspezifischen Systemen unterschiedlich interpretiert und umgesetzt werden. Ein solches Silo-Denken verursacht daher eine zunehmende Heterogenität in den Daten und der Systemlandschaft einer Bank.

Zusammenfassend kann festgehalten werden, dass SAP FPSL auf der technischen Seite Synergien erzeugt und zugleich dem Fachbereich erlaubt, sich auf die fachliche Konfiguration zu konzentrieren. Allgemein gilt, dass die technischen Anforderungen durch SAP FPSL für alle Vorsysteme zentral vorgegeben werden.

Vereinfachung nachgelagerter Prozesse

Ein weiterer wichtiger Faktor, der für die Verwendung von SAP FPSL spricht, ist der Detailgrad an Daten, der durch SAP FPSL operativ zugänglich gemacht wird. Insbesondere Reporting-Anforderungen, die vorher entweder durch das Hauptbuch (General Ledger) oder durch die heterogenen Datenhaushalte der Quellsysteme erfüllt wurden, können vereinheitlicht und automatisiert werden.

Bei vielen Banken wird noch immer der General Ledger für das Detailreporting herangezogen und somit zweckentfremdet. Dies hat den Nachteil, dass für das Reporting benötigte Buchungsdetails anhand von immer spezifischeren Konten im Kontenplan erkennbar gemacht werden. Es wird also für nahezu jede mögliche Ausprägung eines Sachverhaltes ein eigenes Konto angelegt (z.B.: Kontensplit für Inlands-/Auslandsgeschäfte). Dafür müssen in der Buchungslogik des General Ledgers sehr viele fachliche Parameter, wie z.B. die Währung, Counterparty oder Region, in der Kontenfindung sowohl fachlich als auch technisch umgesetzt werden. Im Ergebnis gestaltet sich die Kontenfindung als komplex und fehleranfällig, da jeder zusätzliche Parameter in einer technischen Ableitungsregel definiert werden muss.

SAP FPSL bietet eine Reihe an standardisierten Detail-Reports, die anstelle des General Ledgers für die Berichtserstattung genutzt werden können. Zusätzlich kann nach allen befüllten Datenfeldern gefiltert und so neue Reports benutzerfreundlich erzeugt werden. Da diese Reports alle relevanten Daten aus den Quellsystemen enthalten und ein detaillierter Subledger-Kontenplan vorhanden ist, muss im General Ledger kein so hoher Detailgrad mehr aufrechterhalten werden. Der Kontenplan und die Kontenfindung im General Ledger können also deutlich vereinfacht und so der Wartungsaufwand reduziert werden.

Zusätzlich bedeutet ein hoher Detailgrad an Daten im Subledger, dass die erzeugten Reports auch zur Belieferung anderer Endabnehmer, wie z.B. dem Meldewesen oder Controlling, verwendet werden können. Dies führt nicht nur zu einer allgemein besseren Datenqualität, sondern erleichtert zusätzlich die Abstimmung zwischen den Daten der einzelnen Abteilungen. Ein Grund hierfür ist auch, dass ohne ein zentrales Nebenbuch die Daten anderer Abteilungen, die meist auf Vertrags-Ebene vorliegen, oftmals nur mit kumulierten Hauptbuchkonten (General Ledger Accounts) abgestimmt werden können. Mit SAP FPSL lässt sich der General Ledger Account jedoch nicht nur auf Subledger Account-Ebene entschlüsseln, sondern erlaubt auch Auswertungen auf Vertragsbasis.

Vereinheitlichung und Anonymisierung von Daten

Eine verbesserte Datenqualität allgemein und eine Abstimmung dieser ist dabei nicht nur für Synergien zwischen verschiedenen Fachbereichen wünschenswert, sondern spätestens mit den steigenden Anforderungen in den Bereichen Meldewesen und Risiko verpflichtend.

Denn nicht zuletzt mit den BCBS-239 Grundsätzen des Baseler Ausschusses für Bankenaufsicht sind Themen wie Datenqualität (u.a. Traceability), Governance und eine sinnvolle Aggregation und Vereinheitlichung von Daten unausweichlich geworden. Dabei sind nach Angaben des Basler Ausschusses die Anforderungen nach wie vor unzureichend in den Banken umgesetzt[1]. SAP FPSL kann Banken dabei helfen einen ersten Schritt in Richtung vereinheitlichte Daten zu gehen.

Da auch das Thema Datenschutz mit der DSGVO nicht zu vernachlässigen ist, bietet die Einführung eines zentralen Nebenbuches die Gelegenheit, den Anonymisierungsgrad, der im Accounting verwendeten Daten, neu anzupassen und somit den Gesetzesgrundlagen gerecht zu werden.

Was muss bei der Einführung von SAP FPSL beachtet werden?

Die Grundvoraussetzung für die Einführung von SAP FPSL ist, dass die Bank einen Nebenkontenplan erstellt und diesen für alle relevanten Geschäftsvorfälle in SAP FPSL definiert. Dadurch können alle angelieferten Geschäftsvorfälle in den Nebenbuchkonten (Subledger Accounts) gebucht werden, ohne Einfluss auf den finalen Hauptkontenplan zu nehmen. Zu erwähnen ist hierbei, dass SAP FPSL auf der neuen in-memory[2] Datenbankarchitektur S/4HANA von SAP basiert und zudem Cloud-fähig ist. SAP FPSL unterstützt sowohl multi-GAAP Accounting als auch multi-Currency Accounting. So kann SAP FPSL z.B. das Geschäft parallel nach IFRS 9 und HGB buchen und zugleich sowohl eine Heimwährung als auch eine Konzernwährung führen. Die FX Bewertungen und Fixierungen finden dabei im Einklang mit IAS 21 statt. Auch mehrere Mandanten lassen sich in SAP FPSL führen, wodurch SAP FPSL auch mehreren Zeitzonen gerecht werden kann.

Des Weiteren gibt es Standardschnittstellen zur vereinfachten Anbindung an SAP FI. Ein Anbinden von SAP FPSL an Oracle Financial oder Peoplesoft GL ist ebenfalls möglich. Damit die Anlieferung der SAP FPSL Buchungen an den General Ledger funktioniert, stellt SAP FPSL einen Mechanismus zur Verfügung, der die einzelnen Buchungen auf den Subledger Accounts aggregiert und an den General Ledger anliefert. Das genaue Zusammenspiel zwischen den SAP FPSL Subledger Accounts und den General Ledger Accounts wird im Abschnitt SAP FPSL Chart of Accounts näher erläutert.

Auf Basis des Subledgers ist ein detailliertes Finanzreporting möglich, sodass Auswertungen auf Einzelbuchungsebene vorgenommen werden können. Grundsätzlich können alle Quelldaten, die im Schritt der Datentransformation an SAP FPSL geschickt werden, in Detailreports mit abgefragt, geclustert oder gefiltert werden.

Abbildung 1 - Detailreport aus SAP FPSL (Display Result Data)

Abbildung 1 zeigt ein Beispiel für einen solchen Report, in dem die Buchungsbestände der Subledger Accounts ausgewiesen werden.

Details, wie z.B. die Klassifikation, die Währung oder der General Ledger Account sind ebenfalls aufgeführt. Der Report könnte auch mit weiteren Informationen in Form von anonymisierten Kundenkennzeichnungen, Industriekennzeichnungen oder interne Kennungen wie z.B. eine Kostenstelle angereichert werden. Voraussetzung hierfür ist, dass diese Attribute aus den Quellsystemen an SAP FPSL übergeleitet werden.

Quelldaten

Die Quelldaten können über die SAP Financial Service Data Plattform (FSDP) und das entsprechende SAP Financial Service Data Management (FSDM) angeliefert werden. Alternativ kann auch eine SAP FPSL-eigene Quelldatenschicht genutzt werden. Diese ist jedoch gegenüber SAP FSDP stark vereinfacht.

Durch die Quelldatenaufbereitung in SAP FSDP ist es möglich, mehrere heterogene Bestandssysteme an SAP FPSL anzubinden. So können die Nebenbücher der verschiedenen bestandsführenden Systeme aus den Bereichen Kredit, Treasury oder Handel in SAP FPSL geführt werden. Basis für die SAP FPSL Anbindung ist immer eine einheitliche Quelldatenschicht, die die verschiedensten Finanzprodukte in einem gemeinsamen Datenstandard abbildet. Zur detaillierten Beschreibung von SAP FSDP als Bestandteil der Banksteuerung ist folgender Artikel zu empfehlen: https://www.finbridge.de/aktuelles/2021/5/11/integration-sap-fsdp-banksteuerung

Sollte die Bank kein Interesse an der Einführung von SAP FSDP als standardisiertes bankfachliches Datenmodell haben, besteht auch die Möglichkeit innerhalb von SAP S/4HANA ein eigenes, konsolidierendes Datenmodell zu entwickeln, auf dessen Basis die Anlieferung an SAP FPSL erfolgt.

Anbindung von Quellsystemen

Zur Anbindung diverser Quellsysteme an SAP FPSL, sollten in einem ersten Schritt die für SAP FPSL relevanten Daten in der S/4HANA Datenbank repliziert werden.

Hierzu gibt es verschiedene technische Methoden. So ist es möglich, die Quelldaten auf der S/4HANA Datenbank entweder via Smart Data Integration (SDI) zu kopieren oder via Smart Data Access (SDA) zu replizieren (real-time oder batch-basiert). Alternativ können die Daten auch mithilfe von Apache Kafka repliziert werden. Wird sich für die SDA Technologie entschieden, so werden die Quelldaten in virtuellen Tabellen auf der S/4HANA Seite vorgehalten. Technisch gesehen werden dabei die Daten nicht auf der S/4HANA Seite gespeichert, sondern über einen sog. Pointer aus der Quelltabelle abgerufen. Zur vollständigen Datenreplikation sollte auf die SDI Technologie zurückgegriffen werden. In einem nächsten Schritt müssen die Daten in einen Standard-Data-Layer konsolidiert werden. Hier bietet sich die SAP FSDP an. Die Nutzung von SAP FSDP als Quelldatenschicht für SAP FPSL bietet den Vorteil, dass SAP sog. Adapter anbietet, die eine Datenanlieferung stark standardisieren und somit auch vereinfachen.

SAP FPSL Objekte

In SAP FPSL ist zwischen folgenden Datentypen zu unterscheiden:

· Stammdaten,

· Bewegungsdaten,

· Marktdaten und

· Zielwerte.

Folgende Objekte müssen aus den Quellsystemen an SAP FPSL angeliefert werden:

i) In SAP FPSL werden sog. Verträge bebucht. Ein Vertrag kann hierbei einer Einlage oder einem Kredit entsprechen.

ii) Ein Vertrag besitzt hierbei immer mindestens einen Businesspartner. Dies kann für einen Kredit-Vertrag z.B. der/die Kreditnehmer*in sein. Bei einer Einlage wäre der Businesspartner der/die Einlagengeber*in.

iii) Für einen Vertrag werden diverse analytische Status angeliefert, wie z.B. die Bewertung (Fair Value oder Fortgeführte Anschaffungskosten) oder die Wertminderungsstufe (1, 2 oder 3).

iv) In SAP FPSL können unterschiedliche Geschäftsvorfälle gebucht werden. Hierzu zählen z.B. die Auszahlung des Kredites, die Tilgung oder die Zinszahlung.

v) Auf Basis der aus den Vorsystemen angelieferten Zielwerten (wie z.B. Zinsabgrenzung, Risikovorsorge oder Fair Value) bucht SAP FPSL die Veränderung gegenüber dem zuletzt angelieferten Zielwert.

vi) Auf Basis der angelieferten Wechselkurse findet eine Fremdwährungs- und Kassabewertung statt, wodurch auch der Fremdwährungsposten in der GuV evaluiert wird.

Daher ist ein integraler Bestandteil bei einer Anbindung von SAP FPSL an ein neues Quellsystem die Datentransformation, sodass SAP FPSL in der Lage ist, die Geschäftsvorfälle im Quellsystem zu verstehen und richtig zu buchen. Diese Datentransformation muss vor der finalen Datenanlieferung an SAP FPSL erfolgen, damit die Quelldaten in einem SAP FPSL-verständlichen Format angeliefert werden können.

SAP FPSL Chart of Accounts

Eine der Kernfunktionalitäten von SAP FPSL ist die multi-GAAP Fähigkeit. Diese wird durch mehrstufige Kontenhierarchien ermöglicht. Dabei stellen die Subledger Accounts die Stufe mit dem höchsten Detailgrad dar. Subledger Accounts können GAAP spezifisch angelegt und angepasst werden, sollten die von SAP FPSL vorgegebenen Accounts nicht ausreichend sein.

Mehrere Subledger Accounts werden zu einer Subledger Account Group zusammengefasst. Auf Grundlage dieser Clusterung werden auf Subledger Account Group Ebene die grundlegenden Parameter, welche für die Buchungslogik ausschlaggebend sind, definiert. Dies bedeutet, dass Vertragsdetails,wie z.B. die Währung oder die Counterparty, bereits auf Subledger Account Group Ebene zu unterschiedlichen Buchungsableitungen führen. Die Kontenfindung der General Ledger Accountsgeschieht mit Hilfe sogenannter Ableitungsregeln (Derivation Rules). In welchen Prozessschritten von SAP FPSL die Kontensalden der Subledger Accounts aktualisiert werden, wird ebenfalls auf Ebene der Subledger Account Groups definiert. Abbildung 2 zeigt die Subledger Accounts, die der Subledger Account Group „Income“ zugeordnet sind. Diese weist wiederum das Financial Statement Segment der Gewinn- und Verlustrechnung (Profit-and Loss Statement) als Attribut auf.

Abbildung 2 - Ansicht der Subledger Accounts innerhalb einer Subledger Account Group

Alle Subledger Account Groups sind einem Financial Statement Segment zugeordnet. Diese Segmente unterteilen sich in Balance Sheet, Profit- and Loss Statement, sowie Equity und sind von SAP FPSL vorgegeben. Um ein flexibles Reporting zu ermöglichen sind die Financial Statement Segmente wiederum in Financial Statement Subsegmente unterteilt. Die Einteilung in verschiedene Subsegmente kann dabei GAAP-spezifisch stattfinden. Abbildung 3 stellt die beschriebene Hierarchie anhand von einigen vereinfachten Beispielen nach IFRS dar.

Abbildung 3 - SAP FPSL Chart of Account Hierarchie

Sind alle Subledger Accounts und Account Groups erstellt und die Derivation Rules definiert, ist in einem letzten Schritt das Mapping der Subledger Accounts auf die General Ledger Accounts vorzunehmen.

In SAP FPSL ist sowohl der Nebenkontenplan (Subledger Chart of Accounts) als auch der Hauptkontenplan (General Ledger Chart of Accounts) hinterlegt, sodass jede Nebenkontenbuchung einem entsprechenden General Ledger Account zugeordnet werden kann. Ein solches Mapping ist in Abbildung 4 ersichtlich. Hier wurde für die Derivation Rule der Zinsaufwände die in der Tabelle aufgeführten Subledger Accounts bestimmten General Ledger Accounts zugeordnet.

Abbildung 4 – Mapping Subledger Account zu General Ledger Account

Best Practice: Loan IQ Anbindung an SAP FPSL

Finbridge konnte in der Vergangenheit bereits Erfahrung bei der Anbindung des bestandsführenden Kreditsystems Finastra Fusion Loan IQ an SAP FPSL sammeln. Ziel eines bereits 2020 abgeschlossenen Projekts war die Überführung der Loan IQ Subledger Funktionalität nach SAP FPSL.

Im Folgenden wird aufgezeigt, wie eine Integration von Loan IQ und SAP FPSL erfolgen kann, sodass SAP FPSL die Subledger Funktionalität von Loan IQ vollständig übernehmen kann.

In einem ersten Schritt der technischen Integration von Loan IQ und SAP FPSL erfolgt die Replizierung der Loan IQ Datenbank in S/4HANA mit der bereits beschriebenen SDI-Technologie. In einem nächsten Schritt erfolgt die Datentransformation, sodass die Loan IQ Daten in einer Quellsystem unabhängigen Datenschicht konsolidiert werden können. Aus dieser Datenschicht kann SAP FPSL über Standard-Adapter täglich beladen werden. Im Anschluss startet der SAP FPSL Prozess, der die täglichen Buchungen im Nebenbuch erzeugt.

Damit SAP FPSL die Loan IQ Daten versteht, sind folgende Transformationsregeln definiert:

1. Fusion Loan IQ erlaubt es auf den drei Objekten Deal (Vertrag), Facility (Kreditrahmen) und Outstanding (Ziehung) Accounting-wirksame Geschäftsvorfälle zu erfassen. Loan IQ nutzt für die Erfassung der Buchungen Portfolien, die den drei Hauptobjekten zugeordnet sind. Daher wurde in der Anlieferung an SAP FPSL aus der Kombination von Objekt (Deal, Facility und Outstanding) und Portfolio ein Vertrag abgeleitet.

2. Die Verträge werden um alle Accounting-relevanten Merkmale (z.B. Status) angereichert.

3. Diesen Verträgen werden im nächsten Schritt die Vertragspartner zugeordnet.

4. Um die für SAP FPSL relevanten Geschäftsvorfälle zu erzeugen, werden in einem weiteren Schritt alle Accounting-wirksamen Transaktionen in Loan IQ identifiziert und auf einen SAP FPSL-verständlichen Transaktionsstandard (Basis hierfür ist das Accounting-Mapping in SAP FPSL) gemappt. Hierzu wird der Transaktionstyp (z.B.: Kreditauszahlung, Tilgung oder Zinszahlung), der Betrag (inkl. Währung), die Buchungsrichtung und das Buchungsdatum definiert. Der Screenshot in Abbildung 5 zeigt dabei beispielhaft die Tabelle, mit welcher Transaktionstypen (Spalte 1) wie oben beschrieben angelegt und verwaltet werden können.

Abbildung 5 – View zum Definieren von Transaktionen inklusive buchungsrelevanter Parameter

5. In weiteren Schritten werden die in Loan IQ berechneten Zielwerte (z.B. Zins-Abgrenzung, Gebühren-Amortisierung) erfasst und in einen Ledger-spezifischen (z.B. HGB und IFRS) Zielwertstandard überführt (RDL). Alternativ wäre eine Zielwertberechnung auch direkt in SAP FPSL möglich.

6. Dem folgend werden die Risiko-Zielwerte (z.B. Fair Value, Risikovorsorge und Wertminderungsstufe) aus dem Risikosystem der Bank ebenfalls in den Ledger-spezifischen (z.B. HGB und IFRS) Zielwertstandard überführt (RDL). Auch hier bietet SAP FPSL eine eigene Berechnungslogik an.

7. Die Marktdaten (Wechselkurse) werden direkt an SAP FPSL geschickt, sodass eine vorherige Datenkonsolidierung hierfür nicht benötigt wurde. Eine schematische Darstellung obiger Schritte ist in Abbildung 6 zu sehen.

Abbildung 6 – Anbindung von Loan IQ an SAP FPSL (Datenfluss)

In der Datentransformation ist eine Logik zur Versionierung von Verträgen und Zielwerten implementiert. Dadurch kann sichergestellt werden, dass Änderungen in den Verträgen und den Zielwerten nach SAP FPSL überführt werden, sodass SAP FPSL auf diese Änderungen reagieren kann. So adjustiert SAP FPSL bei der Änderung der Zinsforderung den bereits gebuchten Zinsbetrag um die Änderung im Zielwert. Geschäftsvorfälle, die auf den Transkationen in Loan IQ basieren, haben keine Versionierung und dürfen als Ereignis nur einmal gebucht werden.

Testaufwand

Der Testumfang ist abhängig von der gewählten Migrationsstrategie, der Komplexität des zu migrierenden Portfolios, dem implementierten General Ledger und der Anzahl, der an SAP FPSL anzubindenden Vorsysteme. Auch ist beim Entwickeln einer Teststrategie zu eruieren, wer und in welchem Umfang die Daten nachgelagert verwendet und inwiefern diese Datenendnutzer in einen integrativen Test mit eingebunden werden müssen.

Wichtig ist, dass für die in SAP FPSL gebuchten Produkte sämtliche Buchungssachverhalte geprüft werden, damit sichergestellt wird, dass im Produktionsbetrieb alle Geschäftsvorfälle korrekt gebucht werden. Da dieses Testen sehr umfangreich ist, sollte in Erwägung gezogen werden, den Test zu automatisieren. Dadurch können alle Buchungsszenarien ressourcenschonend nachgestellt werden. Um genauere Informationen zum Thema Testautomatisierung mit der Software Tricentis Tosca zu erhalten, bietet sich folgender Artikel an: https://www.finbridge.de/aktuelles/2021/7/27/smarter-mit-tosca

Im Rahmen des Tests sollte auch die Migration inkl. Jahresabschlusssimulation getestet werden. Hierdurch wird sichergestellt, dass Beim Go-Live auch die Eröffnungsbilanz in SAP FPSL richtig ist und das komplette Bestandsgeschäft in SAP FPSL korrekt eingebucht wird.

Sollte genügend Zeit im Projekt bestehen, ist ein Parallelbetrieb (“parallel run”) von SAP FPSL und dem alten Subledger zu empfehlen. Hierdurch kann sichergestellt werden, ob die Buchungen in SAP FPSL und dem Altsystem konsistent sind. Eventuelle Abweichungen können in dieser Phase analysiert und die Ursache der Abweichung -falls notwendig- behoben werden.

Initialisierung von SAP FPSL

Bei der Initialisierung von SAP FPSL spielt die Migrationsstrategie eine ausschlaggebende Rolle, denn diese kann größere Auswirkungen auf den Umfang des Projekts und die hierfür zur Verfügung stehenden internen Mitarbeiterkapazitäten und technischen Ressourcen haben. Insbesondere die Wahl des Migrationsdatums ist hier von großer Relevanz. Hierdurch wird festgelegt, ob es sich um eine unterjährige Migration handelt oder ob zum Jahresultimo migriert werden soll.

Eine Migration zum Jahresultimo (Abschlussstichtag) ist dabei aus vielerlei Hinsicht empfehlenswert, auch wenn die benötigten Ressourcen aufgrund des anstehenden Jahresabschlusses oftmals nicht zur Verfügung stehen. Der große Vorteil einer Migration zum Abschlussstichtag besteht darin, dass durch den Abschluss des Geschäftsjahres im Altsystem keine Gewinne oder Verluste migriert werden müssen. Zudem gibt es im Regelfall kaum Abgrenzungsperioden über den Jahresultimo hinweg. Somit können auch komplexere Sachverhalte, wie z.B. der Umgang mit Stückzinsen, großteils vermieden werden. Eine reine Bestandsmigration ist demnach ausreichend.

Im Falle einer unterjährigen Migration ist die GuV der Vorperioden zu migrieren. Dies kann sowohl den Arbeitsaufwand als auch die Komplexität der Migration nach SAP FPSL erhöhen und zusätzliche Migrationseffekte erzeugen (z.B. bei GuV in Fremdwährung durch die Konvertierung gem. IAS 21 oder Stückzinsen).

Insgesamt gilt, dass durch die Einführung von SAP FPSL der Finanzabschluss ergebnisgleich sein sollte, potenzielle Änderungen (Migrationseffekte) müssen erklärbar sein. Die Sicherstellung der Ergebnisgleichheit sollte durch die Erstellung von zwei parallelen Abschlüssen erfolgen (Alt vs. Neu). Eine Migration von Stammdaten ist möglich, jedoch können keine vorherigen Abschlüsse migriert werden. Hier ist eine Initialisierung des SAP FPSL notwendig (z.B. von Classic AFI nach SAP FPSL).

Prozessschritte in SAP FPSL

Die nach erfolgreicher Einführung von SAP FPSL durchgeführten Prozessschritte am Monatsultimo können vereinfacht wie folgt dargestellt und beschrieben werden:

Der Prozess „Classify“ stößt eine Umgliederung der Nebenbuchsalden auf Vertragsebene an, sobald aus dem Vorsystem geänderte Stammdaten angeliefert werden und diese einen Einfluss auf die Ableitungsregel bei der Kontenfindung haben.

Da der Prozess „Classify“ im Falle einer Umgliederung einen Einfluss auf alle folgenden Prozesse hat, ist er in Abbildung 7 links über alle Prozessschritte hinweg dargestellt.

Im Prozess „Value FX“ werden die mit IAS 21 im Einklang stehende Bestandskontenbewertung, Fremdwährungsbewertung und Währungs-umrechnung vorgenommen. Diese Umrechnung ist sowohl auf Vertragsbasis als auch auf Buchungsdimensionsbasis durchführbar. Durch die Multi-Currency Funktionalität können die aufgeführten Bewertungen sowohl für die Heimwährung (Home Currency) als auch für eine davon abweichende Konzernwährung (Group Currency) eingerichtet werden.

Finbridge als Partner für die Einführung und Initialisierung von SAP FPSL

Als langjähriger, verlässlicher Partner bei fachlichen Umsetzungsprojekten bringen wir unsere Kompetenzen auf breiter Basis für die Analyse, Umsetzung und Begleitung Ihrer Projekte mit.

Als Partner für die Implementierung von SAP FPSL begleiten wir Sie während der gesamten Projektphase. Wir unterstützen Sie gerne in der Planungsphase bei der Analyse der Vorsysteme, begleiten die Architekturentscheidung und unterstützen Sie bis hin zur Umsetzungsphase. Über den gesamten Projektablauf hinweg bieten wir Hilfestellung in Fragen der Datenanlieferung, -transformation und in Fragen der fachlichen und technischen Umsetzung von Accounting-Anforderungen. Auch bei der Systemkonfiguration von SAP FPSL unterstützen wir Sie gerne. Darüber hinaus unterstützen wir Sie bei den technischen und fachlichen Tests sowie bei der Entwicklung einer Migrationsstrategie. Selbstverständlich begleiten wir Sie auch bei der operativen Migration während des Go-Lives und unterstützen Sie gerne bei etwaigen Problemstellungen nach dem erfolgten Go-Live.

Folgende Punkte zeichnen Finbridge als Implementierungspartner*in von SAP-Produkten, wie SAP FPSL, aus:

· Fachliche und technische Umsetzungen zur Einführung von SAP FPSL wurden bereits erfolgreich abgeschlossen. Wir greifen auf Erfahrungen zurück und können flexibel auf Kundenwünsche eingehen. Eine gesamtheitliche Betrachtung von regulatorischen und bilanziellen Fragestellungen unter Berücksichtigung der IT-Struktur ist für uns selbstverständlich.

· Als Fachberatung beobachten wir kontinuierlich Entwicklungen in der internationalen Rechnungslegung. Wir können sowohl auf operative Erfahrung im Bereich Rechnungswesen als auch auf Umsetzungserfahrung umfangreicher Standards, wie z.B. IFRS 9, IFRS 16 oder IFRS 15, zurückgreifen. Auch in Belangen der lokalen Gesetzgebung (HGB/UGB) können unsere Berater*innen mit fundiertem Wissen unterstützen.

· Unsere Berater*innen sind erfahren in zahlreichen Bank- und Versicherungsanwendungen, sowie Datawarehouse-Applikationen (SAP ERP, SAP FI, SAP CML, SAP BCA, SAP BO, SAP BW, Finastra Fusion Loan IQ, Finastra Summit, …).

Unser Beratungsansatz fokussiert sich bei der Umsetzung auf die optimale Einbettung der automatisierten Analyse- und Prüfungstätigkeiten in ihre vorhandene Prozesslandschaft. Die Schulung interner Mitarbeiter*innen und eine bedarfsgerechte Anwendungsbetreuung sind für uns ebenso selbstverständlich wie ein kundenorientierter Lösungsansatz und die Umsetzung eventuell benötigter individueller Gestaltungen. Gerne unterstützen wir Sie darüber hinaus im Projekteinsatz und/oder dem regelmäßigen Betrieb.

Wir hoffen, Ihr Interesse an unserer Beratung geweckt zu haben und freuen uns auf Ihre Kontaktaufnahme!

Quellen und Referenzen

[1] Bank for International Settlements/Basel Committee on Banking Supervision (2020, April): Progress in adopting the Principles for effective risk data aggregation and risk reporting. URL: https://www.bis.org/bcbs/publ/d501.pdf [30.09.2021]

[2] Eine in-memory Datenbank ist ein Datenbankmanagementsystem, das den Hauptspeicher (Arbeitsspeicher) als Datenspeicher nutzt. Herkömmliche Datenbankmanagementsysteme speichern die Daten ausschließlich auf der Festplatte, sodass diese bei jeder Abfrage von dort gelesen werde müssen.