Erkennen Sie SAP-Abrechnungsfehler vor jedem Abrechnungslauf und vermeiden Sie kostspielige Nachbesserungen nach der Abrechnung durch automatisierte Validierung mit Easy Validate.
Zusammenfassung • 6 Minuten Lesezeit
Fehler in der Lohnabrechnung machen sich selten bemerkbar. Es gibt keine Warnmeldung, keine fehlgeschlagene Transaktion, kein offensichtliches Anzeichen dafür, dass etwas schiefgelaufen ist. Ein gekündigter Mitarbeiter wird versehentlich in den nächsten Abrechnungslauf übernommen. Ein Replikationsfeld wird vor dem Stichtag nicht synchronisiert. Eine Lohnart wurde zwei Monate lang leicht falsch berechnet, und die Abweichung ist so gering, dass niemand darauf aufmerksam geworden ist.
Bis jemand den Fehler bemerkt, ist das Geld bereits überwiesen. Und die Behebung eines Fehlers in der Gehaltsabrechnung nach der Auszahlung kostet im Durchschnitt siebenmal so viel wie die Korrektur vor der Überweisung.
Was die Sache noch schlimmer macht, ist, dass keiner der unten aufgeführten Fehler ungewöhnlich ist. Sie sind nicht das Ergebnis seltener Systemausfälle oder ungewöhnlicher Konfigurationen. Es handelt sich um Fehler, die in SAP-Umgebungen aller Art immer wieder auftreten, weil die manuellen Prozesse, auf die sich die meisten Teams verlassen, nicht dafür ausgelegt sind, sie zuverlässig zu erkennen.
Das klingt nach etwas, das im Jahr 2025 eigentlich nicht mehr möglich sein sollte. Aber es kommt nach wie vor vor.
Ein Mitarbeiter scheidet aus. Die Personalabteilung wickelt die Kündigung ab, die Checkliste für das Offboarding wird abgearbeitet, die Abschiedskarte wird unterschrieben. Doch ein wiederkehrender Abzug wurde nicht deaktiviert, ein Infotyp nicht aktualisiert oder ein außerplanmäßiger Lauf nicht rechtzeitig bemerkt – und der nächste Abrechnungslauf wird durchgeführt, obwohl diese Person noch im Personalbestand geführt wird.
Für Teams, die SuccessFactors Employee Central mit Replikation in ECP nutzen, besteht ein zusätzliches Risiko. Eine in EC bearbeitete Kündigung bedeutet nicht automatisch, dass die Infotypen für die Personalabrechnung aktualisiert werden. Wenn die Replikation nicht korrekt abgeschlossen wird, kann der Mitarbeiter im Stammdatensystem gekündigt sein, für die Personalabrechnung jedoch weiterhin aktiv bleiben. Die beiden Systeme stimmen nicht überein, und die Personalabrechnung orientiert sich am falschen System.
Die Rückforderung einer Überzahlung von einem ehemaligen Mitarbeiter ist bestenfalls unangenehm. Je nachdem, wie viel Zeit vergangen ist und in welchem Rechtsraum Sie sich befinden, kann dies wirklich kompliziert sein. Eine Überprüfung vor der Gehaltsabrechnung erkennt dies, indem sie gekündigte Mitarbeiter in der aktiven Belegschaft vor dem Start des Abrechnungslaufs kennzeichnet – dann ist die Lösung eine zweiminütige Datenkorrektur statt eines schwierigen Gesprächs.
Wenn Employee Central als Stammdatensystem dient, folgt auf jeden Abrechnungszyklus ein Replikationsprozess, über den die meisten Abrechnungsteams kaum Einblick haben. Das ist kein Problem – solange es kein Problem ist.
Replikationsfehler treten häufiger auf, als die meisten Implementierungspartner zugeben. Eine Gehaltsänderung, die es nicht rechtzeitig vor dem Stichtag schafft. Bankdaten, die im falschen Format repliziert werden. Eine Änderung der Arbeitszeiten, die in einer Warteschlange hängt und erst im ECP landet, nachdem der Lauf bereits verarbeitet wurde. Das Abrechnungssystem berechnet anhand der Daten, die es hat, nicht anhand der Daten, die es haben sollte, und der Unterschied tritt oft erst zutage, wenn jemand die Ergebnisse ansieht und denkt, dass etwas nicht stimmt.
Das zeitliche Problem macht die Sache besonders frustrierend. Die Überprüfung der Replikation ist nur vor dem Lauf sinnvoll. Sobald die Verarbeitung abgeschlossen ist, muss man Korrekturen vornehmen. Aber EC-Sätze für Hunderte oder Tausende von Mitarbeitern vor jedem Abrechnungsstichtag manuell Feld für Feld mit den ECP-Infotypen abzugleichen – das ist unrealistisch. Daher führen die Teams Stichproben durch, lassen die Überprüfung ganz weg oder überprüfen die Daten erst im Nachhinein.
Ein automatisierter Abgleich über die gesamte replizierte Datenmenge vor jedem Zyklus verändert diese Situation. Unstimmigkeiten werden erkannt, solange noch Zeit bleibt, sie zu beheben.
Die Konfiguration der Personalabrechnung ändert sich ständig. Ein Unternehmensvertrag wird aktualisiert. Steuertabellen werden aktualisiert. Ein Support-Pack wird installiert. Jemand behebt ein seit langem bestehendes Berechnungsproblem im Schema. Jede Änderung wird bearbeitet, in gewissem Umfang getestet und in die Produktion übernommen. In einer komplexen SAP-Abrechnungsumgebung sind die Folgewirkungen einer Konfigurationsänderung jedoch nicht immer direkt aus der Änderung selbst ersichtlich.
Eine Konfigurationsabweichung entsteht, wenn sich diese Effekte summieren. Das System berechnet etwas, das geringfügig von den Sollwerten abweicht; die Abweichung ist irgendwann in der Vergangenheit entstanden, und da dies schrittweise geschah, gibt es keine offensichtlichen Anzeichen, die darauf hinweisen.
Das spezifische Problem bei der manuellen Abweichungsanalyse besteht darin, dass sie relativ ist. Man vergleicht den aktuellen Zyklus mit dem letzten Zyklus. Wenn sich eine Konfigurationsänderung auf alle Mitarbeiter in gleicher Weise auswirkt – beispielsweise eine Rentenberechnung, die bei allen um einen Prozentpunkt abweicht –, gibt es keine Abweichung festzustellen. Der Fehler ist einheitlich, was bedeutet, dass er unsichtbar ist.
Das gleiche Problem tritt auch bei Migrationen auf. Die Neuanpassung der Gehaltsabrechnungskonfiguration in einer neuen Umgebung (ECP, S/4HANA) bedeutet, dass Logik übersetzt werden muss, die oft über Jahre hinweg entwickelt und angepasst wurde. Ohne einen strukturierten Vorher-Nachher-Vergleich anhand einer realen Mitarbeitergruppe können Fehler in der neuen Konfiguration die parallelen Tests bestehen und in den Produktivbetrieb gelangen.
Nur durch szenariobasierte Tests, die vor und nach einer Änderung an derselben Mitarbeitergruppe durchgeführt werden und bei denen erwartete und unerwartete Abweichungen ausdrücklich dokumentiert werden, lässt sich dies tatsächlich erkennen. Nicht durch eine manuelle Überprüfung, ob die Ergebnisse „richtig aussehen“.
Jeder SAP-Abrechnungsspezialist weiß, dass die Genauigkeit der Abrechnung von der Genauigkeit der Stammdaten abhängt. Das ist eine dieser Tatsachen, über die sich alle einig sind, die aber in der Praxis nur schwer im Griff zu halten sind.
Stammdaten ändern sich schnell. Neue Mitarbeiter werden am Ende einer hektischen Woche in aller Eile angelegt. Jemand wechselt die Kostenstelle, doch die organisatorische Zuordnung wird erst aktualisiert, wenn die Gehaltsabrechnung bereits läuft. Eine Änderung der Bankverbindung wird übermittelt, erfüllt aber die Validierungsregeln nicht. Das sind keine ungewöhnlichen Vorkommnisse. In jedem einigermaßen aktiven Gehaltsabrechnungsbestand kommt so etwas in jedem Zyklus in der einen oder anderen Form vor.
Das Problem ist, dass Lücken in den Stammdaten nicht bereits bei der Eingabe zu Fehlern führen. Sie verursachen erst später Fehler, wenn die Personalabrechnung versucht, einen betroffenen Mitarbeiter zu verarbeiten, und dabei entweder stillschweigend scheitert oder falsche Berechnungen liefert. Ein neuer Mitarbeiter erhält in seiner ersten Woche kein Gehalt, weil die Zahlungsart nicht eingerichtet wurde. Ein Mitarbeiter wird einer Kostenstelle zugeordnet, die nicht mehr existiert. Ein Steuerdatensatz fehlt, weil niemand bemerkt hat, dass der Infotyp nicht gepflegt wurde.
Ein Scan vor der Abrechnung, der auf unvollständige oder ungültige Datensätze prüft – fehlende Infotypen, Kombinationen, die die Mindestanforderungen für einen erfolgreichen Lauf nicht erfüllen –, deckt diese vor der Verarbeitung auf, nicht erst danach.
Der Lauf ist abgeschlossen. Die Ergebnisse sehen gut aus. Die Bankdatei wird versendet, die Hauptbuchbuchung vorgenommen, und alle machen weiter. Was die meisten Teams nicht überprüfen – weil dies das Zusammenführen und Vergleichen von Daten aus mehreren Ausgabedateien erfordert –, ist, ob diese drei Zahlen tatsächlich übereinstimmen.
Gesamtsumme der Bankdatei. Bruttosumme des Lohn- und Gehaltsclusters. Buchungsbetrag im Hauptbuch. Bei einem fehlerfreien Durchlauf ohne manuelle Eingriffe sollten diese Werte identisch sein. In der Praxis gibt es jedoch oft irgendwo eine Abweichung – eine außerplanmäßige Zahlung, die in einer Ausgabe berücksichtigt wurde, in einer anderen jedoch nicht; eine manuelle Anpassung, die nicht überall berücksichtigt wurde; oder Rundungen, die sich über mehrere Perioden hinweg angesammelt haben. Einzeln betrachtet sind das Kleinigkeiten. In der Summe bedeuten sie jedoch, dass der Lohn- und Gehaltsprozess nicht vollständig abgeschlossen ist.
Diese Unstimmigkeiten treten meist am Monatsende auf, wenn die Finanzabteilung eine Hauptbuchabstimmung durchführt und sich etwas nicht aufschließen lässt. Zu diesem Zeitpunkt ist der Abrechnungszeitraum möglicherweise schon fast abgeschlossen, die Mitarbeiter der Lohnbuchhaltung haben bereits mit dem nächsten Zyklus begonnen, und die Rückverfolgung bis zur Ursache kostet Zeit, die niemand hat.
Eine Abgleichprüfung nach der Gehaltsabrechnung, bei der nach jedem Durchlauf alle drei Zahlen miteinander abgeglichen werden und etwaige Abweichungen vor Abschluss des Zeitraums gekennzeichnet werden, ist eine relativ einfache Kontrollmaßnahme. Es ist jedoch eine Maßnahme, die überraschend viele Teams nicht umgesetzt haben.
Technisch gesehen ist keine davon wirklich ungewöhnlich. Jeder erfahrene SAP-Abrechnungsspezialist, der dies liest, wird sie sofort wiedererkennen, wahrscheinlich aus eigener Erfahrung.
Sie treten immer wieder auf, weil es die Kapazitäten der meisten Teams übersteigt, sie manuell – für jeden Mitarbeiter, in jedem Zyklus und mit dokumentierten Nachweisen – aufzuspüren. Manuelle Validierung bedeutet Stichproben. Man prüft, wofür man Zeit hat, man entdeckt, wonach man Ausschau hält, und der Rest bleibt praktisch ungeprüft. Die oben genannten Fehler sind genau diejenigen, die durch diesen Prozess hindurchrutschen – nicht, weil sie versteckt sind, sondern weil der Prozess nicht darauf ausgelegt war, sie in großem Maßstab aufzuspüren.
Die praktische Lösung besteht in einer Validierung, die automatisch den gesamten Datenbestand abdeckt, Probleme aufzeigt, bevor sie zu Problemen nach der Zahlung werden, und den Untersuchungsverlauf speichert, damit die Teams nicht in jedem Zyklus wieder bei Null anfangen müssen.
Entwickelt für SAP-HCM- und SAP-SuccessFactors-Umgebungen.
Inhaltsverzeichnis
Easy Validate Sie Probleme bei der Lohn- und Gehaltsabrechnung erkennen, bevor sie sich auf die Abrechnungsläufe auswirken. Die für SAP HCM und SAP SuccessFactors entwickelte Lösung automatisiert die Validierung in jeder Phase und bietet einen lückenlosen Prüfpfad sowie eine lückenlose Historie der durchgeführten Überprüfungen.