Kann LYNQTECH Abrechnung nur im Frontend?  

LYNQTECH, die Cloud-Plattform für Energieversorger, begleitet Stadtwerke als agiler Partner bei der digitalen Transformation. Als fester Bestandteil von CORE ermöglicht das Modul „Abrechnung“ die vollständig automatisierte Abrechnung sämtlicher Produkte. Der ein- und ausgehende Zahlungsverkehr wird autonom abgewickelt, wobei eine individuelle Steuerung auf Wunsch weiterhin möglich ist. 

Oft werden wir bei LYNQTECH gefragt, ob die Abrechnung nur aus einem Frontend besteht. Nein, natürlich nicht! Schauen wir uns die im Hintergrund laufenden Echtzeit-Prozesse mal genauer an, die einem EVU viel Arbeit ersparen und Service- und Betriebskosten spürbar senken. 

Realtime-Abrechnung statt Nachtlauf

Die Event-basierte Abrechnung für Strom, Gas und Non-Commodity findet in frei definierbaren Zyklen statt: Jährlich, vierteljährlich oder monatlich – Einzel- oder Gruppenrechnungen für beliebige Zeiträume sind in Sekunden erstellt, und Endkund:innen werden ebenso schnell wie umfassend informiert. Die bei Konzepten anderer Markteilnehmer gängigen Nachtläufe entfallen und werden bei LYNQTECH durch Realtime-Abrechnungen ersetzt.

Neben einfachen Preiskonstruktionen aus Arbeitspreis und Grundpreis werden auch komplexere Modelle zur Preisbildung unterstützt: Zonenpreise, Staffelpreise, Durchschnittspreise, Einmalkosten bei Non-Commodity oder Abo- beziehungsweise Leasing-Modelle – alles ist möglich.

Domain-Verbund: Mehr als nur die Summe der Teile …

Marktpartnerrechnungen sowie die zugehörigen Mengen- und Preismitteilungen werden vom Modul „Abrechnung“ selbsttätig geprüft, Ein- und Ausgangszahlungen sowie deren buchhalterische Erfassung zuverlässig abgewickelt. Für die Einzelfallklärung ist ein bedienerfreundliches Frontend („Agent Portal“) verfügbar, das innerhalb des Moduls „Abrechnung“ eine von insgesamt neun Domains bildet.

Der Einfachheit halber darf man sich das CORE Modul „Abrechnung“ als Verbund aufeinander abgestimmter Domains vorstellen: Die einzelnen Domains erfüllen unterschiedliche Aufgaben, sind jedoch eng miteinander verkoppelt und beeinflussen sich bei Bedarf gegenseitig. Zu jeder Domain gehören mehrere Systeme, die einzelnen Aspekten des Abrechnungsprozesses zugeordnet sind und die reibungslose Funktion der Domain sicherstellen.

Smarter Workflow

Zentrales Element des CORE Moduls „Abrechnung“ ist die Billing Engine, in welcher wesentliche Rechnungsprozesse ausgeführt werden. Der Rechnungsprozess kann über das Agent Portal von Mitarbeitenden eines EVU manuell ausgelöst werden, wobei eine intuitiv verständliche Bedienoberfläche den bestmöglichen Überblick sicherstellt. Im Gegensatz zur manuellen Auslösung durch einen Agent triggert die Domain Contract Data Management einen Rechnungsprozess, sobald der vertraglich festgelegte Zeitpunkt erreicht ist – etwa zu einem festen jährlichen Termin oder anlässlich des End-of-Supply, an dem automatisch eine Schlussrechnung erstellt wird. In der Domain sind wichtige Vertragseckpunkte (Produkte, Preise etc.) gespeichert.

Weitere für die Abrechnung erforderliche Daten werden aus der Domain Technical Master Data Management bezogen, in welcher technische Stammdaten von Kund:innen hinterlegt sind, beispielsweise der Zählertyp. Falls es die Gegebenheiten in einem EVU erfordern, können zu dieser Kategorie gehörende Werte aus externen Systemen angefordert werden. Keine technischen Kennziffern, sondern die personenbezogenen Daten von Kund:innen sind schließlich in der Domain Customer Data Management gespeichert. Hierzu gehören unter anderem die Anschrift und die Bankverbindung.

Bevor weitere Schritte erfolgen, prüft der Algorithmus, ob ein „Billing Lock“ existiert: Ist eine derartige Abrechnungssperre auf Vertragsebene gesetzt, weil sich beispielsweise Zahlungen von Kund:innen noch in Klärung befinden, wird der Abrechnungsprozess zunächst gestoppt („Block Task“) und ein Agent über den Vorgang informiert.

Immer zum richtigen Zeitpunkt

Ist keine Sperre vorhanden, gilt es im nächsten Schritt, den Rechnungszeitpunkt zu bestimmen: Eine Rechnung deckt grundsätzlich einen definierten Zeitraum ab, der lückenlos sowie überlappungsfrei am letzten Abrechnungszeitpunkt beginnen muss und sich bis zum aktuellen Datum erstreckt – selbstverständlich kann die Billing Engine eigenständig auf die in diesem Zusammenhang benötigten Daten zurückgreifen.

Für den nun feststehenden Zeitraum müssen „Accounting Periods“ berücksichtigt werden: Möglicherweise hat sich für eine bestimmte Zeitdauer ein Berechnungsfaktor wie etwa die Höhe der Umsatzsteuer geändert, was eine Abgrenzung zu den Zeitfenstern vor und hinter der betreffenden Periode erforderlich macht. Auch ist für den Jahresabschluss eines EVU grundsätzlich eine bilanzielle Abgrenzung erforderlich, um Umsätze korrekt zuordnen zu können, ohne dass Rechnungen an Kund:innen übermittelt werden.

Kundenspezifische Zeitscheiben, die zur Erstellung einer Rechnung benötigt werden, erfasst das System ebenso wie eventuelle Produkt- oder Zählerwechsel bzw. Preisänderungen – es gilt, verbrauchte Einheiten mit den für die jeweilige Zeitscheibe geltenden Preisen in Einklang zu bringen. Für typische Abrechnungen werden meist drei bis vier Zeitscheiben samt der zu den jeweiligen Grenztagen gehörenden Zählerstände berücksichtigt. Innerhalb der Billing Engine erfolgt eine Abfrage, welche Zählerstände aktuell verfügbar sind – falls Lücken bestehen, wird eine Schätzung vorgenommen, sofern es sich nicht um eine Schlussrechnung (beispielsweise anlässlich eines Auszugs) handelt. Sind Schätzungen nicht möglich, wird über die Marktkommunikation eine Anfrage an den Netzbetreiber mit Bitte um eine Übermittlung der Zählerstände gesendet. Die jeweils gültigen Netzkosten, Netztarife und ähnlichen Faktoren werden aus der Domain Grid Data Management bezogen.

Nebenbuch und Netzgebühren

Sind alle relevanten Daten vorhanden, kommen nun als Ergänzung Informationen aus dem Subledger wie etwa bereits bezahlte Abschläge oder angefallene Bankgebühren hinzu. Der Begriff Subledger lässt sich mit „Nebenbuch“ übersetzen: In dieser Domain werden alle Ereignisse vermerkt, die während des laufenden Vertragsverhältnisses von Belang sind. Zu den gespeicherten Positionen zählen unter anderem ein- und ausgehende Zahlungen sowie sämtliche Rechnungen.

Auch technische Stammdaten sind an dieser Stelle erforderlich, um in die Kalkulation Faktoren wie Netzgebühren, Konzessionsabgaben und die EEG-Umlage einbeziehen zu können, welche letztlich als „Bill Items“ aufgeführt werden. Auch hier kann eine Validierung anhand vorgegebener Kriterien erfolgen. Ein „Block Task“-Befehl wird gesetzt, sofern Regeln verletzt werden sollten.

Verbrauchsermittlung einfach gemacht

Ein wichtiger Punkt für Verbraucher:innen ist der Abschlag, dessen Höhe die Billing Engine auf Basis aktuell bekannter Werte bestimmt. Beim Consumption Management wird in diesem Zusammenhang zunächst der geschätzte Verbrauch für die kommende Rechnungsperiode angefragt – von dort wird der Schätzwert an die Engine übermittelt, welche nun einen konkreten Betrag prognostiziert, welcher später unter Annahme eines gleichbleibenden Verbrauchs den Kund:innen mitgeteilt wird. Ziel ist immer, dass zum Ende der nächsten Periode keine zusätzlichen Zahlungen erforderlich werden – angestrebt wird eine Punktlandung ohne Nachforderung. Im Consumption Management werden die Zählerstände erfasst, welche dem EVU sowohl direkt von Kund:innen als auch durch die Marktkommunikation übermittelt werden. Neu eingehende Zählerstandsmitteilungen werden in einem ersten Schritt validiert; entsprechende Regeln (etwa vertragsspezifische min./max. Consumption) sind in der Domain hinterlegt. Sollte ein Wert nicht stimmig erscheinen, erfolgt ein „Block Task“-Befehl und ein Agent wird informiert. Ist der übermittelte Wert valide, wird er gespeichert. Parallel dazu wird die Billing Engine informiert, welche ihrerseits nun ggf. einen bislang blockierten Rechnungsprozess auslösen kann – der Vorgang wird automatisch neu gestartet, ohne dass Mitarbeitende des EVU aktiv werden müssen.

Rechnungserstellung und -versand

In einem letzten Schritt konsultiert die Billing Engine abschließend das Subledger und das Customer Master Data Management, um die Dokumentenerstellung im Document Management anzustoßen. Das Document Management widmet sich gemäß seines Namens der Erstellung und Verwaltung von Dokumenten sowie dem Versand von Rechnungen an Kund:innen.