Doppelbuchungen vermeiden: Idempotenz im Mittelstand

Zwei Systeme tauschen Daten über eine Leitung aus, die nicht zuverlässig ist. Das ist keine Schwäche einer bestimmten Software, sondern eine Eigenschaft jeder Verbindung, die über ein Netzwerk läuft. Der Sender schickt einen Beleg und wartet auf die Bestätigung. Kommt sie an, ist die Sache klar. Kommt sie nicht an, kennt der Sender nur einen einzigen Zustand: keine Antwort erhalten. Er weiß nicht, ob der Beleg unterwegs verloren ging, ob das Zielsystem ihn erhalten und verworfen hat oder ob er dort längst verbucht wurde und nur die Rückmeldung auf halbem Weg stecken blieb.

Genau hier liegt der Kern des Problems: keine Antwort bedeutet nicht, dass nichts angekommen ist. Trotzdem muss der Sender etwas tun, denn die stille Variante wäre schlimmer. Würde er bei jeder ausbleibenden Antwort einfach aufgeben, gingen Belege verloren, und der Bestand liefe langsam auseinander. Deshalb wiederholt jede vernünftig gebaute Übergabe den Versuch, meist mit wachsendem Abstand: nach einer Minute, nach fünf Minuten, nach einer halben Stunde. Der Wiederholungsversuch ist also nicht der Fehler. Der Fehler ist, dass die Gegenseite ihn nicht als Wiederholung erkennt.

Ohne Erkennungsmerkmal sieht das Zielsystem beim zweiten Versuch schlicht einen neuen Beleg mit denselben Daten. Es hat keinen Grund, misstrauisch zu werden, denn zwei Rechnungen über denselben Betrag an denselben Kunden am selben Tag sind fachlich möglich. Also legt es einen zweiten Datensatz an, vergibt eine zweite interne Nummer und meldet erfolgreich zurück. Der Sender ist zufrieden, das Ziel ist zufrieden, und in der Buchhaltung steht ein Betrag doppelt. Bei einem Lastschrifteinzug wird er doppelt gezogen, bei einer Lagerbuchung wandert die Menge zweimal aus dem Bestand, bei einer Zeitbuchung erscheint dieselbe Stunde zweimal auf der Projektabrechnung.

Ein brauchbarer Schlüssel hat eine einzige entscheidende Eigenschaft: Er ändert sich nicht, wenn derselbe Vorgang erneut gesendet wird. Damit fallen alle Kandidaten aus, die beim Absenden entstehen. Ein Zeitstempel ist beim zweiten Versuch ein anderer. Eine fortlaufende Nummer der Übertragung ebenso. Eine Zufallszahl, die die Schnittstelle je Aufruf erzeugt, macht jeden Versuch zu einem neuen Vorgang und ist damit das genaue Gegenteil dessen, was gebraucht wird.

Der Schlüssel muss aus dem fachlichen Vorgang selbst kommen, also aus dem sendenden System, in dem der Beleg entstanden ist. Bewährt hat sich eine Kombination aus Belegart, Belegnummer und dem Kürzel des Quellsystems, etwa in der Form RE-2026-4417 für eine Ausgangsrechnung. Diese Kennung ist im Quellsystem ohnehin eindeutig, sie ist für Menschen lesbar, und sie taucht bei einer späteren Klärung auch auf dem Papierbeleg auf. Alternativ lässt sich eine technische Kennung verwenden, die beim Anlegen des Vorgangs erzeugt und dauerhaft am Datensatz gespeichert wird.

Ein häufiger Fehler in der Praxis ist der Versuch, ohne Schlüssel auszukommen und stattdessen den Inhalt zu vergleichen: gleicher Kunde, gleicher Betrag, gleiches Datum, also vermutlich ein Doppel. Das funktioniert bei Rechnungen mit ungewöhnlichen Beträgen erstaunlich gut und bei allem anderen nicht. Zwei Wartungspauschalen über denselben Betrag am selben Tag sind ein völlig normaler Geschäftsvorfall. Ein Inhaltsvergleich als einzige Absicherung führt deshalb entweder zu übersehenen Doppeln oder zu abgewiesenen echten Belegen. Als zusätzliche Suchhilfe für Altfälle ist er nützlich, als Schutz im laufenden Betrieb nicht.

Das Protokoll ist die unscheinbarste der drei Zutaten und in der Nacharbeit die wichtigste. Es hält je Schlüssel fest, wann der Vorgang eingegangen ist, wie er entschieden wurde und welche interne Nummer dabei entstand. Sinnvoll sind außerdem eine Prüfsumme über die übermittelten Inhalte und die Angabe, welches System gesendet hat. Die Prüfsumme beantwortet eine Frage, die sonst offen bleibt: Wurde derselbe Schlüssel mit unterschiedlichem Inhalt geschickt? Das ist kein Wiederholungsversuch, sondern ein Hinweis auf eine geänderte Rechnung oder auf einen Fehler in der Schlüsselvergabe, und beides sollte nicht stillschweigend abgewiesen werden.

Zur Aufbewahrungsdauer gibt es keine allgemeingültige Zahl. Sie muss mindestens das Zeitfenster abdecken, in dem Wiederholungsversuche möglich sind, und darüber hinaus die Zeit, in der jemand einen Vorgang klären will. In der Praxis haben sich mindestens neunzig Tage bewährt, bei belegführenden Strecken deutlich mehr (Projekterfahrung). Für die Protokollierung selbst gibt das Bundesamt für Sicherheit in der Informationstechnik in seinen Grundschutz-Bausteinen eine Orientierung: Umfang, Speicherort und Aufbewahrungsdauer sollten schriftlich festgelegt und regelmäßig überprüft werden (BSI). Wo Protokolle steuerlich relevante Vorgänge betreffen, gelten zusätzlich handels- und steuerrechtliche Aufbewahrungsfristen, deren Anwendung im Einzelfall fachlich zu prüfen ist.

Wer den Schutz nachrüstet, hat das Problem für die Zukunft gelöst und für die Vergangenheit nicht. Im Bestand liegen die bereits entstandenen Doppel weiter, und sie treten dann zutage, wenn es besonders ungünstig ist: bei der Abstimmung der Offenen Posten, bei einer Prüfung oder bei der Rückfrage eines Kunden, der eine Rechnung zweimal erhalten hat. Eine gezielte Suche im Bestand ist deshalb der zweite Teil der Aufgabe, und sie lässt sich in wenigen Schritten strukturieren.

Der Suchansatz ist derselbe, der als laufender Schutz untauglich wäre: der Inhaltsvergleich. Als Fahndungswerkzeug für einen abgeschlossenen Zeitraum ist er gut geeignet, weil jeder Treffer ohnehin von Hand beurteilt wird. Wichtig ist nur, die Trefferliste großzügig zu halten und danach zu sortieren, statt die Kriterien so eng zu setzen, dass am Ende eine leere Liste die Erleichterung liefert.

Ob eine vorhandene Übergabe geschützt ist, lässt sich ohne Zugriff auf den Quelltext klären. Es genügen einige Fragen an die Stelle, die die Verbindung betreut — intern oder beim Dienstleister. Entscheidend ist dabei weniger die Antwort selbst als ihre Form: Wer den Vorgangsschlüssel benennen und das Protokoll zeigen kann, hat den Schutz vermutlich. Wer antwortet, dass so etwas noch nie vorgekommen sei, hat ihn vermutlich nicht.

Die letzte Frage ist die aussagekräftigste, weil sie sich nicht durch eine Beschreibung beantworten lässt. Ein bewusst wiederholter Testbeleg in einer Prüfumgebung dauert wenige Minuten und liefert ein eindeutiges Ergebnis: Entweder steht der Beleg danach einmal im Zielsystem oder zweimal. Alles andere ist Auslegung. Wer regelmäßig Verbindungen betreibt, nimmt diesen Test in die wiederkehrenden Aufgaben des laufenden IT-Betriebs auf, gemeinsam mit der Kontrolle der Warteschlange und der Protokollgröße.