Abgleich & Zahlungsflüsse

Auf den Rechnungen eines Armaturenherstellers steht unter der Bankverbindung eine Zeile, die kaum ein Kunde liest: RF18 5390 0754 7034. Sie ist eine strukturierte Gläubigerreferenz nach ISO 11649. Überweist der Kunde mit dieser Angabe, findet das ERP-System die Rechnung ohne Zutun. Die Referenz reist mit der Zahlung und kommt im Kontoauszug unverändert an. Zahlt derselbe Kunde in Euro-Stablecoins, kommt nur der Betrag an. Die Buchhaltung muss die Rechnung dann aus anderen Merkmalen erschließen: aus Betrag, Absender und Zeitpunkt.

Woran eine Überweisung ihre Rechnung erkennt

Im SEPA-Verfahren hat jede Überweisung ein Feld für den Verwendungszweck. Das Regelwerk des European Payments Council (EPC) erlaubt darin 140 Zeichen, frei formuliert oder strukturiert. Es begründet das Feld ausdrücklich mit dem automatischen Abgleich von Forderungen und Zahlungen beim Empfänger. Jede Bank auf dem Weg muss die Angaben vollständig und unverändert weitergeben. Als bevorzugte Form empfiehlt das Regelwerk die strukturierte Gläubigerreferenz, und zwar für Zahlungen, die sich auf eine einzelne Rechnung beziehen.

Die Schweizer Richtlinien zur QR-Rechnung beschreiben den Aufbau genauer. Die Referenz hat 5 bis 25 Zeichen und beginnt mit RF und zwei Prüfziffern nach dem Verfahren Modulo 97-10. Ein Zahlendreher fällt deshalb schon bei der Eingabe auf, nicht erst in der Buchhaltung. Zahlt ein Kunde zwei Rechnungen auf einmal, hilft die eine Referenz allerdings nicht weiter. Dann steht im freien Text eine Liste von Rechnungsnummern, oder der Kunde schickt ein Zahlungsavis.

Aus diesen Angaben arbeitet ein Abgleichsprogramm in Stufen. Zuerst sucht es die Referenz. Fehlt sie oder passt sie nicht, prüft es Betrag und Zahler gegen die offenen Posten dieses Kunden. Bleiben danach mehrere Kandidaten, gibt die Nähe zur Fälligkeit den Ausschlag. Was keine Stufe eindeutig zuordnet, landet auf der Liste zur Klärung.

Was bei einer Zahlung in Token fehlt

Bei einem Euro-Stablecoin auf Ethereum fällt die erste Stufe aus. Das Ereignis einer Übertragung trägt Absender, Empfänger und Betrag, aber keinen Verwendungszweck; die Felder im Einzelnen sind in Datenstandard & Kontoauszug beschrieben. Die zweite Stufe greift nur zur Hälfte. Der Betrag ist bekannt, den Zahler kennt die Buchhaltung aber nur als Adresse. Ob diese Adresse zu einem Kunden gehört, steht in den Stammdaten, sofern jemand sie dort hinterlegt hat. Wie das geschieht, ist in Stammdaten, Privacy & Security beschrieben.

Eine Eigenschaft der Token hilft dagegen. Bei einer Auslandsüberweisung kommt oft weniger an, als der Kunde angewiesen hat, weil Korrespondenzbanken unterwegs Entgelte abziehen. Beim Stablecoin zahlt der Absender die Netzgebühr getrennt, zum Beispiel in Ether. Ein Token, der beim Übertragen nichts einbehält, kommt deshalb in genau der angewiesenen Höhe an. Weicht der Betrag von der Rechnung ab, liegt der Grund beim Kunden: ein Skontoabzug, eine Kürzung, ein Tippfehler. Jede Differenz hat damit eine kaufmännische Ursache und keine technische.

Zwei Rechnungen, eine Zahlung

In Datenstandard & Kontoauszug zahlt ein Kunde des Armaturenherstellers 18.400 Euro-Stablecoins für zwei Rechnungen. Angenommen, bei ihm sind vier Rechnungen offen, über 11.900, 6.500, 4.200 und 2.300 Euro. Keine davon lautet auf 18.400. Das Programm sucht deshalb Kombinationen, deren Summe den Betrag trifft, und findet zwei: 11.900 und 6.500 oder 11.900, 4.200 und 2.300. Rechnerisch sind beide gleich gut. Für die eine spricht vielleicht die ältere Fälligkeit, für die andere eine Mail des Kunden, die im Postfach des Vertriebs liegt.

Raten ist in diesem Fall schlechter als Liegenlassen. Wählt das Programm die falsche Kombination, sind zwei Rechnungen ausgeglichen, die noch offen sind, und eine bezahlte Rechnung geht in den Mahnlauf. Auffallen wird das erst, wenn der Kunde die Mahnung reklamiert. Eine brauchbare Regel lässt mehrdeutige Summen deshalb nicht automatisch durch. Sie legt den Eingang mit beiden Vorschlägen zur Klärung vor.

Umgekehrt kann eine Rechnung auch in mehreren Zahlungen eingehen. Ein anderer Kunde zahlt auf eine Rechnung über 8.000 Euro zunächst 5.000 und drei Wochen später den Rest. Die erste Zahlung trifft keinen offenen Posten in voller Höhe. Das Programm braucht eine Regel, ob es sie als Teilzahlung auf die einzige passende Rechnung bucht oder zur Klärung stellt. Ähnlich liegt es bei Abweichungen. Zahlt ein Kunde 6.370 statt 6.500 Euro, kann das ein Skontoabzug von 2 Prozent sein, und der Posten ist ausgeglichen. Bei 6.300 Euro ist es eine Kürzung, die jemand klären muss.

Solche Regeln sind keine technische Einstellung. Wie viel Abweichung ein Posten verträgt, wann eine Teilzahlung gebucht wird und was mit mehrdeutigen Summen geschieht, wirkt bis in Mahnungen und Kundenkonten. Die Finanzleitung legt es fest, und es gilt dann für jede Zahlung gleich.

Wenn ein Dienstleister die Zahlungen bündelt

Viele Unternehmen nehmen Stablecoins nicht selbst an, sondern über einen Zahlungsdienstleister (PSP). Er nennt dem Kunden eine Adresse, nimmt die Token entgegen und zahlt das Geld gesammelt aus, etwa in Euro auf das Geschäftskonto. Der Armaturenhersteller verkauft zum Beispiel Ersatzteile über einen Webshop. Angenommen, an einem Tag gehen dort 37 Zahlungen über zusammen 9.250 Euro ein, und der Dienstleister behält 1 Prozent als Entgelt ein. Auf dem Bankkonto kommen dann 9.157,50 Euro in einer Summe an.

Mit dem Kontoauszug allein lässt sich dieser Eingang nicht abgleichen. Er gleicht nicht eine Rechnung aus, sondern 37, und keine davon lautet auf den ausgezahlten Betrag. Die Zuordnung steht in der Abrechnung des Dienstleisters: welche Zahlung zu welcher Bestellung gehört und was er einbehalten hat. Die Buchhaltung gleicht die 37 offenen Posten in voller Höhe aus und bucht die 92,50 Euro als Aufwand. Nur so stimmen am Ende die Kundenkonten und das Bankkonto zugleich.

Für solche Sammelbuchungen kennt ISO 20022 eine eigene Form. Im Schema von camt.054 kann ein einzelner Umsatz einen Block für die Sammelbuchung tragen, mit der Zahl der Transaktionen und dem Gesamtbetrag. Darunter folgen beliebig viele Einzeltransaktionen, jede mit eigenem Betrag, eigenen Entgelten und eigenem Verwendungszweck. Liefert der Dienstleister seine Abrechnung in dieser Form, liest das ERP-System sie wie eine Sammelbuchung der Bank. In welchem Format er tatsächlich liefert, regelt der Vertrag mit ihm. Davon hängt ab, wie viel Handarbeit jeder Tag im Webshop kostet.

Sammelzahlungen im Ausgang

Dasselbe Muster gibt es in der Gegenrichtung. Zahlt der Armaturenhersteller zwölf Lieferanten auf einmal, kann er dafür eine einzige Transaktion abschicken, die über einen Smart Contract zwölf Übertragungen auslöst. Nach dem Token-Standard EIP-20 erzeugt jede Übertragung ihr eigenes Ereignis. Alle zwölf tragen aber denselben Transaktions-Hash. Der Hash bezeichnet dann nicht mehr eine Zahlung, sondern ein Bündel. Eindeutig wird ein einzelner Umsatz erst zusammen mit seiner Position im Block, die jedes Ereignis mitführt. Wer im Abgleich nur den Hash speichert, kann die zwölf Verbindlichkeiten nicht auseinanderhalten.

Was auf dem Klärungskonto landet

Was keine Regel zuordnet, bucht die Buchhaltung zunächst auf ein Klärungskonto. Bei Zahlungen in Token füllt es sich auch aus Gründen, die es im Bankverkehr so nicht gibt. Einer davon ist ein Absender, der in keinen Stammdaten steht. Zahlt ein Kunde aus einem Konto bei einer Handelsplattform, schickt die Plattform die Token von einer Adresse, die sie selbst verwaltet. Im Auszug erscheint dann die Plattform als Absender, und eine Erstattung an diese Adresse ginge an sie statt an den Kunden. Eine Rückgabe wie bei der Lastschrift gibt es nicht. Jede Erstattung ist eine neue ausgehende Zahlung an eine Adresse, die vorher geprüft sein muss.

Für den Finanzchef zeigt das Klärungskonto, wie gut der Abgleich arbeitet. Zwei Werte genügen dafür: der Anteil der Eingänge, die das Programm ohne Eingriff zuordnet, und das Alter der Posten, die übrig bleiben. Solange ein Betrag dort steht, zeigen die Bücher Geld, das keinem Kunden gehört, und Forderungen, die längst bezahlt sind. Ein hoher Stand zum Monatsende kostet deshalb doppelt, in der Klärung und im Mahnwesen.

Eine Referenz für den Ledger

Für die fehlende Referenz gibt es einen Vorschlag. ERC-7699 erweitert den Token-Standard um eine Übertragung mit Referenz. Der Token schreibt dann neben das Ereignis der Übertragung ein zweites, das bis zu 32 Byte im Klartext tragen kann. Eine Gläubigerreferenz mit höchstens 25 Zeichen passt hinein. Die RF-Referenz, die heute auf der Rechnung steht, könnte so mit der Zahlung auf dem Ledger reisen. Die erste Stufe des Abgleichs griffe dann wieder, ohne neue Regel.

Die Grenzen nennt der Vorschlag selbst. Im September 2026 ist er ein Entwurf, und er wirkt nur bei einem Token, dessen Emittent ihn einbaut. Die Referenz ist öffentlich und verbindet für jeden sichtbar die Zahlungen, die zu einer Rechnung gehören. Außerdem prüft der Standard sie nicht. Wer die Referenz eines fremden Kunden einsetzt, erzeugt einen Eingang, der scheinbar passt. Die Referenz sagt dann, welche Rechnung gemeint ist, und wer gezahlt hat, sagt weiterhin nur die Adresse.