Zum Hauptinhalt springen

Datenstandard & Kontoauszug

Wie aus den Ereignissen auf der Blockchain ein Kontoauszug nach dem Muster von camt.053 wird: welche Felder sich füllen lassen, welche eine Festlegung brauchen und welches fehlt.

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 AuszugGrenze im SchemaVon der BlockchainWas offen bleibt
KontokennungIBAN oder bis 34 ZeichenAdresse mit 42 Zeichenpasst nicht; das Konto braucht eine eigene Kennung, die Adresse steht in der Zusatzinformation
Währunggenau drei GroßbuchstabenAdresse des Token-Kontraktskein Code nach ISO 4217 für den Token; das Unternehmen legt einen fest
Betragbis fünf Nachkommastellenganze Zahl, Stellen je TokenEther rechnet mit 18 Stellen; was darunter liegt, fällt beim Runden weg
BuchungstagDatum oder ZeitpunktZeitstempel des Blocksdie Tagesgrenze
StatusPflichtfeldZahl der Bestätigungenab wann ein Umsatz als gebucht gilt
Referenzbis 35 ZeichenHash mit 66 Zeichen und Position im Blockpasst nicht; Zusatzinformation mit bis zu 500 Zeichen oder ergänzende Daten
BeteiligteName und KontoAdresse des Gegenübersder Name kommt aus den Stammdaten
Verwendungszweck140 Zeichen je Zeile oder strukturiertnichtsfehlt
Art des GeschäftsPflichtcodenichtsein eigener Code, das Schema lässt ihn zu
EntgelteBetrag je UmsatzNetzgebühr in Ether, nur beim Absenderein 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

Stand: 25.09.2026

←Zurück zur Integrations-Übersicht