Data Standard & Account Statement

Every morning the ERP system of a valve manufacturer reads in the statements from its banks. It matches the entries against open items, and whatever does not fit goes onto a list for clarification. Since the company started invoicing part of its business in euro stablecoins, it runs an account for which no statement arrives: its wallet. Payments come in and go out there, but nobody puts them into the format the accounting team reads in.

This knowledge hub calls that missing statement an On-Chain Bank Statement (OCBS). The term was coined by Wolfram Menser and has appeared here since January 2026; it is not a standard. It means an account statement built from the events on the blockchain and modelled on camt.053, the end-of-day statement under ISO 20022. How close it gets to its model is decided field by field. Some fields can be filled directly, others only with a decision by the company, and for one the blockchain supplies nothing at all.

What an End-of-Day Statement Carries

In the ISO 20022 catalogue, camt.053 belongs to the message set Bank-to-Customer Cash Management. The current version is number 14, and the catalogue gives 19 March 2026 as its last update. The schema sets out which details are mandatory and how long a field may be.

A statement has three layers. At the top are the account and at least one balance, each with type, amount and date. Below that come the entries. Mandatory for each entry are the amount with currency, the credit or debit indicator, a status and a code classifying the type of transaction. Booking date, value date, a reference from the account servicer and charges are provided for but optional.

The third layer holds the details per transaction. Here are the parties with name and account, the references from the order through to the credit, and the remittance information, either free text in lines of 140 characters or structured. Matching against open items depends on these details.

Two siblings belong to the same set. camt.052 reports entries during the day, camt.054 a single credit or debit. Both use the same structure for an entry as camt.053. For an OCBS this is useful: the same translation of an event serves the immediate notification and the statement at the end of the day.

What the Blockchain Supplies

For a euro stablecoin on Ethereum, every transfer leaves an event called Transfer. The standard for such tokens, EIP-20, requires it to fire on every transfer, even when the amount is zero. The event carries exactly three values: sender, recipient and amount. The amount is an integer; how many of its digits are decimals is set by each token itself.

Around the event, the blockchain records further details. They include the transaction hash, the block number, the position of the event within that block and the time the block was formed, as a Unix timestamp. An address is 20 bytes, 42 characters in the usual hexadecimal notation. A transaction hash is 32 bytes, so 66 characters.

The event carries no remittance information. There is no field for it, and no invoice number travels with the payment.

Field by Field

Placing both sides next to each other shows where the translation runs smoothly and where it needs a decision. The limits in the second column come from the camt.053 schema, version 14.

Three rows go beyond a mere question of format. The reference does not fit, and it is precisely the key with which an auditor finds the entry on the blockchain again. The currency is not a currency in the ISO 4217 sense but a token with its own issuer. And the remittance information is missing entirely, which strikes at the heart of matching.

Part of the gap is closed by the travel rule, but only where service providers are involved. When a transfer runs between two crypto-asset service providers, they transmit, under Regulation (EU) 2023/1113, among other things the names of sender and recipient and their addresses, separately from the blockchain. If such a provider runs the company's wallet, it can fill the parties in the statement with names. Remittance information is not among these details. If details are missing, the provider may hold back the payment until they are supplied. It has then arrived on the blockchain but is not yet available, and the OCBS needs a status that the block timestamp does not know. Which details the rules require is described in Cross-Cutting: Compliance & Reporting.

A Day with One Receipt and One Payment

In the morning a customer of the valve manufacturer pays two invoices totalling 18,400 euro stablecoins. On the blockchain there is one event with the customer's address, the manufacturer's address and the amount. Which two invoices are meant is recorded nowhere. Accounting can only match by amount and sender, and that only works if the customer's address is held in master data. How addresses and counterparties are maintained is described in Master Data, Privacy & Security, and matching without an invoice number in Reconciliation & Payment Flows. The manufacturer pays no network fee here, because the fee is borne by whoever sends the transaction.

In the afternoon the manufacturer pays a supplier 6,250 euro stablecoins. Now it is the sender and bears the fee. The fee is due not in euro stablecoins but in ether, the network's currency. The stablecoin balance falls by the purchase price, and a second balance on the same address falls by the fee. The OCBS for this day therefore contains two statements, one per balance, just as a bank sends a separate statement for a foreign currency account. The schema allows several statements in one message. How purchase price and fee are posted is described in Posting, Valuation & Tax.

One peculiarity only shows when something goes wrong. According to the Ethereum documentation, the fee is due even when a transaction fails. If the payment to the supplier fails, the ether statement shows a debit for which there is no entry in the stablecoin statement. Accounting has to be able to see that the two belong together. The transaction hash achieves this, provided it appears in both entries.

Three Decisions Nobody Takes Off Your Hands

A bank sets the booking date itself. With an OCBS the company has to define it. A block timestamp is Unix time and therefore UTC. In summer a payment at 23:30 UTC already falls on the next day in Germany, at 1:30 Central European Summer Time. Whether the statement cuts by UTC or by German time is a decision that has to apply to every statement in the same way.

The second decision concerns the status. A payment is not final the moment it appears in a block. The company decides from how many confirmations an entry counts as booked; the reason is described in How Does a Blockchain Work?. Until then the entry appears in the statement as provisional.

The third is the evidence. Unlike with a bank statement, any third party can look up the entry, using a block explorer and the transaction hash. For this to work during an audit, the hash has to appear in the statement in full, not cut to 35 characters. How the statement is then archived so that it cannot be altered is described in Treasury, Risk & Reporting.

What the German Commercial and Fiscal Codes Require

Section 239(2) of the German Commercial Code requires entries and records to be complete, correct, timely and orderly. Under subsection (3), an entry must not be altered in a way that makes its original content impossible to establish. The German Fiscal Code governs retention in section 147(3): books for ten years, accounting vouchers for eight. Section 147(1) no. 1 expressly counts among the books the working instructions and organisational documents needed to understand them.

For an OCBS this is not a side note. A statement generated from the blockchain can be regenerated at any time and checked against the original. That only works with the same decisions on day cut-off, confirmations, currency code and rounding. If one of them changes, the same events produce a different statement. Which category of section 147 of the Fiscal Code these documents fall into is for the company to settle with its tax adviser or auditor. The same applies to how the statement is treated as a voucher.

The Statement Needs an Issuer

For a bank account the account servicer issues the statement, and accounting trusts it because it trusts the bank. For a wallet there is no such account servicer. Even so, the gaps in the table do not separate a wallet from a bank account in principle. Each has a known answer: the hash in the additional information, a code of one's own for the token, the name from master data, a fixed day cut-off. What is missing is someone who performs this translation the same way every day. That can be a custodian that runs the wallet, an add-on to the ERP system or a program of the company's own. One implementation is HashBuch by Setrion GmbH, which also operates this knowledge hub. From the events of a wallet it generates a statement with opening and closing balance and the transaction hash per entry, and it transfers the postings to the ERP system. With the statement, this supplier takes over the position that the bank holds today. It sets the decisions described in this article, and with them what accounting takes to be the balance of its account.