Wenn die Fakturierung scheitert, lohnt sich ein Blick auf den Business Partner: eine technische Spurensuche durch die SD-Stammdaten

Die meisten Artikel über Fakturierungsfehler bleiben auf der Ebene von „Verbessern Sie Ihre Datenqualität“. Dieser Rat ist richtig, aber funktional nicht besonders hilfreich. Wenn Sie in einer SAP-SD-Landschaft arbeiten, möchten Sie wissen, welche Daten in welchem Objekt typischerweise welchen Schritt im Fakturierungsprozess stören, denn genau auf dieser Ebene können Sie handeln. Die These bleibt: Ein grosser Teil dessen, was Fakturierungsteams als Fakturierungsfehler behandeln, sind eigentlich Business-Partner-Fehler, die bereits bei der Anlage der Stammdaten entstanden sind und unsichtbar blieben, bis die Fakturierung die erste Transaktion war, die alle relevanten Felder gleichzeitig genutzt hat.

Das Symptom, technisch betrachtet

Die wiederkehrenden Fehler lassen sich meist in einige Gruppen einteilen:

• Der Fakturabeleg existiert, aber der FI-Folgebeleg fehlt, sodass der Umsatz nirgends gebucht wird.
• Rechnungen werden mit der falschen Ausgangssteuer gebucht oder scheitern an einem Fehler zwischen Steuerkennzeichen und Sachkonto.
• Rechnungen werden gegen den falschen Regulierer erstellt, sodass Zahlungsbedingungen und Mahnwesen in den Folgeprozessen falsch sind.
• Es entstehen Fakturasplits, die nicht auftreten sollten, und damit mehrere Rechnungen, obwohl der Kunde eine einzige erwartet.
• Rechnungen erreichen den Kunden nicht, weil die Output-Ermittlung nicht ausgelöst wurde.

Jeder dieser Fälle wird in der Regel als eigenes Ticket behandelt, obwohl vergleichsweise wenige davon ihren Ursprung tatsächlich in der Fakturierungskonfiguration haben.

Die Quelle: Der Business Partner ist das eine Objekt, auf das all diese Prozesse zugreifen

In S/4HANA gibt es keinen unabhängigen Kundenstamm mehr, der isoliert „falsch“ sein kann. Der Business Partner ist der Kundenstamm. BUT000 ist die führende Tabelle, und die klassischen Kundentabellen KNA1, KNB1 und KNVV werden vom System mit ihr synchron gehalten. Die alten Transaktionen zur Kundenanlage sind nicht mehr so relevant. Der Datensatz entsteht in der Transaktion BP beziehungsweise in der App „Maintain Business Partner“, und das, worauf SD und FI später zugreifen, ist eine Projektion davon, wie dieser BP eingerichtet wurde.

Was den BP zur gemeinsamen Ursache der oben genannten Fehler macht, ist, dass jede Entscheidung im Fakturierungsprozess auf einen anderen Aspekt davon zugreift und diese Aspekte über Rollen gesteuert werden. Grob gesagt enthält die FI-Kundenrolle die buchungskreisbezogenen Daten wie Abstimmkonto, Zahlungsbedingungen und Mahnwesen. Die Vertriebskundenrolle enthält die Vertriebsbereichsdaten wie Verkaufsorganisation, Vertriebsweg und Sparte, die Preisfindung, Statistik- und Kontierungsgruppen sowie die Partnerfunktionen. Ein Auftraggeber, der in Aufträgen verwendet wird, benötigt normalerweise beide Rollen.

Das führt zu einem der häufigsten strukturellen Fehler: Ein BP hat die FI-Rolle, wurde aber nie um die Vertriebsrolle für den relevanten Vertriebsbereich erweitert. In S/4HANA steuert die Rolle weitgehend auch die Feldauswahl, also welche Felder Pflichtfelder, optional oder ausgeblendet sind. Wenn eine Rolle nicht zugewiesen ist, waren die Felder, auf die die Fakturierung später angewiesen ist, bei der Anlage möglicherweise schlicht nicht vorhanden. Aufgrund der Rollenzuordnung waren sie nie Pflichtfelder. Der zugrunde liegende Prozessfehler besteht darin, dass der BP häufig reaktiv angelegt wird, um einen Auftrag freizugeben. Die Vollständigkeit, die die Fakturierung benötigt, wird bei der Stammdatenanlage nicht erzwungen, weil die Person, die den BP anlegt, nicht dieselbe Person ist, die Wochen später feststellt, dass eine Vertriebsbereichserweiterung fehlt.

Die Auswirkungen auf die Daten, Aspekt für Aspekt

Verfolgt man jedes Symptom bis zu dem Aspekt zurück, auf den es zugreift, wird das Muster konkreter.

Partnerfunktionen und Regulierer

Die zentralen SD-Partnerfunktionen Auftraggeber, Warenempfänger, Rechnungsempfänger und Regulierer werden standardmäßig aus den Partnerdaten des Kunden auf Vertriebsbereichsebene übernommen und über die Partnerfindung in jedes Dokument kopiert. Die Fakturierung verwendet den Regulierer für Zahlungsbedingungen und Mahnwesen und den Rechnungsempfänger für den Rechnungsversand.

Wenn die Partnerfunktionen so eingerichtet wurden, dass standardmäßig ein Regulierer gezogen wird, der eigentlich nicht vorgesehen ist, kann jeder Auftrag für diesen Kunden den falschen Regulierer in die Folgeprozesse übernehmen. Sichtbar wird das häufig erst dann, wenn jemand hinterfragt, warum die Zahlungsbedingungen oder das Mahnwesen falsch sind. Technisch ist in diesem Fall nichts fehlgeschlagen; die Stammdaten haben dem System genau diese Konstellation vorgegeben.

Steuerklassifikation

Die Ausgangssteuer auf der Rechnung wird über die Steuerkondition ermittelt. Dabei wird die Steuerklassifikation des Kunden zusammen mit der des Materials berücksichtigt. Ist die Steuerklassifikation des Kunden falsch oder fehlt sie, was bei neu angelegten BPs und bei migrierten Datensätzen häufig vorkommt, kann die Ermittlung den falschen Steuersatz liefern oder überhaupt keine gültige Steuerkondition finden.

Das zeigt sich in der Fakturierung als falscher Mehrwertsteuerbetrag oder, wenn das resultierende Steuerkennzeichen keine verwendbare Sachkontenzuordnung hat, als Fehler, der den FI-Beleg blockiert. Für den Anwender sieht es dann so aus, als hätte die Fakturierung die Steuer falsch berechnet, obwohl die Ursache häufig in der Steuerklassifikation des BP liegt.

Übergabe an die Finanzbuchhaltung

Das ist in der Regel einer der teuersten Fehler, weil der Umsatz überhaupt nicht gebucht wird. Wenn ein Fakturabeleg gespeichert wird und die Fakturaart nicht so eingestellt ist, dass die Buchung gesperrt wird, versucht das System, den FI-Beleg zu erzeugen. Dieser Schritt hängt davon ab, dass die Kontenfindung für jede relevante Kondition ein Sachkonto bestimmen kann.

Zu den Eingaben für diese Ermittlung gehören stammdatenabhängige Felder wie die Kontierungsgruppen von Kunde und Material. Wenn eines dieser Felder fehlt oder falsch ist, kann die Erlöskondition ihr Konto nicht finden, die Buchhaltungsschnittstelle läuft auf einen Fehler und der Fakturabeleg bleibt ungebucht. Für Praktiker ist dabei besonders hilfreich, dass die in die Fakturierung integrierte Kontenfindungsanalyse bei einer festhängenden Rechnung zeigt, welche Kondition kein Konto finden konnte. Die Ursache lässt sich dadurch häufig bis zu einem Stammdatenfeld zurückverfolgen und liegt nicht zwangsläufig in einer fehlerhaften Konfiguration.

Der Migrationseffekt

All diese Probleme treten in konvertierten Systemen häufig noch deutlicher auf. Die Customer Vendor Integration (CVI) hält den Business Partner und die klassischen Kunden- und Lieferantentabellen synchron, und ihre Qualitätsanforderungen sind streng. Genau deshalb erzwingt eine Brownfield-Konvertierung eine Bereinigung der Stammdaten, bevor sie abgeschlossen werden kann.

Wenn diese Bereinigung jedoch nur bis zu dem Mindeststandard durchgeführt wird, der notwendig ist, um die Migration technisch zu bestehen, statt bis zu dem Standard, den die Fakturierung tatsächlich benötigt, kann man in S/4HANA mit BPs ankommen, die technisch gültig, aber funktional unvollständig sind: Rollen wurden nicht auf alle benötigten Vertriebsbereiche erweitert, Partnerfunktionen wurden nicht sauber übernommen, Verknüpfungen zwischen dem BP und den zugrunde liegenden Kundendatensätzen sind nicht vollständig konsistent, oder durch parallele Nummernkreise wurden Dubletten erzeugt.

Der erste Geschäftsprozess, der all diese Punkte systematisch nutzt, ist häufig die Fakturierung. Das ist einer der Gründe, warum der Nacharbeitsaufwand im Billing nach einem Go-live so häufig ansteigt und dann als Problem der Fakturierungskonfiguration interpretiert wird, obwohl es eigentlich ein Problem der Migrationsvollständigkeit ist.

Der BP bündelt dabei viele relevante Stammdatenaspekte in einem gemeinsamen Objekt. Ein falsches Feld führt anfangs nicht zwingend zu einem sichtbaren Fehler, sondern wird korrekt und unbemerkt in jedes Dokument weitergegeben, das auf diesen Aspekt zugreift. Dadurch wird der Fehler häufig erst weit entfernt von seinem Entstehungsort sichtbar. Wenn Rechnungen dann einzeln korrigiert werden, wird jeweils nur das Ergebnis angepasst, während der zugrunde liegende Stammdatensatz weiterhin neue fehlerhafte Belege erzeugen kann.

Die Lösung: Validierung dorthin verschieben, wo der Datensatz entsteht

Die Massnahme ergibt sich direkt daraus: Die Fehlererkennung muss weiter nach vorne im Prozess verlagert werden, von der Fakturierung, wo Fehler spät und jeweils auf Belegebene sichtbar werden, hin zur Anlage und Änderung des BP, wo die Ursache direkt im Stammdatensatz geprüft werden kann.

Die erste Ebene ist Governance an der Quelle. Der BP sollte erst dann nutzbar sein, wenn die Aspekte, auf die die Fakturierung angewiesen ist, vollständig und intern konsistent sind: die erforderlichen Rollen für jeden Vertriebsbereich, in dem der Kunde Transaktionen durchführen wird; bewusst gepflegte Partnerfunktionen statt bloßer Standardwerte; eine gültige Steuerklassifikation; gepflegte Buchungskreis- und Kontierungsfelder; sowie konsistente Zahlungsbedingungen zwischen den auftragsrelevanten Daten und dem Regulierer.

Vieles davon ist weniger ein Technologieproblem als eine Frage der Prozessgestaltung. Der BP muss als gesteuertes Objekt mit klarer Verantwortlichkeit behandelt werden, unterstützt durch Feldstatus, Validierung und einen definierten Anlage- und Erweiterungsprozess. Damit wird die Datenqualität nicht erst dann geprüft, wenn eine Rechnung bereits davon abhängt.

Die zweite Ebene ist die proaktive Erkennung, denn Governance für neu angelegte Daten bereinigt nicht automatisch den bestehenden Datenbestand. Anstatt fehlerhafte Partner jeweils erst über eine fehlgeschlagene Rechnung zu entdecken, sollte der BP-Bestand kontinuierlich analysiert und auf unvollständige, inkonsistente oder doppelte Datensätze geprüft werden, bevor sie die Fakturierung erreichen.

In unserer Arbeit bedeutet das typischerweise, die relevanten Business-Partner-Daten, Rollen, Partnerfunktionen, Steuerklassifikationen und Kontierungsfelder aus SAP nach Azure zu extrahieren, sie in einer Data-Quality-Sicht zu modellieren und regelmässig zu aktualisieren. Dadurch kann ein fehlerhafter BP bereits am Tag seiner Anlage erkannt werden und nicht erst Wochen später über eine festhängende Rechnung. Dieselbe Sicht zeigt außerdem, welche Datensätze überproportional viel Nacharbeit verursachen, sodass die Bereinigung gezielt auf die zugrunde liegenden Stammdaten ausgerichtet werden kann und nicht nur auf die einzelnen Rechnungen, die daraus entstehen.

Die Diagnose

Das lässt sich auch ohne eigenes Projekt abschätzen. Nehmen Sie einen Monat an Fakturierungsfehlern: ungebuchte Belege, Steuerfehler, Gutschriften wegen falscher Mehrwertsteuer sowie Streitfälle zu Regulierer und Zahlungsbedingungen. Verfolgen Sie jeden einzelnen Fall zurück, führen Sie bei den festhängenden Belegen die Kontenfindungsanalyse durch und verfolgen Sie Regulierer- und Steuerfelder bis zum BP zurück.

Ordnen Sie die Fälle anschließend als „Billing/Konfiguration“ oder „Stammdaten“ ein. Viele Teams haben diese Klassifizierung bislang nicht systematisch vorgenommen. Sie liefert eine konkrete Grundlage dafür, zu beurteilen, welcher Anteil der Fehler tatsächlich aus der Fakturierung selbst stammt und welcher bereits im Business Partner angelegt wurde.

So arbeiten wir bei Conactive SAP-Probleme auf: Wir verfolgen das sichtbare Symptom zurück bis zu dem Prozess und den Stammdaten, die es verursachen, und setzen die Korrektur dort an, wo die Ursache entsteht. Bei Fakturierungsfehlern bedeutet das insbesondere, systematisch zu prüfen, wie häufig Business-Partner-Daten an der Fehlerentstehung beteiligt sind und an welchen Stellen im Anlage-, Änderungs- oder Migrationsprozess diese Daten besser validiert werden müssen.