Jeden Morgen liest das ERP-System eines Armaturenherstellers die Auszüge seiner Banken ein. Es gleicht die Umsätze mit den offenen Posten ab, und was nicht passt, landet auf einer Liste zur Klärung. Seit das Unternehmen einen Teil seiner Rechnungen in Euro-Stablecoins abrechnet, führt es ein Konto, für das kein Auszug kommt: sein Wallet. Dort gehen Zahlungen ein und aus, aber niemand bringt sie in das Format, das die Buchhaltung einliest.
Diesen fehlenden Auszug nennt dieser Wissenshub On-Chain Bank Statement (OCBS). Den Begriff hat Wolfram Menser geprägt, er steht hier seit Januar 2026; ein Standard ist er nicht. Gemeint ist ein Kontoauszug, der aus den Ereignissen auf der Blockchain entsteht und sich am Aufbau von camt.053 orientiert, dem Tagesauszug nach ISO 20022. Wie nah er dem Vorbild kommt, entscheidet sich Feld für Feld. Manche Felder lassen sich direkt füllen, andere nur mit einer Festlegung des Unternehmens, und für eines liefert die Blockchain gar nichts.
Was ein Tagesauszug trägt
camt.053 gehört im Katalog von ISO 20022 zum Nachrichtenset Bank-to-Customer Cash Management. Die aktuelle Fassung trägt die Versionsnummer 14, der Katalog nennt als letzte Änderung den 19. März 2026. Das Schema legt fest, welche Angaben Pflicht sind und wie lang ein Feld sein darf.
Ein Auszug hat drei Schichten. Oben stehen das Konto und mindestens ein Saldo, jeweils mit Art, Betrag und Datum. Darunter folgen die Umsätze. Pflicht sind für jeden Umsatz der Betrag mit Währung, die Angabe Soll oder Haben, ein Status und ein Code, der die Art des Geschäfts einordnet. Buchungstag, Valuta, eine Referenz des Kontoführers und die Entgelte sind vorgesehen, aber freiwillig.
Die dritte Schicht sind die Einzelheiten je Transaktion. Hier stehen die Beteiligten mit Namen und Konto, die Referenzen vom Auftrag bis zur Gutschrift und der Verwendungszweck, frei formuliert in Zeilen zu je 140 Zeichen oder strukturiert. An diesen Angaben hängt der Abgleich mit den offenen Posten.
Zum selben Set gehören zwei Geschwister. camt.052 meldet Umsätze im Laufe des Tages, camt.054 eine einzelne Gutschrift oder Belastung. Beide verwenden für den Umsatz dieselbe Struktur wie camt.053. Für ein OCBS ist das nützlich: Dieselbe Übersetzung eines Ereignisses taugt für die Meldung sofort und für den Auszug am Tagesende.
Was die Blockchain liefert
Bei einem Euro-Stablecoin auf Ethereum hinterlässt jede Übertragung ein Ereignis namens Transfer. Der Standard für solche Token, EIP-20, schreibt vor, dass es bei jeder Übertragung ausgelöst wird, auch wenn der Betrag null ist. Das Ereignis trägt genau drei Werte: Absender, Empfänger und Betrag. Der Betrag ist eine ganze Zahl; wie viele Stellen davon Nachkommastellen sind, legt jeder Token selbst fest.
Um das Ereignis herum führt die Blockchain weitere Angaben. Dazu gehören der Hash der Transaktion, die Nummer des Blocks, die Position des Ereignisses in diesem Block und der Zeitpunkt, zu dem der Block gebildet wurde, als Unix-Zeitstempel. Eine Adresse hat 20 Byte, in der üblichen hexadezimalen Schreibweise 42 Zeichen. Ein Transaktions-Hash hat 32 Byte, also 66 Zeichen.
Einen Verwendungszweck führt das Ereignis nicht. Es gibt dafür kein Feld, und keine Rechnungsnummer reist mit der Zahlung.
Feld für Feld
Legt man beide Seiten nebeneinander, zeigt sich, wo die Übersetzung glatt geht und wo sie eine Entscheidung braucht. Die Grenzen in der mittleren Spalte stammen aus dem Schema von camt.053 in Version 14.
| Im Auszug | Grenze im Schema | Von der Blockchain | Was offen bleibt |
|---|---|---|---|
| Kontokennung | IBAN oder bis 34 Zeichen | Adresse mit 42 Zeichen | passt nicht; das Konto braucht eine eigene Kennung, die Adresse steht in der Zusatzinformation |
| Währung | genau drei Großbuchstaben | Adresse des Token-Kontrakts | kein Code nach ISO 4217 für den Token; das Unternehmen legt einen fest |
| Betrag | bis fünf Nachkommastellen | ganze Zahl, Stellen je Token | Ether rechnet mit 18 Stellen; was darunter liegt, fällt beim Runden weg |
| Buchungstag | Datum oder Zeitpunkt | Zeitstempel des Blocks | die Tagesgrenze |
| Status | Pflichtfeld | Zahl der Bestätigungen | ab wann ein Umsatz als gebucht gilt |
| Referenz | bis 35 Zeichen | Hash mit 66 Zeichen und Position im Block | passt nicht; Zusatzinformation mit bis zu 500 Zeichen oder ergänzende Daten |
| Beteiligte | Name und Konto | Adresse des Gegenübers | der Name kommt aus den Stammdaten |
| Verwendungszweck | 140 Zeichen je Zeile oder strukturiert | nichts | fehlt |
| Art des Geschäfts | Pflichtcode | nichts | ein eigener Code, das Schema lässt ihn zu |
| Entgelte | Betrag je Umsatz | Netzgebühr in Ether, nur beim Absender | ein eigener Umsatz in eigener Währung |
Drei Zeilen reichen über eine bloße Formatfrage hinaus. Die Referenz passt nicht, und ausgerechnet sie wäre der Schlüssel, mit dem ein Prüfer den Umsatz auf der Blockchain wiederfindet. Die Währung ist keine Währung im Sinne von ISO 4217, sondern ein Token mit eigenem Emittenten. Und der Verwendungszweck fehlt ganz; das trifft den Abgleich im Kern.
Einen Teil der Lücke schließt die Travel Rule, allerdings nur, wenn Dienstleister beteiligt sind. Läuft eine Übertragung zwischen zwei Anbietern von Kryptowerte-Dienstleistungen, übermitteln sie nach der Verordnung (EU) 2023/1113 unter anderem die Namen von Absender und Empfänger und ihre Adressen, getrennt von der Blockchain. Führt ein solcher Anbieter das Wallet des Unternehmens, kann er die Beteiligten im Auszug mit Namen füllen. Ein Verwendungszweck gehört nicht zu diesen Angaben. Fehlen Angaben, darf der Anbieter die Zahlung zurückhalten, bis sie nachgereicht sind. Dann ist sie auf der Blockchain angekommen, aber noch nicht verfügbar, und das OCBS braucht einen Status, den der Zeitstempel des Blocks nicht kennt. Welche Angaben die Regeln im Einzelnen verlangen, ist in Querschnitt: Compliance & Reporting beschrieben.
Ein Tag mit einem Eingang und einem Ausgang
Am Vormittag zahlt ein Kunde des Armaturenherstellers zwei Rechnungen über zusammen 18.400 Euro-Stablecoins. Auf der Blockchain steht ein Ereignis mit der Adresse des Kunden, der Adresse des Herstellers und dem Betrag. Welche beiden Rechnungen gemeint sind, steht nirgends. Die Buchhaltung kann nur über Betrag und Absender zuordnen, und das gelingt nur, wenn die Adresse des Kunden in den Stammdaten hinterlegt ist. Wie Adressen und Gegenparteien gepflegt werden, ist in Stammdaten, Privacy & Security beschrieben, der Abgleich ohne Rechnungsnummer in Abgleich & Zahlungsflüsse. Eine Netzgebühr fällt für den Hersteller hier nicht an, denn sie trägt, wer die Transaktion abschickt.
Am Nachmittag bezahlt der Hersteller einen Lieferanten mit 6.250 Euro-Stablecoins. Jetzt ist er der Absender und trägt die Gebühr. Sie wird nicht in Euro-Stablecoins fällig, sondern in Ether, der Währung des Netzes. Der Stablecoin-Bestand sinkt also um den Kaufpreis, und ein zweiter Bestand auf derselben Adresse sinkt um die Gebühr. Das OCBS dieses Tages enthält deshalb zwei Auszüge, einen je Bestand, so wie eine Bank für ein Fremdwährungskonto einen eigenen Auszug schickt. Das Schema lässt mehrere Auszüge in einer Nachricht zu. Wie Kaufpreis und Gebühr gebucht werden, ist in Buchung, Bewertung & Steuer beschrieben.
Eine Eigenheit zeigt sich erst, wenn etwas schiefgeht. Die Gebühr ist nach der Dokumentation von Ethereum auch dann fällig, wenn eine Transaktion fehlschlägt. Scheitert die Zahlung an den Lieferanten, steht im Auszug über Ether eine Belastung, zu der es im Auszug über den Stablecoin keinen Umsatz gibt. Die Buchhaltung muss erkennen können, dass beides zusammengehört. Das leistet der Transaktions-Hash, wenn er in beiden Umsätzen steht.
Drei Festlegungen, die niemand abnimmt
Eine Bank bestimmt den Buchungstag selbst. Beim OCBS muss das Unternehmen ihn festlegen. Der Zeitstempel eines Blocks ist Unix-Zeit und damit UTC. Eine Zahlung um 23:30 Uhr UTC fällt im Sommer in Deutschland schon auf den nächsten Tag, 1:30 Uhr mitteleuropäischer Sommerzeit. Ob der Auszug nach UTC oder nach deutscher Zeit schneidet, ist eine Entscheidung, die für jeden Auszug gleich gelten muss.
Die zweite Festlegung betrifft den Status. Eine Zahlung ist nicht in dem Moment endgültig, in dem sie in einem Block steht. Ab welcher Zahl von Bestätigungen ein Umsatz als gebucht gilt, entscheidet das Unternehmen; warum, ist in Wie funktioniert eine Blockchain? beschrieben. Bis dahin steht er im Auszug als vorläufig.
Die dritte ist der Nachweis. Anders als bei einem Bankauszug kann jeder Dritte den Umsatz selbst nachsehen, über einen Block Explorer und den Transaktions-Hash. Damit das im Prüfungsfall gelingt, muss der Hash vollständig im Auszug stehen, nicht gekürzt auf 35 Zeichen. Wie der Auszug danach unveränderbar archiviert wird, ist in Treasury, Risiko & Reporting beschrieben.
Was HGB und Abgabenordnung verlangen
Das Handelsgesetzbuch verlangt in § 239 Abs. 2, dass Eintragungen und Aufzeichnungen vollständig, richtig, zeitgerecht und geordnet vorgenommen werden. Nach Abs. 3 darf eine Eintragung nicht so verändert werden, dass ihr ursprünglicher Inhalt nicht mehr feststellbar ist. Die Abgabenordnung regelt in § 147 Abs. 3 die Aufbewahrung: Bücher zehn Jahre, Buchungsbelege acht Jahre. Zu den Büchern zählt § 147 Abs. 1 Nr. 1 ausdrücklich auch die Arbeitsanweisungen und Organisationsunterlagen, die zu ihrem Verständnis erforderlich sind.
Für ein OCBS ist das keine Randnotiz. Ein Auszug, der aus der Blockchain erzeugt wird, lässt sich jederzeit neu erzeugen und gegen das Original prüfen. Das gelingt aber nur mit denselben Festlegungen zu Tagesgrenze, Bestätigungen, Währungscode und Rundung. Ändert sich eine davon, entsteht aus denselben Ereignissen ein anderer Auszug. Welche dieser Unterlagen in welche Kategorie des § 147 AO fallen und wie der Auszug als Beleg behandelt wird, klärt das Unternehmen mit seinem Steuerberater oder Abschlussprüfer.
Der Auszug braucht einen Absender
Beim Bankkonto stellt der Kontoführer den Auszug aus, und die Buchhaltung vertraut ihm, weil sie der Bank vertraut. Beim Wallet gibt es diesen Kontoführer nicht. Die Lücken aus der Tabelle trennen ein Wallet trotzdem nicht grundsätzlich vom Bankkonto. Jede hat eine bekannte Antwort: der Hash in der Zusatzinformation, ein eigener Code für den Token, der Name aus den Stammdaten, eine feste Tagesgrenze. Es fehlt jemand, der diese Übersetzung jeden Tag auf dieselbe Weise leistet. Das kann ein Verwahrer sein, der das Wallet führt, ein Zusatz zum ERP-System oder ein eigenes Programm. Eine Umsetzung ist HashBuch der Setrion GmbH, die auch diesen Wissenshub betreibt. Es erzeugt aus den Ereignissen eines Wallets einen Auszug mit Anfangs- und Endsaldo und dem Transaktions-Hash je Umsatz und überträgt die Buchungen ins ERP-System. Mit dem Auszug übernimmt dieser Lieferant die Stellung, die heute die Bank hat. Er bestimmt die Festlegungen aus diesem Artikel und damit, was die Buchhaltung für den Stand ihres Kontos hält.
Quellen & Stand
- •ISO 20022 Registration Authority – ISO 20022 Message Definitions: camt.053 (Bank-to-Customer Cash Management) – (englisch; Schema camt.053.001.14, Nachrichtenset zuletzt geändert am 19.03.2026)
- •Ethereum Improvement Proposals – ERC-20: Token Standard (EIP-20) – (englisch; Ereignis Transfer und Angabe decimals)
- •Bundesministerium der Justiz – Handelsgesetzbuch, § 239 Führung der Handelsbücher
Stand: 25.09.2026