Treasury, Risk & Reporting

On the last working day of the month, the valve manufacturer's treasurer presents the liquidity status. Next to the balances at three house banks, new lines have appeared over the past six months. A wallet holds euro stablecoins for supplier payments and ether for network fees. There is also a balance with the payment service provider that accepts payments from the online shop. Added up, it is all liquidity. Legally these are very different claims against very different debtors, and for one holding there is no debtor at all. So far the treasury policy sets a ceiling only for the banks.

Who stands behind each line

A balance at a house bank is a deposit, and deposits are covered by statutory deposit protection. The euro stablecoin, issued as an e-money token, is a claim against its issuer for redemption at par value at any time (Art. 49(4) MiCAR). If the issuer is an electronic money institution, the funds it receives for issuing e-money are not deposits. That is the rule in Section 3(2) of the German Payment Services Supervision Act (ZAG). The condition is that the e-money is issued immediately and bears no interest. Both are the rule for an e-money token, since MiCAR prohibits interest on it. Deposit protection therefore does not apply here.

Other rules provide the protection. Under Art. 54 MiCAR the issuer must hold at least 30 per cent of the funds received for its tokens in separate accounts with credit institutions. It invests the rest in secure, highly liquid assets in the same currency. The valve manufacturer's claim thus depends on two things: the solvency of the issuer and, indirectly, the banks where its reserve is held. How such a token is classified under supervisory law, and where the register of issuers can be found, is described in MiCAR (EU).

For ether there is no issuer and no claim. Its value is the market value on the reporting date, and how it is measured is set out in Posting, Valuation & Tax. The balance with the payment service provider, finally, is money in transit. The duty to protect such amounts is called safeguarding. Section 17 ZAG requires such amounts not to be commingled with other funds. If they are still with the provider after the next business day, they belong in a separate account with a credit institution or in secure assets. Alternatively, insurance or a guarantee covers them. Which route the provider has chosen is stated in the contract, or belongs there.

Limits by debtor, not by technology

The valve manufacturer's treasury policy limits how much money may sit with any single bank. For the stablecoin there is no such limit, because it came into the company as technology and not as a counterparty. Yet the question is the same: how much can be lost if a single debtor fails? This leads to a limit per issuer, one per custodian if a provider runs the wallet, and one for the balance with the payment service provider. The last can be expressed in days of online-shop revenue. How much should sit in the company's own wallet for day-to-day operations, and who may dispose of it, is described in Custody & Safekeeping.

The indirect side belongs in the calculation too. Suppose the issuer holds part of its reserve at the same bank where the valve manufacturer keeps its largest balance. Then the exposure to that bank grows without appearing in any single line. Before setting the limit, it is therefore worth asking the issuer whether and how it discloses these banks.

For the finance director such a limit is cheap. Because the e-money token bears no interest, the company forgoes nothing by holding little of it. A low limit only means exchanging into book money and back more often. A high limit, by contrast, ties up liquidity in a claim without deposit protection, for a benefit that only arises with the next payment.

Wallet against account at month end

At closing, accounting reconciles every bank account: the balance on the statement against the balance of the general ledger account. The same applies to the wallet, except that no account provider supplies the closing balance. It is queried at the last block of the month. Which block that is depends on the day boundary from Data Standard & Account Statement. A payment at 23:30 UTC on the last day of the month already belongs to the next month in German time.

If the holding differs from the ledger account, the reasons are usually known. A receipt is still in the suspense account, as described in Reconciliation & Payment Flows. A payment has taken place on the blockchain but has not yet been posted. Or a network fee has been recorded in the ether account but not in the stablecoin account, where it does not belong either. Each difference needs an explanation in a list, just as with the bank reconciliation. One implementation is HashBuch by Setrion GmbH, which also operates this knowledge hub. It records each wallet's holding once at the last block of the month and compares it with the balance of the matching account in the ERP system.

From journal entry back to hash

Under Section 145(1) of the German Fiscal Code (AO), the accounts must give an expert third party an overview within a reasonable time. Business transactions must be traceable from their origin to their completion. For token payments this means: an auditor takes a journal entry and finds the matching item in the wallet statement. That item carries the transaction hash. With the hash the auditor looks up the transaction on the blockchain directly. The path must also work the other way round. Every event on the blockchain that concerns the company's address must lead to a posting, or to an entry explaining why there is none.

For this path to be traceable, the company's decisions belong with it. In paragraph 151 the GoBD require procedural documentation for every data processing system. It must show content, structure, sequence and results fully and coherently. For token payments these are above all the day boundary, the number of confirmations after which an item counts as booked, the rate source and the reconciliation tolerances. If one of them changes, the change belongs in the documentation with its date. Otherwise a statement from the previous year can no longer be generated from the same events.

What belongs in the archive

The blockchain secures the transaction. It does not secure the statement the company has made from it. According to paragraph 110 of the GoBD, immutability can be achieved through hardware, for instance unalterable and tamper-proof storage media, through software, or organisationally. Storing data in a file system does not as a rule meet the requirement, the same paragraph says, unless additional measures are taken. An archive that does not allow data to be changed once written, WORM storage, does exactly that.

The archive holds the wallet statement, the company's decisions in the version valid at each point, and the exchange rates with source and timestamp. It also holds the history of the master records as described in Master Data, Privacy & Security. A link to a block explorer does not belong there as evidence, however convenient it is in the statement. The explorer is a third party's website, which can change its addresses or shut down. The archive must hold the data itself, including the full transaction hash. With the hash, the transaction can be found again through any other access to the blockchain.

The balance the auditor queries directly

Anyone can query a wallet's balance at the block of the reporting date, the auditor included, without the company in between. For a bank account the auditor relies on a balance confirmation from the bank instead. The international auditing standard ISA 505 describes such an external confirmation as a direct written response to the auditor from a third party. ISA 505 takes over two principles from the general standard: evidence from independent sources outside the entity is more reliable, and so is evidence the auditor obtains directly. A query at the block meets both. It is not a confirmation within the meaning of the standard, and how an auditor weighs it is up to the auditor. What remains open is who owns the address. That is answered by a message the company signs with the address's key as at the reporting date. Together the two pieces do what the letter to the bank does for a bank account, without a third party in between.