Eine S/4HANA-Migration betrifft nahezu jeden Finanzprozess, aber Debitorenbuchhaltung und Kassenanwendung erhalten in der Regel weniger Planungsaufmerksamkeit als Hauptbuch und Reporting — teils weil AR in ECC „bereits funktioniert", teils weil es verlockend ist, die Migration als technischen Umzug statt als Gelegenheit zur Prozessneugestaltung zu behandeln. Das ist ein Fehler. Die Migration ist das beste Zeitfenster, das Sie bekommen werden, um AR-Prozessschulden zu beheben, die sich in der Regel über Jahre angesammelt haben.
Was sich unter S/4HANA in der Debitorenbuchhaltung tatsächlich ändert
Das Universal Journal von S/4HANA konsolidiert FI- und CO-Daten in einer einzigen Positionstabelle, und Fiori-basierte Apps ersetzen eine Reihe von Transaktionscodes, die AR-Teams seit Jahren verwenden. Speziell für die Kassenanwendung bedeutet dies in der Regel neue Buchungs- und Abgleichsoberflächen, Änderungen bei der Darstellung offener Posten und Ausgleiche sowie — für Gruppen, die Central Finance oder ähnliche Konsolidierungsansätze einführen — eine Phase, in der AR-Daten aus mehreren Quellsystemen in eine einzige S/4HANA-Instanz fließen können.
Die Lift-and-Shift-Falle
Der Weg des geringsten Widerstands bei jeder ERP-Migration besteht darin, die bestehende Prozesskonfiguration im neuen System exakt so zu replizieren wie im alten — dieselben Abgleichsregeln, dieselben manuellen Workarounds, dieselbe tabellenbasierte Ausnahmebehandlung, die sich um die Einschränkungen von ECC herum entwickelt hat. Das ist der schnellste Weg zum Go-live, und es ist auch die Art, wie ein Migrationsprojekt stillschweigend jedes Prozessproblem des alten Systems neu erschafft — nur auf neuerer Infrastruktur.
Wenn Ihr aktueller AR-Prozess auf manueller Neueingabe von Zahlungsavisen, einem tabellenbasierten Ausnahmeprotokoll oder einer nur nachts laufenden Batch-Datei-Integration beruht, bewahrt die Migration desselben Prozesses nach S/4HANA alle drei Einschränkungen. Das neue System führt sie schneller aus, behebt sie aber nicht.
Drei Dinge, die während der Migration überdacht werden sollten
- Abgleichsregeln. Dies ist der natürliche Zeitpunkt, um von einer reinen Exact-Match-Logik zu einem konfidenzbasierten Abgleich überzugehen, der einen deutlich höheren Anteil an Transaktionen automatisch klärt, statt dieselben starren Regeln in der neuen Umgebung neu zu konfigurieren.
- Ausnahme-Reporting. Die Ausnahmeverfolgung aus der ECC-Ära ist oft ein manueller Export nach Excel. Das Echtzeit-Datenmodell von S/4HANA eignet sich stattdessen natürlich für ein Live-Ausnahme-Dashboard — es lohnt sich, dieses einmal während der Migration zu bauen, statt es später nachzurüsten.
- Integrationsmuster. Wenn Ihr aktuelles Kassenanwendungstool über nächtliche Batch-Dateien mit ECC kommuniziert, ist die Migration der Moment, um stattdessen zu einer nativen Echtzeitintegration zu wechseln, anstatt das Batch-Muster in S/4HANA fortzuführen.
Die Abstimmung mit der Migration
Die Neugestaltung des AR-Prozesses muss nicht in derselben Phase wie die technische Umstellung erfolgen, aber sie sollte bewusst geplant werden statt standardmäßig. Teams, die das beste Ergebnis erzielen, validieren neue Abgleichslogik und Ausnahme-Workflows in der Regel parallel zur technischen S/4HANA-Migration, sodass der Go-live eine echte Verbesserung gegenüber dem ECC-Prozess darstellt und nicht nur ein Wechsel des Systems bei gleichbleibendem Prozess — wobei die Neugestaltungsarbeit für eine „Phase zwei" aufgehoben wird, die in der Praxis oft an Priorität verliert, sobald die technische Migration live ist und die Aufmerksamkeit sich verlagert.
Wo PayConnect in eine S/4HANA-Migration passt
PayConnect integriert sich nativ sowohl mit ECC als auch mit S/4HANA, was bedeutet, dass die Kassenanwendungsautomatisierung vor der Umstellung anhand Ihrer aktuellen ECC-Umgebung validiert und ohne ein zweites Implementierungsprojekt nach S/4HANA übertragen werden kann. Für Teams, die von einem batch-dateibasierten Kassenanwendungstool migrieren, ist dies in der Regel auch der Zeitpunkt, an dem sie zu einer Echtzeitintegration wechseln, statt das alte Batch-Muster im neuen System zu replizieren.
Das Fazit
Eine S/4HANA-Migration ist eine seltene Gelegenheit, AR-Prozessschulden gleichzeitig mit dem Wechsel der zugrunde liegenden technischen Plattform zu beheben. Sie rein als technischen Lift-and-Shift zu behandeln bedeutet, für ein Migrationsprojekt zu bezahlen, ohne die Prozessverbesserung zu erhalten, die für ungefähr denselben Aufwand verfügbar war.