Herausforderungen und Vorgehen bei IT-Prüfungen von Banken

Transformationen der IT-Unterstützung im Rechnungswesen

I. Vorgehen bei IT-Prüfungen

[i]Geißler, infoCenter, Digitaler Datenzugriff NWB XAAAB-26807
Philipps/Wilting, Die GoBD in der Abschlussprüfung – Implikationen und erste Anwendungserfahrungen, WP Praxis 5/2016 S. 119 NWB XAAAF-71131
Hossenfelder, Die digitale Transformation wirkt sich auf Portfolio und Organisation aus – Lünendonk®-Studie 2016: Wirtschaftsprüfungs- und Steuerberatungs-Gesellschaften in Deutschland, WP Praxis 12/2016 S. 313 NWB WAAAF-86492 Der Abschlussprüfer hat das IT-gestützte Rechnungslegungssystem daraufhin zu beurteilen, ob es den gesetzlichen Anforderungen – insbesondere den in IDW ERS FAIT 1 dargestellten Ordnungsmäßigkeits- und Sicherheitsanforderungen – entspricht, um die nach § 322 Abs. 1 Satz 1 i. V. mit § 317 Abs. 1 Satz 1 HGB und § 321 Abs. 2 Satz 2 HGB geforderten Prüfungsaussagen über die Ordnungsmäßigkeit der Buchführung treffen zu können. [1]

Die Prüfungsaufträge lassen sich im Wesentlichen in drei unterschiedliche Anwendungsgebiete unterteilen (siehe Übersicht 1), die im Folgenden erläutert werden:

S. 431. Abschlussprüfung bei Einsatz von Informationstechnologie

Ziel einer IT-Systemprüfung ist es, Kenntnisse über den IT-gestützten Rechnungslegungsprozess des Unternehmens zu erhalten, wobei vor allem die Ordnungsmäßigkeit der Buchführung (z. B. Schnittstellenproblematik zwischen Hauptbuch und Nebenbüchern) sowie die Erfüllung der Sicherheitsanforderungen im Mittelpunkt der Betrachtung stehen. Darüber hinaus soll die Prüfung Aufschluss darüber geben, ob das IT-System wesentliche Fehler enthält, die Auswirkungen auf den Rechnungslegungsprozess (Buchführung, Jahresabschluss und Lagebericht) und die GoB haben. [2]

Die IT-Systemprüfung stellt eine Systemprüfung i. S. des IDW PS 261 dar und ist somit integraler Bestandteil der Prüfung des internen Kontrollsystems der Gesellschaft. Neben der Prüfung durch den Abschlussprüfer ist es Aufgabe der Unternehmensleitung, die IT-Strategie festzulegen und deren Umsetzung zu kontrollieren. Des Weiteren kann die Beurteilung des IT-Systems auch durch die Interne Revision oder einen Sachverständigen erfolgen. Die Prüfung selbst lässt sich in drei Bestandteile zerlegen: [3]

• Die Aufnahme des IT-Systems dient der Erlangung eines Grundverständnisses und eines Gesamtüberblicks über den IT-gestützten Rechnungslegungsprozess, die eingesetzte Software sowie die IT-Architektur. Die erlangten Informationen bilden die Basis für die nachfolgende Aufbau- und Funktionsprüfung.

• Mit der Aufbauprüfung beurteilt der Abschlussprüfer, ob das IT-Kontrollsystem unter Berücksichtigung der prüffeldspezifischen inhärenten Risiken angemessen und im geplanten Umfang wirksam ist.

• Zur Beurteilung der Wirksamkeit und Angemessenheit der eingerichteten IT-Kontrollen werden in der Folge Funktions- bzw. Ablaufprüfungshandlungen durch den Abschlussprüfer vorgenommen. Daraus lässt sich erkennen, ob die IT-Kontrollen zur Begrenzung der IT-Fehlerrisiken beitragen.

Im Rahmen der Aufbau- und Funktionsprüfung werden u. a. das IT-Umfeld und die IT-Organisation auf Basis der IT-Strategie und des IT-Sicherheitskonzepts sowie der Richtlinien und Arbeitsanweisungen geprüft. Die fixierten Verfahren und Abläufe werden dabei mit der tatsächlichen Umsetzung in der Praxis verglichen. Weiterhin ist die IT-Infrastruktur Gegenstand der Prüfungshandlungen. Hierbei geht u. a. um elektronische Zugriffskontrollen, physische Sicherheitsmaßnahmen, Maßnahmen für den Regel- und Notfallbetrieb sowie Organisation der Datensicherung und Auslagerungsverfahren. [4]

Ebenfalls von hoher Bedeutung ist die Prüfung der IT-Anwendungen, da hier die Erfüllung der verfahrensbezogenen Anforderungen der GoB umgesetzt wird. Dazu gehören des Weiteren die Anforderungen an die rechnungslegungsrelevanten Verarbeitungsregeln sowie die Softwaresicherheit. Für die Prüfung der IT-Anwendung ist es erforderlich, dass die Gesellschaft eine Verfahrensdokumentation aufgestellt hat. Diese Dokumentation ist ständig zu aktualisieren und hat vollständig zu sein. Durch den Abgleich des Soll-Zustands aus der Dokumentation mit der tatsächlichen Handhabung im täglichen Umgang können Übereinstimmungen bzw. Abweichungen festgestellt und es kann auf Risiken geschlossen werden. Der Aufbauprüfung schließt sich erneut ein Funktionstest an, bei dem beispielhafte Geschäftsvorfälle durchlaufen werden. [5]

Grundsätzlich besteht die Prüfung der IT-Anwendung aus

• der Prüfung der Programmfunktion, um Aussagen über die Angemessenheit und Funktionsfähigkeit der Programmfunktionen sowie der im Programm enthaltenen IT-Kontrollen zur Sicherstellung der Einhaltung der GoB treffen zu können, [6]

• der Prüfung der Organisation von Auswahl-, Entwicklungs- und Änderungsprozessen, d. h. wie sind die Richtlinien bei Erweiterungen der IT, bei Updates usw. geregelt, [7]

• der Prüfung von Implementierungen im Fall der Einführung von rechnungslegungsrelevanter Software einschließlich unternehmensindividueller Anpassungen von Standardsoftware an die Erfordernisse des Unternehmens. [8]

Abzugrenzen von der Prüfung von IT-Anwendungen ist die Prüfung von Softwareprodukten, die durch IDW PS 880 geregelt ist (vgl. Punkt I.3.). Weitere Prüffelder im Rahmen der Aufbau- und Funktionsprüfung nach IDW PS 330 sind:

• IT-gestützte Geschäftsprozesse: Bilden die IT-Geschäftsprozesse die Abläufe innerhalb des Unternehmens sachgerecht ab? Greifen die Prozesse innerhalb der IT ohne Daten- bzw. Informationsverluste lückenlos ineinander etc.? [9]

• IT-Überwachungssystem: Sind ausreichende und wirksame Kontrollschleifen installiert? Wie und durch wen werden IT-Kontrollen vorgenommen (eigene IT-Abteilung; Interne Revision oder externe Sachverständige)? [10]

• Prüfung des IT-Outsourcing: Sollte das Unternehmen Teile oder das ganze IT-System ausgelagert haben, ist zu klären, wie das Kontrollsystem gewährleistet wird. Kontrollen könnten hier beispielweise in dem Dienstleistungsunternehmen stattfinden, das einen Teil des IT-Systems für das zu prüfende Unternehmen übernommen hat, [11] oder die Kontrollen könnten weiterhin im Unternehmen selbst vorgenommen werden. [12] S. 44

Als Zwischenfazit lässt sich an dieser Stelle festhalten, dass der IDW PS 330 ein grundlegender Prüfungsstandard ist, der über die Abschlussprüfung hinaus (auch wenn seine Überschrift von Abschlussprüfungen spricht) Bedeutung hat. Bei Anpassungen oder Transformationen sind breite Teile der o. g. Bereiche und Aufgaben durch den Abschlussprüfer neu zu beurteilen. [13] Die Prüfung der Informationstechnologie sollte der Abschlussprüfung zeitlich vorgelagert sein, so dass insbesondere im Rahmen von Transformationsprozessen des IT-Systems umfassende Prüfungshandlungen vorgenommen werden sollten, um die möglichen Auswirkungen auf das Interne Kontrollsystem beurteilen zu können. Es kann sich aber auch anbieten, den Einsatz der Informationstechnologie im Rahmen eines Projekts zu beurteilen. [14]

2. Projektbegleitende Prüfung

Die projektbegleitende Prüfung ist Gegenstand des IDW PS 850. Anlässe einer projektbezogenen Prüfung können z. B. die Implementierung eines neuen IT-gestützten Rechnungslegungssystems, die Erweiterung des bestehenden IT-Systems, die Abbildung von Geschäftsprozessen in der IT, automatisierte Verfahrensabläufe (elektronische Verarbeitung von Rechnungen, „e-invoicing“) oder die Anpassung von Standardsoftware an die Besonderheiten und Erfordernisse des Unternehmens sein. [15] Durch diese Maßnahmen werden unter Umständen auch Veränderungen der IT-Infrastruktur (Anpassung an die technischen Erfordernisse) notwendig oder die IT-Projekte haben Einfluss auf den IT-gestützten Geschäftsprozess oder das IT-Kontrollsystem. Diese müssen im Zuge des Projekts ebenfalls angepasst werden.

Projekte werden in unterschiedliche Phasen unterteilt, die IDW PS 850 wie folgt benennt: [16]

Nicht alle Phasen müssen in jedem IT-Projekt durchlaufen werden. Die Art sowie die Komplexität des Projekts bestimmen, ob einzelne Phasen verkürzt oder komplett weggelassen werden können. Allerdings sollten in jeder Phase des Projekts Beurteilungen angestellt werden, welche Risiken mit der Veränderung einhergehen, und durch welche Kontrollen diesen begegnet werden kann. Die einzelnen Phasen können dementsprechend durch unterschiedliche Prüfungshandlungen begleitet werden. Neben der Internen Revision und einem externen Sachverständigen kann es auch sinnvoll sein, den Abschlussprüfer oder einen anderen Prüfer zu Rate zu ziehen.

Die projektbegleitende Prüfung sollte in einem ausreichenden Maße dokumentiert werden. Dabei empfiehlt es sich, die gewonnenen Erkenntnisse über das IT-System und die Projektorganisation in einem Prüfungsbericht zusammenzufassen. Die einzelnen Prüfungshandlungen und -schritte sollen in den Arbeitspapieren des Prüfers nachzuvollziehen sein. [17]

3. Prüfung von Softwareprodukten

Die Prüfung von Softwareprodukten erfolgt im Allgemeinen getrennt von der Prüfung des IT-Systems des Unternehmens, obwohl es im weiteren Sinne Bestandteil dessen ist. Die Prüfung umfasst dabei sowohl selbst erstellte Produkte als auch von fremden Dritten bezogene Software. [18] Dabei erfassen die Softwareprüfungen neben den Standardsoftwareprodukten eines Softwareherstellers auch individuell erstellte Softwarelösungen. Zentrale Bestandteile der Prüfung sind

• die Gewinnung eines Verständnisses über die Software,

• die Beurteilung des Softwareentwicklungsverfahrens,

• die Angemessenheit der Programmfunktionen und

• die Funktionsfähigkeit der Programmfunktion. [19]

Über die Prüfung, die oftmals beim Produzenten der Software selbst erfolgt, erstellt der Prüfer einen Prüfungsbericht, der mit einer Softwarebescheinigung endet. Im Fall von Erweiterungen oder Änderungen einer Software kann eine Folgeprüfung erforderlich sein, die auf den Ergebnissen und Feststellungen der ersten Prüfung aufbaut. Je nach Umfang der vorgenommenen Änderungen ist die Folgeprüfung entsprechend mehr oder weniger umfangreich. [20]

II. Risiken der Transformation

1. Charakterisierung der Transformation

Banken lassen sich im Hinblick auf ihr Geschäftsmodell in eine Vielzahl von Typen unterscheiden: Universalbanken bzw. reine Geschäftsbanken, Landesbanken, Sparkassen/Genossenschaftsbanken, Direktbanken und Spezialbanken wie Autobanken.

In diesem Artikel steht die Universalbank im Fokus, da bei ihr aufgrund der Breite der Geschäftstätigkeit die betrachtete Transformationsproblematik am deutlichsten ausgeprägt ist. Die Aktivitäten einer Bank lassen sich grob in die Bereiche Vertrieb, Steuerung und Produktion aufteilen. [21] Nachfolgende Übersicht visualisiert aufbauend auf dieser gedanklichen Unterteilung in drei Teilbanken für Vertrieb, Steuerung und Produktion die typische Unternehmensarchitektur einer Geschäftsbank und soll nachfolgend der genaueren Charakterisierung der Transformation dienen. [22] S. 45

In der Vertriebsbank wird der Kundenkontakt hergestellt und die Kundenbeziehung über die unterschiedlichen Vertriebskanäle gepflegt. Im Vertrieb von Banken hat sich ein Multikanalansatz etabliert, der die nahtlose Kundeninteraktion online, über Call-Center oder in Filialen ermöglicht. Die Produktionsbank ist verantwortlich für die Entwicklung und operative Abwicklung der Bankprodukte. In einer Bank bildet die IT die Produkte nicht nur ab, sondern die Produkte selbst sind reine IT-Artefakte. Darüber hinaus ist festzuhalten, dass sich die verschiedenen Bankprodukte wie Konten, Darlehen oder Derivate sowohl im Hinblick auf ihre Abwicklungsprozesse als auch auf ihre notwendige IT-Unterstützung wesentlich unterscheiden.

Das Rechnungswesen ist Teil der Steuerungsbank bzw. der Banksteuerung, zu der auch das Risikomanagement sowie das Controlling gehört. Die Verarbeitung der Steuerungsinformationen erfolgt in drei Stufen. Idealerweise werden die steuerungsrelevanten Informationen aus den operativen Systemen in integrierter Form abgelegt und bewirtschaftet (Ebene I.). [23] Auf Basis dieser Information erfolgt dann die Weiterverarbeitung, also die GoB-konforme Buchung im Rechnungswesen (Ebene II.). Auf der Ebene III. werden weitergehende Analysen oder Darstellungen erzeugt. Im Rechnungswesen erfolgt zudem die branchenspezifische Gliederung von Bilanzpositionen nach Fristigkeit im Anhang. [24]

Über die sich ergebenden Verarbeitungsebenen I.–III. der Steuerungsbank sowie der Produktionsbank spannt sich die vertikale Integrationsdimension. Die Integration über unterschiedliche Produktbereiche wird mit horizontaler Integration beschrieben. [25] Charakteristisch für die Steuerungsfunktion in der Bankenindustrie ist die Dichte der regulatorischen Vorgaben, die sich aus der besonderen Bedeutung der Kreditwirtschaft für die Gesamtwirtschaft ergeben.

Ein IT-Transformationsprojekt im Rechnungswesen zeichnet sich durch folgende Faktoren aus und grenzt sich dadurch von „gewöhnlichen“ IT-Vorhaben ab:

• Ausgangspunkt ist eine grundlegende Erneuerung eines zentralen Systems zur IT-Unterstützung im Rechnungswesen in der Steuerungsbank in den Ebenen I., II. oder III.

• Durch die hohe Integration der einzelnen Ebenen in der Steuerungsbank sowie zwischen dem Rechnungswesen und anderen Fachbereichen (Risikomanagement, Controlling) ist sich ergebender Anpassungsbedarf auf die anderen Prozesse der Banksteuerung zu identifizieren und abzufangen.

• Dies ist mit einer Änderung der Datenanlieferung in Granularität/Qualität und ggf. auch Periodizität verbunden, womit direkt die operativen bestandsführenden Systeme (Ebene IV.) betroffen sind.

• Diese strahlt in der vertikalen Integration auf die Produktionsbank ab und führt dort zu Anpassungen in der Abwicklung von Geschäftsprozessen und ihrer IT-Unterstützung in großer Breite (horizontale Integration).

Zusammenfassend ist die hier betrachtete Transformation charakterisiert durch den Ausgangspunkt einer Modernisierung in der Steuerungsfunktion, die die Bank weitreichend sowohl in horizontaler als auch vertikaler Dimension erfasst. Vor dem Hintergrund der großen Unterschiede bei den betroffenen Bankprodukten sowie der hohen Regelungsdichte in den Banksteuerungsprozessen ergibt sich der für diesen Transformationstyp charakteristische Komplexitätsgrad.

2. Besonderheiten der Bankbilanzierung

Die grundsätzlich vollumfänglich gültigen handelsrechtlichen Vorschriften werden für Banken und Kreditinstitute ergänzt durch branchenspezifische Vorgaben aus § 340 bis § 340o HGB. Neben diesen materiellen Vorgaben sind die formellen Vorschriften der Verordnung über die Rechnungslegung der Kreditinstitute und Finanzdienstleistungsinstitute (RechKredV) anzuwenden, in denen spezifische Formblätter für die Abschlusserstellung vorgegeben sind. Die Unterschiede in der Bankbilanzierung zu Industrie- und Handelsunternehmen liegen sowohl im Ansatz, in der Gliederung als auch in der Bewertung von Bilanzpositionen. Diese werden nachfolgend grob skizziert und in ihren Auswirkungen auf Prozess und IT-Unterstützung dargestellt.

Im Bilanzierungsansatz ist das Verrechnungsverbot von Aktiv- und Passiv- bzw. Gewinn- und Verlustpositionen nach § 246 Abs. 2 HGB für Kreditinstitute nicht anzuwenden, soweit abweichende Vorschriften bestehen. [26] Des Weiteren bestehen spezifische Vorschriften zur Bilanzierung von Pensions- und Wertpapierleihgeschäften. [27] Sowohl bei Pensionsgeschäften als auch bei Wertpapierleihgeschäften beziehen sich die Regelungen auf Fragestellungen des Bilanzierungsansatzes beim Leiher bzw. Entleiher von Wertpapieren bzw. Pensionsgegenständen und den sich hierdurch ergebenden bilanzpolitischen Spielraum. Für den Prozess der Transformation sind insbesondere solche spezifischen Vorschriften von S. 46Bedeutung, die die Angabe von Geschäften unterhalb der Bilanz betreffen. Durch den Ausweis von Eventualverbindlichkeiten, z. B. Garantien oder Bürgschaften, werden Verpflichtungen der Institute dokumentiert, die zum Bilanzstichtag bereits eingegangen wurden, aber nicht bilanzierbar sind. [28] Auch schwebende Geschäfte, zu denen u. a. Termingeschäfte und unwiderrufliche Kreditzusagen zählen, sind unterhalb der Bilanz anzugeben. Durch diese Anforderungen ergibt sich ein hoher zusätzlicher Aufwand – ergänzend zum bilanziellen Hauptbuch sind umfangreiche Nebenbuchkonten zu halten. So müssen beispielsweise Zins-Swap-Geschäfte des Handelsbestands seit Inkrafttreten des BilMoG zum beizulegenden Zeitwert bilanziert werden. Wenn dieses Derivat zu marktgerechten Konditionen abgeschlossen wurde, ist der Zeitwert null und eine Bilanzierung somit nicht notwendig. Trotzdem müssen zu diesem Finanzinstrument alle Details der zugrunde liegenden Grundgeschäfte beider Vertragsparteien vorgehalten werden, damit zu Bilanzstichtagen eine Ermittlung des Zeitwerts möglich ist und bei einem Wert ungleich null die Aufnahme in die Bilanz erfolgt. [29]

Laut Scharf/Schaber wird im „Gliederungsschema der Bilanz für Institute [...] im Gegensatz zum Gliederungsschema für Nichtinstitute (§ 266 HGB) keine formale Trennung zwischen Anlage- und Umlaufvermögen vorgenommen.“ [30] Institute sind durch § 340a Abs. 2 HGB von den Vorschriften des § 266 HGB sowie insbesondere des § 247 Abs. 1 HGB befreit. Die Gliederung der Bilanz von Instituten erfolgt insbesondere unter dem Blickwinkel eines verbesserten Einblicks in die Liquiditätslage. [31] Das nach § 2 Abs. 1 Satz 1 RechKredV für die Bilanz von Instituten zu verwendende Gliederungsschema bringt dieses Anliegen zum Ausdruck. [32] Des Weiteren sind nach § 9 RechKredV für definierte Bilanzposten Anhangsangaben zu erstellen, in denen diese Posten nach der Restlaufzeit gegliedert werden müssen. [33] Für die Bestimmung der Frist sind für die unterschiedlichen Positionen spezifische Vorschriften anzuwenden. Durch diese Anforderungen ergibt sich ein erweiterter Informationsbedarf in den Bilanzierungssystemen. Aus den operativen Systemen müssen alle Merkmale zu Finanzinstrumenten erfasst und an das Bilanzierungssystem angeliefert werden, die notwendig sind, um die ordnungsgemäße Einordnung in Bilanz bzw. Anhang zu ermöglichen. Beispielsweise müssen bei Kündigungsgeldern die Kündigungsfristen erfasst und über die Schichten der Architektur angeliefert werden, da diese Kündigungsfristen bei ungekündigten Kündigungsgeldern maßgeblich für die Ermittlung der Restlaufzeiten sind.

Bei der Bewertung gilt das Prinzip der Einzelbewertung nach § 252 Abs. 1 Nr. 3 HGB. § 265 Abs. 7 HGB zur Zusammenfassung bestimmter Posten der Bilanz sowie GuV sind für Institute gem. § 340a Abs. 2 Satz 1 HGB ersatzlos nicht anzuwenden. Bei der Bilanzierung von Finanzinstrumenten sind gem. § 254 HGB zu Vermögensgegenständen, Schulden, schwebenden Geschäften oder mit hoher Wahrscheinlichkeit erwarteten Transaktionen, zu denen zum Zweck der Absicherung gegen Wertänderungs- und Zahlungsstromrisiken derivative Finanzinstrumente eingesetzt werden, in der Bilanz Bewertungseinheiten zu bilden. Eine weitere Besonderheit in der Bankbilanzierung ist die Durchbrechung des Realisationsprinzips durch die erfolgswirksame Marktwertbewertung von Wertpapieren des Handelsbestands (§ 340e Abs. 3 Satz 1 HGB). Hierdurch können auch Wertansätze bilanziert werden, die über den Anschaffungskosten liegen. [34] Marktwerte von Wertpapieren des Handelsbestands sind um einen Risikoabschlag zu reduzieren. Durch die Marktwertbewertung und die Nutzung von Bewertungseinheiten finden die Strategien des Risikomanagements einer Bank zur Reduktion von Marktrisiken Berücksichtigung in der Bilanz.

Zusammenfassend lässt sich feststellen, dass sich aus den spezifischen Anforderungen der Bankbilanzierung ein sehr hoher Aufwand der Informationserfassung und Verarbeitung ergibt. Jedes einzelne Finanzinstrument muss in der Ebene in der Ebene I. der Banksteuerung mit einer Vielzahl von Informationen abgebildet werden, damit die notwendige Berechnung und Darstellung im Rechnungswesen erfolgen können. Dabei stellen sowohl die hohe Anzahl an Instrumenten, [35] die eine Bank bilanzieren muss, als auch die große Unterschiedlichkeit der Produkte einen Komplexitätstreiber dar.

Auf eine Darstellung der Besonderheiten der Bankbilanzierung nach IFRS wird im Rahmen dieses Beitrags verzichtet. Die Aussagen aus diesem Kapitel gelten für ein Institut, das nach IFRS bilanzieren muss, in verstärktem Maße. Dies liegt zum einen am zusätzlichen Aufwand für eine „doppelte“ Bilanzierung, zum anderen an den dem IFRS inhärenten Prinzipien, z. B. die Fair-Value Bewertung, die die vorgenannte Argumentation verstärken.

3. Spezifische Risiken der Transformation

Die Umsetzung aller für die Transformation notwendigen Änderungen an den Buchungs- und Informationsbereitstellungsabläufen über alle Produktkategorien und alle Architekturebenen (siehe Übersicht 2) stellt sowohl eine Herausforderung im Hinblick auf die technisch-fachliche Durchdringung als auch im Hinblick auf die Steuerung im Projektmanagement dar.

In der Praxis lassen sich folgende Risiken identifizieren:

1. unpräzise/unvollständige oder fehlerhafte Fach- und IT-Umsetzungskonzeptionen,

2. Verzögerung bei der Erstellung der Fach- und IT-Umsetzungskonzeptionen,

3. hohes Fehleraufkommen insbesondere bei fachlichen Tests,S. 47

4. mangelnde Transparenz im Projektmanagement über den Projektstatus mit dem Risiko, das falsche Steuerungsimpulse gesetzt werden.

Zu 1. und 2.: Zur Verdeutlichung soll das Beispiel einer Transformation betrachtet werden, bei der die operativen Buchungen im Derivate-Nebenbuch zukünftig nicht mehr direkt in der integrierten Buchhaltung des Handelssystems, sondern für jede Buchung auf Einzelgeschäftsebene im zentralen Buchungssystem bzw. Hauptbuch vorgenommen werden sollen. Die Festlegung, welche Informationen und Attribute in welchem Format aus dem Handelssystem an das zentrale Buchhaltungssystem zu liefern sind, werden in einer adäquaten Zeitspanne nicht lücken- und fehlerfrei prozesskonform in Form von Konzepten dokumentiert werden können. Die Berücksichtigung der technischen Besonderheiten der Quell- und Zielsysteme sowie aller buchhalterischen Sonderfälle, z. B. rückwirkende Änderungen bei upfront payments im Rahmen von Zinstauschgeschäften (SWAPS), und daraus resultierende Änderungen bei der Periodisierung der Aufwände bzw. Erträge würden die Konzeptionsphase derart umfangreich machen, dass der Gesamtrahmen für Zeit- und Budget der Transformation gesprengt würde.

Aus diesen Herausforderungen in der Konzeptionsphase folgt ein erhöhtes Aufkommen von Fehlern im Fachtest (Punkt 3.), da sich einige Zusammenhänge erst bei genauer fachlicher Betrachtung der Buchungsabläufe und Ergebnisse im technisch funktionsfähigen System zeigen. Die Beurteilung des Projektfortschritts und die Fortschrittsprognose sowie das Setzen geeigneter Steuerungsimpulse sind in einem Umfeld mit so hoher Unschärfe nur begrenzt möglich (Punkt 4.).

Die beschriebenen Risiken für die Transformation erhöhen für den Prüfer das Prüfungsrisiko. Dem hohen inhärenten Risiko, dass aus der Komplexität der Buchungsvorgänge und der großen Anzahl der Sachverhalte resultiert, kann zwar mit Hilfe einer umfangreichen Prüfung des Internen Kontrollsystems (IKS) begegnet werden, insgesamt verbleibt für den Prüfer aber eine Restgröße im Entdeckungsrisiko. Es besteht das Risiko, dass die Auswirkungen auf das Buchhaltungssystem aus dem Projektverlauf nicht vollständig erkennbar sind.

III. Herausforderungen und Vorgehen

1. Prüfungsaktivitäten während Transformation

Übersicht 4 zeigt, welche Art von IT-Prüfungsaktivitäten in welcher Phase der Transformation stattfinden kann. Die Phasen der Transformation sind eine Vereinfachung der bereits in I.1.2 vorgestellten Projektphasen.

Eine Prüfung und ggf. Zertifizierung der zum Einsatz kommenden (Standard-)Softwarekomponenten kann nur in der vorbereitenden Definitionsphase stattfinden. Während der Konzeption und Umsetzung wird die projektbegleitende Prüfung durchgeführt. Zielsetzung hierbei ist die Überprüfung der Prozesskonformität im IKS. Von daher wird eine projektbegleitende Prüfung eher in den späteren Phasen der Transformation Anwendung finden, da hier alle Prozesse der Anforderungsdefinition und der Umsetzung aktiv sind und überprüft werden können.

Schließlich muss die obligatorische IT-Prüfung der operativen Abschlusserstellung zunächst im alten und dann – ab Go-Live – im neuen System erfolgen. Hier ist in aller Regel eine mehr oder minder lange Phase des Parallelbetriebs beider Systeme erforderlich, um eine sicheren und ordnungsgemäßen Übergang zu sichern. Der neue und der alte Abschluss müssen den normalen Abläufen der turnusmäßigen IT-Prüfung unterzogen werden.

2. Herausforderungen der Prüfung

Die Softwareprüfung nach PS 880 kann nur einen sehr eingeschränkten Beitrag zur Prüfung der Transformation leisten. Durch die breite Wirkung der Transformation auf die Gesamtarchitektur sowie die in den meisten Fällen umfänglich vorgenommen Anpassungen der Software lassen sich durch Zertifikate einzelner Softwareprodukte keine belastbaren Aussagen für das Gesamtsystem ableiten.

Eine projektbegleitende Prüfung nach PS 850 ist jedoch im Zuge einer Transformation geboten. Fokus hierbei ist die Überprüfung der korrekten Funktionsweise des IKS und hier im Speziellen der IT-Entwicklungsprozesse. Die Überprüfung dieser Prozesse im Einzelnen wird möglich sein, allerdings bildet sich, wie in II.2. dargelegt, ein erhöhtes Prüfungsrisiko. Dieses Risiko belastet die IT-Prüfung beim Übergang in das neue System.

Beim Übergang zum neuen System muss dem Stetigkeitsprinzip folgend der neue Abschluss aus dem alten Abschluss erklärbar sein. Der Prüfer muss in der Lage sein, jede Abweichung zwischen altem und neuem Abschluss nachzuvollziehen. Auch nach durchgeführter projektbegleitender Prüfung ist in der Praxis die Wahrscheinlichkeit hoch, dass sich viele Bilanzpositionen zwischen altem und neuem System unterscheiden. Ursachen hierfür können sein:

• fehlerhafte Verarbeitung im neuen System (auch bei Durchführung umfangreicher Tests),

• gewünschte Veränderung aufgrund der nun durch die Transformation möglichen Ausübung von Wahlrechten S. 48bei Bewertungsmethoden, z. B. bei der Ermittlung von Marktwerten,

• erstmalige richtige Bilanzierung im neuen System in der Wertentwicklung oder im Ansatz.

Da sich nach den evtl. bereits vorliegenden Prüfungsaussagen nach A und B die Ursachen für festgestellte Abweichungen nicht erklären lassen, ist eine nahezu vollumfängliche Prüfung und ein Abgleich aller Bilanz- bzw. GuV-Positionen notwendig. Auch die Gleichheit von Positionen auf Summenebene kann bei vorliegenden Abweichungen nicht als Indikator für die Regelkonformität des Systems angenommen werden, da diese rein zufällig sein können. Alle Werte müssen auf der Ebene des einzelnen Finanzinstruments abgeglichen werden.

3. Strategien zum Vorgehen in der Praxis

3.1 Reduktion der Komplexität der Transformation

Die aufgezeigten Problemstellungen resultieren aus der Komplexität dieser Transformation, genauer: aus der Änderung der Buchungsabläufe sowohl horizontal als auch vertikal über mehrere Ebenen. Insofern ist es naheliegend, die Transformation auf eine eindimensionale Problemstellung zu reduzieren, z. B. im sequenziellen Wechsel der einzelnen Produktsysteme auf das neue Rechnungslegungssystem.

Bei einer Entscheidung für ein sequenzielles Vorgehen gegenüber einem Big-Bang-Ansatz, in dem alle Produkte zur selben Zeit den Systemwechsel vollziehen, ist eine Vielzahl von Faktoren zu betrachten, wie etwa das Budget und die Gesamtvorhabenplanung der Bank, die hier nicht in ausreichender Tiefe besprochen werden können. Es soll nur darauf hingewiesen werden, dass bei einer Sequenzialisierung andere Problemstellungen für den Prüfer entstehen, nämlich die nachvollziehbare Zusammenführung des Gesamtabschlusses aus unterschiedlich prozessierten Teilbilanzen.

3.2 Optimierung des Vorgehens in der Projektphase

Ein anderer Ansatz zielt darauf ab, die Möglichkeiten der projektbegleitenden Prüfung zu optimieren. Dies würde auf eine intensivere Begleitung der Transformation über alle Projektphasen mit einem gegenüber einer reinen Prozessprüfung des IKS erweiterten Fokus hinauslaufen. Betroffen wäre hier beispielsweise die Definition der Testfälle für die fachlichen Tests, bei denen der Prüfer einbezogen wird, um einen möglichst großen Bezug zu den für die Bilanz dieser Bank relevanten Sachverhalten herzustellen. Dies erfolgt idealerweise in Form produktbezogener Teams, in denen sowohl IT- als auch Fachexperten mit dem Prüfer zusammenarbeiten.

3.3 Erweiterung der Prüfung

Auch wenn schon in frühen Phasen der Transformation Aktivitäten auf die spätere IT-Prüfung beim Systemwechsel abzielen, wird eine intensive Prüfung des Abschlusses aus dem neuen System sowie ein Abgleich zwischen altem und neuem System notwendig sein. Insofern ist es ratsam, sich schon von Beginn an auf diesen Umstand einzustellen, ein möglichst effektives Vorgehen abzustimmen und die notwendigen Ressourcen einzuplanen. Die beiden Abschlüsse müssen stets systematisch auf Unterschiede analysiert werden. Kritischer Erfolgsfaktor ist die Geschwindigkeit der Analyse eventueller Abweichungen. Durch Clusterung von ähnlichen Fehlerkategorien, z. B. Dateneingabe- oder Berechnungsfehler etc., kann hier Geschwindigkeit gewonnen werden.

IV. Zusammenfassung

Bei Transformationen der IT-Systeme im Rechnungswesen von Banken stellt die Übernahme und Prüfung des neuen Jahresabschlusses die letzte große und in der Planung oftmals vernachlässigte Hürde dar. Es besteht ein nicht unerhebliches Restrisiko, dass der Prüfer im Zuge der Abwägung seines Prüfungsurteils im Kontext der vorliegenden Prüfungsrisiken zum „Zünglein an der Waage“ wird, das die geplante Übernahme und den erfolgreichen Abschluss der Transformation verhindert bzw. verschiebt. Insbesondere wird der Abschlussprüfer die Ordnungsmäßigkeit der Buchprüfung verneinen, wenn er den Übergang und die Unterschiede zwischen altem und neuem Abschluss nicht erklären bzw. nachvollziehen kann. Um das Risiko hierfür zu reduzieren, sollte der Prüfer frühzeitig und breit in das Projekt eingebunden werden. Der Prüfer selbst ändert dadurch seine grundsätzliche Rolle nicht, sondern wird zu einem Begleiter des Transformationsprozesses. Dadurch erhält der Abschlussprüfer das hier benötigte besondere Verständnis vom IKS und dem Rechnungslegungssystem, was sich final in der Qualität des Prüfungsurteils widerspiegeln wird.