Abrechnungsplattformen: wo Umsatz zwischen den Systemen verschwindet

Revenue Assurance ist die Kontrolle darüber, ob jede erbrachte Leistung tatsächlich zu einer Rechnung führt. Der Begriff wird häufig mit Rechnungsprüfung verwechselt, betrifft aber eine andere Frage: nicht ob die Rechnung stimmt, sondern ob sie überhaupt entstanden ist. In Abrechnungsplattformen, die Ereignisse aus mehreren Vorsystemen zusammenführen, verschwindet Umsatz fast nie im Rechnungslauf. Er verschwindet an den Übergängen davor, und dort sucht ihn selten jemand.

Der Unterschied zur Rechnungsprüfung

Eine Rechnungsprüfung nimmt eine erzeugte Rechnung und prüft sie gegen Vertrag, Tarif und Steuerlogik. Sie beantwortet die Frage, ob der ausgewiesene Betrag für die abgerechnete Leistung korrekt ist. Das ist notwendig und findet einen Teil der Fehler.

Sie findet einen anderen Teil systematisch nicht. Wenn eine Leistung erbracht, aber nie in die Abrechnungskette eingespeist wurde, gibt es keine Rechnungszeile, die auffallen könnte. Die erzeugte Rechnung ist formal einwandfrei. Sie ist nur zu klein. Kein Prüfschritt, der von der Rechnung ausgeht, kann etwas finden, das nicht auf ihr steht.

Revenue Assurance dreht die Richtung um. Sie geht vom Ereignis aus, nicht von der Rechnung, und verfolgt, was auf dem Weg passiert ist. Die Leitfrage lautet: Von hundert Ereignissen, die im Vorsystem entstanden sind, wie viele erscheinen am Ende auf einer Rechnung, und wo genau sind die übrigen geblieben.

Diese Umkehrung ist der ganze Punkt. Sie ist auch der Grund, warum Revenue Assurance nicht im Rechnungswesen entsteht, sondern in der Architektur der Abrechnungsplattform.

Wo die Verluste tatsächlich entstehen

In einer Abrechnungsplattform durchläuft ein Ereignis typischerweise vier bis sechs Stationen: Erfassung im operativen System, Übernahme in eine Sammelschicht, Anreicherung um Vertrags- und Kundendaten, Bewertung nach Tarif, Aggregation, Fakturierung. Jede Station hat eine eigene Fachlogik, oft ein eigenes Team, teilweise einen eigenen Betreiber.

Die Verluste konzentrieren sich nicht in diesen Stationen, sondern zwischen ihnen. Innerhalb eines Systems ist die Logik getestet und wird bei Änderungen erneut getestet. Zwischen zwei Systemen liegt eine Übergabe, für die sich im Zweifel beide Seiten für zuständig halten und keine Seite verantwortlich fühlt.

Die wiederkehrenden Muster:

• Stille Abbrüche in der Übernahme. Ein Satz erfüllt eine Formatbedingung nicht und wird verworfen. Er landet in einem Fehlerverzeichnis, das niemand regelmäßig ansieht, weil es die meiste Zeit leer ist. Nach einer Schnittstellenänderung ist es plötzlich nicht mehr leer.
• Zeitfenster, die nicht zusammenpassen. Das Vorsystem schließt den Tag um Mitternacht, die Abrechnung schneidet um 22 Uhr. Die zwei Stunden dazwischen laufen in den nächsten Zyklus, was zulässig ist, solange am Monatsende jemand den Übertrag prüft. Am Jahresende prüft ihn oft niemand.
• Nicht bewertbare Ereignisse. Ein Ereignis kommt vollständig an, aber die Bewertung findet keinen passenden Tarif, weil der Vertrag ein Merkmal trägt, das die Tariflogik nicht kennt. Der Satz bleibt in einer Warteschlange liegen, technisch korrekt, wirtschaftlich verloren.
• Doppelte Unterdrückung. Eine Duplikatserkennung, die zu weit greift, entfernt echte Wiederholungen. Bei Leistungen, die legitim mehrfach am Tag auftreten, ist das ein direkter Umsatzverlust, der als Qualitätsmaßnahme getarnt ist.

Keines dieser Muster erzeugt eine Störungsmeldung. Alle laufen still, und alle laufen so lange, bis jemand von der anderen Seite her zählt.

Der Abgleich, der tatsächlich etwas findet

Die übliche Kontrolle ist ein Summenabgleich: Das Vorsystem meldet eine Tagesmenge, die Abrechnung meldet eine Tagesmenge, beide werden verglichen. Das ist besser als nichts und deckt grobe Ausfälle auf.

Es hat zwei Schwächen. Erstens gleichen sich Fehler aus: Wenn an einer Stelle Sätze verloren gehen und an anderer Stelle Duplikate entstehen, stimmt die Summe wieder. Zweitens sagt eine Abweichung in der Summe nichts darüber, welche Sätze fehlen, also beginnt nach jedem Alarm eine manuelle Suche, die Tage dauert.

Was trägt, ist ein Abgleich auf Ebene der Einzelsätze mit einem stabilen Schlüssel. Jedes Ereignis bekommt bei der Erfassung eine Kennung, die es unverändert bis zur Rechnungszeile behält. An jedem Übergabepunkt wird nicht die Summe verglichen, sondern die Menge der Kennungen. Das Ergebnis ist keine Zahl, sondern eine Liste: diese Sätze sind an dieser Station eingegangen und dort nicht mehr aufgetaucht.

Aus dieser Liste folgt unmittelbar die Ursache, weil der Ort bekannt ist. Aus einer Summenabweichung folgt eine Untersuchung.

Drei Eigenschaften machen einen solchen Abgleich belastbar:

• Er läuft unabhängig von der Fachlogik. Wenn die Kontrolle dieselbe Bibliothek benutzt wie die Verarbeitung, teilt sie deren Fehler. Der Zähler muss ein eigener Pfad sein.
• Er läuft auf jedem Übergang, nicht nur am Anfang und Ende. Ein Abgleich zwischen Erfassung und Rechnung sagt, dass etwas fehlt. Ein Abgleich an jedem Übergang sagt, wo.
• Er hat eine Toleranz, die begründet ist. Es gibt legitime Differenzen, etwa durch Zeitfenster. Diese Differenzen müssen benannt und beziffert sein, sonst wird die Toleranz mit der Zeit zum Ablageort für echte Verluste.

Stammdaten sind die stillste Verlustquelle

Die bisher beschriebenen Fälle betreffen fehlende Sätze. Der teurere Fall ist der, bei dem alle Sätze ankommen und der Betrag trotzdem falsch ist.

Das passiert über Stammdaten. Ein Kunde wechselt in einen anderen Tarif, der Wechsel wird im Vertriebssystem gepflegt und nicht in der Abrechnung. Ein Rahmenvertrag bekommt eine neue Konditionsstufe, die für Neukunden greift und für Bestandskunden nachgepflegt werden müsste. Eine Leistung wird umbenannt, und die alte Bezeichnung bleibt in einer Zuordnungstabelle stehen, die seit Jahren niemand geöffnet hat.

In allen drei Fällen läuft die Kette technisch fehlerfrei. Jede Kontrolle, die Mengen zählt, meldet Grün. Die Rechnungen sehen korrekt aus, weil sie konsistent falsch sind. Solche Abweichungen bestehen typischerweise über Jahre und werden entdeckt, wenn ein Kunde sie bemerkt oder ein Wirtschaftsprüfer eine Stichprobe zieht.

Die Gegenmaßnahme ist keine Kontrolle in der Abrechnung, sondern Ordnung in den Stammdaten und ein definierter Weg, auf dem Änderungen die Abrechnung erreichen. Solange Tarif- und Vertragsdaten an mehreren Stellen unabhängig gepflegt werden, ist die Frage nicht, ob sie auseinanderlaufen, sondern wie weit. Wir haben das Vorgehen dazu im Artikel zum Stammdatenmanagement im Unternehmen beschrieben; die messbare Seite, also wie sich Abweichungen laufend sichtbar machen lassen, steht in Datenqualität im Unternehmen sicherstellen.

Die Schnittstelle zum ERP als eigener Prüfpunkt

Der letzte Übergang der Kette führt in die Finanzbuchhaltung, in DACH-Landschaften überwiegend nach SAP. Dieser Übergang verdient eine eigene Kontrolle, aus zwei Gründen.

Erstens ist er der Punkt, an dem aus einer Abrechnungsgröße eine Buchungsgröße wird. Ab hier gilt das Ergebnis als Umsatz, und Korrekturen sind nicht mehr nur technisch, sondern buchhalterisch relevant. Ein Verlust vor dieser Grenze lässt sich nachverarbeiten. Ein Verlust nach dieser Grenze wird zu einer Korrekturbuchung mit Erklärungsbedarf.

Zweitens ist dieser Übergang oft technisch am ältesten. Er ist in vielen Landschaften vor der übrigen Plattform entstanden, läuft über eine Strecke, die seit Jahren unverändert ist, und wird bei Änderungen an der Abrechnung selten mitgetestet. Genau diese Kombination aus Alter, Stabilität und Unauffälligkeit macht ihn zum Ort, an dem eine Änderung anderswo eine stille Wirkung entfaltet.

Wir behandeln SAP-Schnittstellen deshalb nicht als Transportstrecke, sondern als kontrollpflichtigen Übergang mit eigenem Mengenabgleich und eigener Abstimmung gegen das Hauptbuch. Die Frage, welches Integrationsmuster darunter liegen soll, ist eine Frage der Systemintegration geschäftskritischer Systeme.

Wer die Kontrolle betreibt, entscheidet über ihren Wert

Revenue Assurance scheitert in der Praxis häufiger an der Zuständigkeit als an der Technik.

Das Muster ist gleichbleibend. Die Aufgabe wird dem Team zugeordnet, das die Abrechnung betreibt. Damit misst dieses Team die Vollständigkeit des eigenen Prozesses und berichtet Abweichungen an einem Verfahren, das es selbst verantwortet. Niemand handelt dabei unredlich, aber die Anreizlage ist ungünstig, und das praktische Ergebnis ist, dass Zweifelsfälle regelmäßig in Richtung Toleranz aufgelöst werden.

Zwei Anordnungen vermeiden das. Die Messung läuft auf einem eigenen Pfad mit eigenem Eigentümer, üblicherweise im Controlling, und das Abrechnungsteam ist für die Behebung dessen zuständig, was die Messung meldet, nicht für die Messung selbst. Und die Kennzahl wird zusätzlich als absoluter Betrag berichtet. Ein Vollständigkeitsgrad von 99,4 Prozent liest sich gut. Derselbe Wert, ausgedrückt als Betrag der fehlenden 0,6 Prozent, führt zu einer anderen Diskussion, und es ist diese Diskussion, die eine Behebung finanziert.

Dazu kommt eine Frage der Taktung. Eine Kontrolle, die einmal im Monat läuft, findet einen Verlust im Mittel zwei Wochen nach seinem Eintritt. Bei einem Fehler, der aus einer Schnittstellenänderung stammt, sind das zwei Wochen fortlaufender Verlust und ein Zeitraum, in dem sich die Ursache schwerer rekonstruieren lässt, weil zwischenzeitlich weitere Änderungen erfolgt sind. Der tägliche Abgleich der Übergänge ist deutlich billiger als die nachträgliche Aufarbeitung eines Monats.

Welche Kennzahl den Zustand beschreibt

Die meisten Berichte zu Abrechnungsplattformen messen Verfügbarkeit, Durchsatz und Laufzeit. Diese Werte beschreiben Systeme. Sie beschreiben nicht, ob Umsatz vollständig ankommt.

Die Kennzahl, die das beschreibt, ist der Anteil der erfassten Ereignisse, der nachweislich bis zur Rechnungszeile durchläuft, gemessen über einen abgeschlossenen Zyklus und aufgeschlüsselt nach Übergang. Ein Wert von 99,4 Prozent klingt gut und ist bei hohen Mengen ein erheblicher Betrag, was genau der Grund ist, warum die Zahl absolut und nicht nur relativ berichtet werden sollte.

Dazu gehören zwei Ergänzungen: die Zeit bis zur Entdeckung einer Abweichung, und der Anteil der Abweichungen, deren Ursache benannt werden konnte. Eine Plattform, die Verluste zuverlässig findet, aber die Ursache in der Hälfte der Fälle nicht bestimmen kann, wird dieselben Verluste im nächsten Zyklus erneut haben.

Wenn die Ursache außerhalb der Abrechnung liegt

Ein erheblicher Teil dessen, was Revenue Assurance sichtbar macht, lässt sich in der Abrechnungsplattform nicht beheben, und eine Meldung als Abrechnungsfehler schickt die Arbeit an die falsche Stelle.

Sätze, die fehlerhaft, verspätet oder mit unbekannten Merkmalen ankommen, entstehen in der Erfassung oder in den kaufmännischen Vorsystemen. Die Abrechnung kann sie erkennen, aussteuern und melden. Sie kann nicht verhindern, dass sie erzeugt werden. Wenn die Berichterstattung nicht zwischen Fehlern der Abrechnung und Fehlern, die die Abrechnung lediglich beobachtet, unterscheidet, sammelt das Abrechnungsteam einen Rückstand an, für dessen Behebung es keine Zuständigkeit hat, und die verursachenden Systeme sehen die Kosten nie, die sie erzeugen.

Die praktikable Lösung ist, jeden Befund dem System zuzuordnen, in dem er entsteht, statt dem, in dem er auffällt, und diese Zuordnung an die Eigentümer der Vorsysteme zu berichten. Damit wird aus einem Qualitätsproblem der Abrechnung eine Liste konkreter Mängel mit benannten Zuständigen, und das ist die einzige Form, in der sie behoben werden.

Wo wir ansetzen

In unseren Projekten an Abrechnungs- und Zahlungsplattformen beginnt die Arbeit an Revenue Assurance fast immer mit derselben Übung: die Kette einmal vollständig aufzeichnen, jeden Übergabepunkt benennen, und für jeden Punkt feststellen, ob es dort eine unabhängige Zählung gibt. In gewachsenen Plattformen liegt die Antwort bei der Mehrzahl der Übergänge zunächst bei Nein.

Diese Aufnahme kostet wenige Wochen und verändert die Diskussion, weil sie aus einer Vermutung über mögliche Verluste eine Liste konkreter blinder Stellen macht. Erst danach ist die Frage sinnvoll, welche davon zuerst geschlossen werden.