Auditfeste Datenmigration: was der Wirtschaftsprüfer sehen will

Eine Datenmigration ist kein reines IT-Projekt: Mit den offenen Posten wandern Bilanzwerte ins neue System. Dieser Beitrag zeigt, welche Nachweise Wirtschaftsprüfer erwarten, was regulatorisch ab Tag eins funktionieren muss und wie ein Validierungs-Framework beides absichert.

Warum die Migration den Jahresabschluss berührt

Wer Forderungen, Zahlungen und Sicherheiten aus dem Altsystem übernimmt, migriert keine „Daten", sondern Bilanzpositionen. Die offenen Posten im Vertragskontokorrent (FI-CA, das Massenkontokorrent von SAP IS-U) gehen als Forderungsbestand in die Eröffnungswerte des neuen Systems ein. Stimmt die Summe nicht, stimmt der Abschluss nicht.

Damit gelten für die Migration dieselben Maßstäbe wie für die Buchführung selbst: Nachvollziehbarkeit, Vollständigkeit, Richtigkeit, also die Grundsätze, die auch die GoBD an digitale Prozesse anlegt. Der Wirtschaftsprüfer wird die Migration als prüfungsrelevanten Vorgang behandeln und Nachweise verlangen, dass zwischen Alt- und Neusystem nichts verloren ging, nichts doppelt entstand und nichts umgedeutet wurde. Wer diese Nachweise erst nach dem Go-live zusammensucht, hat verloren.

Was der Prüfer konkret sehen will

Die Erwartungsliste ist über Mandate hinweg erstaunlich stabil. Fünf Nachweise stehen praktisch immer darauf:

• Lückenlose Protokolle je Lauf. Für jeden Migrationslauf: wann, welcher Datenstand, welche Objekte, wie viele Sätze gelesen, geladen, abgewiesen, inklusive Begründung der Abweisungen. Ein „der Testlauf zählt nicht" gibt es nicht; auch verworfene Läufe gehören dokumentiert.
• Vor-/Nach-/Delta-Mengenabstimmung. Je Migrationsobjekt die Kette: Anzahl Quelle, Anzahl Ziel, Differenz. Für jede Differenz gehört eine Erklärung dazu (bereinigte Karteileichen, bewusst ausgeschlossene Testdatensätze, Dubletten-Zusammenführung).
• Centgenaue Summenabstimmung der offenen Posten. Soll- und Habensalden alt gegen neu, je Belegart und in Summe: auf den Cent, nicht „ungefähr". Eine Restdifferenz von 3,17 Euro ist keine Rundung, sondern ein ungeklärter Befund.
• Nachvollziehbare Transformationsregeln. Jede Umschlüsselung (Belegarten, Steuerkennzeichen, Mahnstufen, Kontenfindung) muss als dokumentierte, versionierte Regel vorliegen. „Das hat das Skript gemacht" ist keine Antwort; die Frage lautet: nach welcher Regel, entschieden von wem, wann?
• Wiederholbarkeit. Gleicher Input, gleiche Regeln, gleiches Ergebnis. Der Produktivlauf darf kein Unikat sein, sondern die Wiederholung einer Generalprobe, deren Ergebnis bereits abgestimmt war.

Der rote Faden: Der Prüfer will nicht glauben müssen, dass die Migration korrekt war – er will es nachrechnen können.

Die regulatorische Seite: mehr als der Abschluss

Bei Energieversorgern kommt eine zweite Prüfebene dazu, die mit dem Jahresabschluss nichts zu tun hat und trotzdem keinen Aufschub duldet: die Marktprozesse.

Die Marktlokation (MaLo), die 11-stellige Kennung, unter der eine Lieferstelle im Markt bilanziert wird, muss die Migration nahtlos überstehen. Lücken oder Dubletten in den MaLo-Daten schlagen direkt auf die MaBiS durch, die Marktregeln zur Bilanzkreisabrechnung: Falsch bilanzierte Lokationen erzeugen Mehr-/Mindermengen-Streit und im Ernstfall Ärger mit der Bundesnetzagentur. Anders als ein interner Datenfehler ist das nach außen sichtbar, bei jedem Marktpartner, der die Lokation anfasst.

Genauso wenig verhandelbar ist die GPKE-Fähigkeit ab Tag eins: Lieferbeginn, Lieferende und Lieferantenwechsel laufen in gesetzlichen Fristen weiter, während migriert wird. Ein System, das nach dem Cutover erst „eingeschwungen" werden muss, produziert Fristverletzungen im Wechselprozess, und die warten nicht auf den Abschluss der Nacharbeiten. Wie man den Cutover zeitlich plant, behandelt der Beitrag Migration von SAP IS-U auf S/4HANA Utilities: Vorgehen & Zeitplan.

Praktische Bausteine: so entsteht Auditfestigkeit

Auditfestigkeit ist keine Dokumentationsübung am Ende, sondern eine Architekturentscheidung am Anfang. Drei Bausteine tragen sie:

1. Abnahmekriterien vorab definieren Bevor der erste Testlauf startet, steht schriftlich fest, was „bestanden" heißt: welche Mengendifferenzen erklärungspflichtig sind, welche Summen centgenau stimmen müssen, welche Stichproben die Fachbereiche ziehen. Kriterien, die erst nach dem Lauf entstehen, sind keine Kriterien, sondern Verhandlungsmasse.
2. Validierungs-Framework mit Prüfprotokollen Die Abstimmungen laufen nicht als Handarbeit in Tabellenkalkulationen, sondern als automatisierte Prüfstrecke, die je Lauf ein Protokoll erzeugt: Mengenketten je Objekt, Summenabgleich je Belegart, Konsistenzchecks (hat jeder Vertragspartner ein Vertragskonto, ist jede Zahlung einer Forderung zuordenbar, sind alle MaLo-Kennungen befüllt?). Das Protokoll entsteht als Nebenprodukt jedes Laufs, nicht als Sonderaufwand vor dem Prüfertermin. Warum solche Prüfungen auch rückwärts vom Zielsystem her laufen müssen, erklärt Stille Fehler in der Datenmigration.
3. Generalprobe unter Ernstbedingungen Mindestens ein Probelauf mit vollständigem Datenbestand, echten Regeln und echter Abstimmung, dessen Prüfprotokoll dem des Produktivlaufs bis auf den Zeitstempel gleicht. Erst diese Wiederholbarkeit macht aus einer Behauptung einen Nachweis.

Auditfest ist eine Migration dann, wenn der Nachweis ihrer Korrektheit als Nebenprodukt jedes Laufs entsteht – nicht als Fleißarbeit danach.

Wer so vorgeht, hat beim Prüfertermin keine Sonderschicht vor sich, sondern einen Ordner, der ohnehin existiert. Und er hat nebenbei das Steuerungsinstrument, das jede Migration braucht: belastbare Zahlen je Lauf statt Bauchgefühl. Welche technischen Werkzeuge SAP dafür mitbringt, zeigt EMIGALL erklärt: die IS-U Migration Workbench in der Praxis.