E-Rechnung in SAP: Was tun, wenn eine Fehlermeldung alles blockiert?

2 Ausbaustufen

erst die Fehleranalyse im SAP DRC, dann euer eigenes Wissen im System

Was passiert, während die Rechnung liegen bleibt

Eine Fehlermeldung fühlt sich zunächst wie ein technisches Ärgernis an. Betriebswirtschaftlich ist sie das nicht. Bei einer Ausgangsrechnung beginnt die Zahlungsfrist in der Regel erst, wenn die Rechnung beim Empfänger zugegangen ist. Solange sie in deinem System hängt, läuft dein Zahlungsziel nicht. Zwei Tage Fehlerbearbeitung sind damit schlicht zwei Tage später Geld. Bei hohen Belegzahlen summiert sich das zu einem Betrag, den niemand als Kostenstelle sieht, weil er nirgendwo gebucht wird.

Bei einer Eingangsrechnung dreht sich die Logik um. Der Zugang zählt ab dem Zeitpunkt, an dem die Rechnung bei dir angekommen ist, nicht ab dem Zeitpunkt, an dem dein System sie erfolgreich verarbeitet hat. Verzögert sich die interne Bearbeitung, schützt dich das nicht vor Skontofristen. Skonto, das durch Bearbeitungsstau verfällt, ist der wahrscheinlich am besten dokumentierte und am schlechtesten überwachte Verlust im Rechnungswesen.

In Ländern mit Clearance-Pflicht kommt eine dritte Ebene dazu. Wenn eine staatliche Plattform ablehnt, gilt die Rechnung in der Regel nicht als ordnungsgemäß gestellt. Der Fehler blockiert dann nicht nur einen Prozessschritt, sondern die Rechnung selbst.

Deshalb lohnt sich eine Frage, die selten gestellt wird: Was kostet euch ein durchschnittlicher Fehlerfall eigentlich, gerechnet in Bearbeitungszeit, verzögertem Zahlungseingang und entgangenem Skonto? Sobald diese Zahl auf dem Tisch liegt, wird die Diskussion über eine bessere Fehleranalyse deutlich kürzer.

Warum derselbe Fehler immer wiederkommt

Die meisten Fehlermeldungen sind keine Überraschung. Sie sind das Ergebnis einer Entscheidung, die viel früher getroffen wurde.

Wenn regelmäßig die Umsatzsteuer-ID fehlt, liegt das nicht am Rechnungsprozess, sondern am Anlageprozess für Geschäftspartner. Wenn Zahlungsbedingungen nicht durchkommen, fehlt meist eine Pflichtfeldregel im Stammdatensatz. Wenn ein Steuercode falsch gemappt ist, betrifft das nicht einen Beleg, sondern alle Belege dieser Konstellation.

Deshalb ist die interessante Kennzahl nicht, wie schnell ihr Fehler behebt. Sie lautet: Wie viele eurer Fehler sind Wiederholungstäter?

Um das zu beantworten, braucht es nicht viel. Es reicht, über drei Monate mitzuschreiben, welcher Fehlertyp wie oft auftritt und bei welchen Geschäftspartnern. In fast jedem Unternehmen zeigt sich dabei dasselbe Muster: Eine Handvoll Ursachen erzeugt den Großteil der Fälle. Wer diese fünf Ursachen abstellt, reduziert das Aufkommen deutlicher als jede Beschleunigung der Einzelbearbeitung.

Besonders auffällig wird das bei neuen Geschäftspartnern. Der erste Beleg an einen neuen Kunden ist überproportional häufig fehlerhaft, weil sich Konfigurationslücken erst dort zeigen. Ein kurzer Testlauf beim Onboarding kostet zehn Minuten und verhindert Fälle, die später unter Zeitdruck bearbeitet werden.

Empfang oder Versand: der Unterschied ist größer als gedacht

In Projekten werden beide Richtungen gern zusammen betrachtet. Operativ haben sie fast nichts gemeinsam.

Beim Empfang liegt der Fehler bei jemand anderem. Deine Aufgabe ist Erkennen und Reagieren: die Rechnung ablehnen oder annehmen, den Lieferanten informieren, den Vorgang dokumentieren. Der Aufwand ist Kommunikationsaufwand. Kritisch wird es, wenn nicht dokumentiert ist, dass ihr abgelehnt habt und warum.

Beim Versand liegt der Fehler bei euch. Hier hängt euer Geld, eure Frist und in manchen Ländern die Gültigkeit der Rechnung. Der Aufwand ist Korrekturaufwand, und er ist zeitkritisch.

Aus dieser Unterscheidung folgt eine praktische Konsequenz für die Organisation. Eingangsfehler kann eine Person sammeln und gebündelt abarbeiten. Ausgangsfehler brauchen eine tägliche Sichtung mit klarer Vertretungsregelung. Wer beides in denselben Topf wirft, priorisiert am Ende falsch.

Was dazu im Whitepaper steht

Die Punkte oben sind das Umfeld. Das Whitepaper geht in die Fälle selbst.

Darin siehst du echte Meldungen aus SAP mit Screenshots, dazu die Erklärung, was jeweils wirklich dahintersteckt. Es zeigt die Fragen, mit denen du einen Fehler sauber lokalisierst, bevor du über die Behebung entscheidest. Und es beschreibt, wie eine Fehleranalyse aufgebaut ist, die direkt im SAP DRC läuft, technische Meldungen in Klartext übersetzt und die Korrektur aus der Meldung heraus anstößt.

Dazu ein Ausblick darauf, wie sich das Wissen aus vergangenen Fällen im System halten lässt, statt in Tickets und Köpfen zu verschwinden.

FAQ - Häufige Fragen

Über den Autor Florian Quaß

Produktmanager SAP E-Rechnungen und Full-Stack-Entwickler im SAP Umfeld

Florian Quaß ist ein begeisterter Full Stack Entwickler mit Erfahrung in diversen Programmiersprachen sowie im UI/UX Bereich. Ihn motiviert die Umsetzung und Optimierung von Kundenbedürfnissen mit modernen Technologien.