Rechnungsdoubletten im März 2026

Veröffentlicht am

Entschuldigung: Bei uns ist was schiefgelaufen!

Jeden Monatsersten startet unser Rechnungslauf. Was vor 20 Jahren als kleines manuell gestartetes Script einer kleinen Firma mit wenigen Kunden angefangen hat, ist inzwischen eine echte Choreographie geworden aus zahlreichen Schritten zur Vor- und Nachbereitung und mehreren Stunden für die eigentliche Fakturierung.

Erledigt werden diese Schritte von unseren fleißigen "Rechnungsläufern", virtuelle Prozesse, von denen eine(r) alle 15 Minuten losläuft, die nächste Aufgabe erledigt, nach in der Regel 2-8 Minuten damit fertig ist und sich wieder in seiner Zentrale zurückmeldet. Damit dann zur nächsten Viertelstunde der nächste Rechnungsläufer (oder -läuferin) an den Start geht. 

Am 01.03.2026 am späten Nachmittag kam dann die Phase der Fakturierung. Unser Rechnungsläufer-Prozess läuft dabei los zum ersten Schalter, fragt dort die Datenbank, was in die nächste zu erstellende Rechnung aufgenommen werden muss und übernimmt das in sein Rechnungsformular. Dann geht's weiter zum nächsten Schalter, dort lässt er sich die nächste freie Rechnungsnummer zuteilen. Die trägt er ebenfalls auf sein Rechnungsformular ein, läuft zum nächsten Schalter und verschickt dort die soeben erstellte Rechnung. Das ganze dauert ca. 2-3 Sekunden, er macht es 120 Mal hintereinander und nach etwa 5 Minuten meldet er sich dann als fertig zurück - normalerweise.

An diesem Tag aber nicht, in der Zentrale wartete man vergeblich auf die Fertigmeldung. Also wurde der Gesamtprozess gestoppt und unsere Rufbereitschaft alarmiert. Der Kollege, dieses Mal ein echter, hat rund zwei Stunden lang den Fehler zunächst versucht zu sehen, dann die Ursache zu finden, und zum Schluss zu korrigieren. Der Fehler, wie sich später herausstellte, war eine Engstelle in der Datenbank, weshalb das Erstellen einer Rechnung etwa fünf Sekunden länger dauerte als üblich (und damit waren die 120 Rechnungen pro Durchgang nicht mehr zu schaffen).

Um den Fehler sehen zu können, musste unser Kollege (also der echte) genau diesen Rundlauf selbst starten (also manuell einen Rechnungsläufer ins Rennen schicken) und zugucken, ob er ins Stolpern gerät oder durchläuft oder oder oder. 

Nun darf es nicht vorkommen, dass mehrere Rechnungsläufer gleichzeitig auf der Bahn unterwegs sind. Würde das passieren, dann würden die gleichzeitig die gleichen Rechnungsinhalte auf ihr Rechnungsformular schreiben und am Ende die gleiche Rechnung mehrfach versenden. Das möchten wir nicht.

Darum gibt es definierte Zeit-Slots: Zu jeder Viertelstunde, also z.B. um 17.45 Uhr, startet der automatische Rechnungsläufer. Und hat Energie für genau 10 Minuten. Ab 17.55 Uhr ist die Bahn also wieder frei und unser Bereitschaftstechniker konnte den manuellen Start veranlassen. (Und dabei sicherstellen, dass die Bahn bis 18 Uhr auch wieder frei ist). 

Theoretisch. Doch durch den Engpass der Datenbank waren auch andere Dinge verzögert, unter anderem auch die Startaufstellung für die (automatischen) Rechnungsläufer. Statt z.B. um 17.45 Uhr loszulaufen erfolgte der automatische Start (unbemerkt) erst rund 8 Minuten später.

Und es passierte genau das, was durch die Slot-Regelung eigentlich hätte vermieden werden sollen: Es waren mehrere Rechnungsläufer unterwegs und haben bei einigen Kunden Rechnungen versehentlich doppelt ausgestellt. 

Das hätte nicht passieren dürfen. Wir haben in den letzten Wochen nicht nur analysiert, wen das betraf, sondern auch Maßnahmen ergriffen, damit sich so ein Problem nicht nochmal wiederholt. 

Entschuldigung! Wir haben die betroffenen Rechnungen heute storniert.

Aktuelles