Every blockchain transaction, accounted for. Reported. Recorded. Proven.
For MiCAR-licensed providers and for companies paid in stablecoins: the DAC8 report to the German tax office, the books in DATEV, the evidence for the auditor. One engine, where every entry carries its rule, its legal basis and its rate source.
From a wallet address to the DATEV batch and the DAC8 file, every step at reading pace.
The real dashboard on a public wallet, nothing mocked: sync, the refusal, the booking, the entry an auditor reads, the export, then the self-certification, the CARF file and the DIP envelope. Captions, no voice.
Read what the film says
- 0:00Every blockchain transaction, accounted for. Reported. Recorded. Proven.
- 0:00A wallet delivers a hash, an amount, a time. Nothing else.
- 0:00No bank statement. No journal entry. No record.
- 0:00German books need from it: a euro value at the market rate (BMF 06.03.2025, Rz. 43); an account and a VAT rate; a rule with its paragraph; a record, kept eight years (section 147 AO); an audit trail a third party can follow (GoBD).
- 0:00And for crypto-asset service providers, two deadlines already running. self-certifications of existing customers; first DAC8 report to the BZSt, reporting period 2026.
- 0:40The overview: wallets, booked entries, open items, chain status.
- 0:44Account 1370 is flagged unverified from day one. On purpose: no tax firm has confirmed it yet.
- 1:00A public address is enough. No keys, no signing rights, no access to funds.
- 1:14The valuation method is a decision, not a default: Kraken daily close, or 1 USDC = 1 USD at the ECB reference rate.
- 1:26This wallet goes back to 2022, further than the platform's rate history. So the ECB route (BMF 06.03.2025, Rz. 43 and 91).
- 1:35Recorded with name and time. The audit report shows the month it applies from.
- 1:50Sync reads the chain and fetches the day's rate. Nothing more.
- 1:55280 transactions. Booked: zero. The system does not guess.
- 2:11143 of them are dust: spam tokens below the materiality threshold.
- 2:22One click rejects them. Each rejection is a decision with a name and a time. Nothing is booked.
- 2:29A real inbound payment: 21,632 USDC, in euro at the day's ECB rate.
- 2:40The customer is an EU business, reverse charge, and by mistake 19 % VAT.
- 2:55No rule matches. It would rather book nothing than book it wrong.
- 3:07Corrected to 0 % with the customer's VAT-ID.
- 3:26Booked under rule 13.1, version 3: section 3a(2) UStG, place of supply with the customer.
- 3:35The entry an auditor would read.
- 3:41Debit 1370, credit 8336. Both sides checked.
- 3:51The rule at the version it was booked under, with its paragraph.
- 4:02The rate, its source, its time.
- 4:12The hash, recomputed now, not stored.
- 4:23Who approved it, and when.
- 4:39The audit report: chain intact, every rule, every decision. One HTML file for the Betriebsprüfer.
- 4:44Section 2: which rate method applied each month, every deviation named.
- 5:00The month as an EXTF batch. Your tax firm imports it like any other.
- 5:12A closed month is final. Later bookings roll into the next open one.
- 5:26The VAT-ID is remembered. The next payment from this address needs no review.
- 5:42Part two: the DAC8 report. Every user under your own customer reference.
- 6:00Pre-existing customer: the self-certification is due by 01.01.2027. After that the BZSt escalation runs.
- 6:17The self-certification as CARF Section II.B describes it: residences, TINs, and for a passive entity its controlling persons.
- 6:56Controlling person 1: address, birth data, residence with TIN, role from the CARF list.
- 7:32Controlling person 2, resident in Switzerland.
- 8:12Reliable. Reportable to NL. Switzerland: open, no confirmed partner state.
- 8:23The Belgian TIN passed its check digit. The Swiss one is structure only, and the finding says so.
- 8:40No official list of partner states exists. Here is what is on record, per state.
- 8:51The decision is yours, with its source. It is recorded.
- 9:11The reporting provider as it appears in the RCASP element, and the BZSt enablement identity.
- 9:46The year's transactions as CSV. Rows with errors are named, not fixed.
- 10:05The preview: who is in the message, who is not, and why.
- 10:17CARF XML 1.5, checked against the OECD schema, kept with its bytes and DocRefIds.
- 10:36The BZSt's DIP envelope, checked against its schema, with its SHA-256. Unsigned: you sign and send.
- 10:54Marked as filed, with the delivery you submitted. Only that is what the BZSt holds.
- 11:05Corrections build only on filed messages, with the reference the BZSt actually holds.
- 11:18Stablewerk holds no key and sends nothing. That is the architecture.
- 11:23What the tax firm and the auditor receive.
- 11:23EXTF batch: DATEV Kanzlei-Rechnungswesen, Windows-1252
- 11:23Reconciliation report: wallet 48,210.00 · booked 48,210.00 · difference 0.00
- 11:23Audit trail per entry: hash · rate source · rule version · approval
- 11:23Valuation log: rate method per month, deviations named
- 11:23And if someone edits an old entry afterwards?
- 11:23Every change is visible. Nothing is silently overwritten.
- 11:23Reported. Recorded. Proven.
- 11:23Read-only. No keys. No payments.
The payment arrives in minutes. The booking has to hold for years.
Between a wallet and proper financial accounting sits a human with a spreadsheet. Every month.
No bank statement
A wallet produces transaction hashes, not journal entries. No ERP reads a hash, and no bank sends a statement for this payment.
Valuation by hand
Every inflow must be valued in euro at the moment it arrives, with a documented rate source. Today that means: google the rate, open Excel, hope.
Two parallel ledgers
The crypto spreadsheet here, the financial books there. Someone rebuilds the bridge every month, and at year-end nobody trusts it.
Audit questions
Where did this rate come from? Who recorded this entry, and when? Without a complete audit trail, every audit becomes a very long week.
One transaction, from the blockchain to the books.
Read-only throughout: a public address goes in, files come out. No keys, no signing rights, no access to funds. Every step carries its source, so anyone can follow it back.
- 01 · On-chainA payment arrives12,500.00 USDCtx 0x7f3a…c412Base · 14.07.2026, 09:41
- 02 · ValuedEuro value, with its source10,960.10 EUR0.876808 EUR per USDCsource + ECB USD/EUR 14.07.2026
- 03 · RuledA rule decides, with its paragraphRule 12.4 · v3§ 12 Abs. 1 UStGEU revenue · 19 % VAT
- ReportedDAC8 report fileCARF XML1.5 · OECD schema ✓DIPBZSt envelope ✓SHA-256of the unsigned filefor licensed crypto-asset providers
- RecordedDATEV batch, SKR031370 S10,960.108400 H9,210.171776 H1,749.93
- ProvenAudit trail per entryhashe5542c7a…eedbcheckrecomputed ✓approvedK. · 14.07. 10:02
Simplified example: one USDC payment for a sale to an EU business at 19 % VAT. The DAC8 report is the duty of licensed crypto-asset providers for their users; a company paid in stablecoins records and proves.
What German law asks of every blockchain transaction, and what you get back.
The report to the Federal Central Tax Office (BZSt): collect and check self-certifications, TINs (tax identification numbers) and residency, partner states, aggregation per user, CARF XML, the DIP envelope, corrections with their reference. You sign and send the file yourself.
- DAC8 report file
Every inflow valued in euro, with rate source and method per month; own wallets, bridges and lending recognised and never booked as revenue; SKR03 or SKR04, booked to GoBD principles, as an EXTF batch for the tax firm.
- EXTF batch
- Reconciliation report
Evidence chain, audit trail per entry, valuation log, reconciliation of wallet against book. Every reported and every booked figure leads back to its transaction.
- Audit trail per entry
Paid in stablecoins by a business elsewhere in the EU? Add a fifth: the Zusammenfassende Meldung for that quarter, the customer's VAT ID and amount already aggregated, ready for your tax firm to file.
- 01FileCARF XML from your data, checked against the BZSt and OECD schemas, one correction.
- 02WorkflowPlus self-certifications, TIN and residency checks, partner states, the correction ledger.
- 03Back officePlus monthly books into DATEV, the evidence pack, the DORA register.
Terms on request.
Two deadlines already running.
Since 1 January 2026, crypto-asset service providers have been recording their customers' transaction data. The first report goes to the Federal Central Tax Office (BZSt) by 31 July 2027. The reporting period is calendar 2026. What was booked and what was reported then have to match.
EU-wide
The reporting duty follows an EU directive and applies across all member states, not only Germany. Implemented in Germany as the Kryptowerte-Steuertransparenzgesetz.
First reporting period
Transactions occurring in 2026 are captured. Providers must obtain a self-certification from customers onboarded earlier by 1 January 2027, and file with the BZSt by 31 July 2027.
Reconciliation becomes possible
The authority holds the data independently of your books. A traceable derivation for every entry stops being diligence and becomes the baseline.
Your tax firm does not have to learn anything new.
Your tax firm receives the month as a booking batch, a reconciliation report and an audit trail. All three in formats it already reads.
Or skip the monthly handoff: your tax firm can log in directly, any time, for every Mandant you grant them. The seat is free and strictly read-only, they see every booking and the full audit trail, and cannot change anything.
Built like a tool for auditors, not like a crypto product.
Read-only, never moving funds
Stablewerk holds no keys, has no signing rights, and cannot initiate any payment. It reads and it books. Nothing more, by architecture.
Data stays in the EU
Processing and storage exclusively on servers within the EU, GDPR-compliant. Your financial data never leaves Europe.
Deterministic, not AI magic
In the booking path, versioned rules with legal citations decide, never a language model. Same input, same entry, every time, traceable to the rule number.
Chained audit trail
Every entry is cryptographically chained with hash, rate source, rule version and approval. Designed as if an auditor will read it tomorrow.
The questions companies and tax firms ask us first.
Still wondering about something? hello@stablewerk.com, we reply personally.
Does Stablewerk need access to our wallets?
How do the entries reach our DATEV environment?
Which rates are used for valuation?
Is Stablewerk a crypto custodian or payment provider?
Do we have to be a German company?
What separates Stablewerk from a plain DAC8 file generator?
Do we have to take all three parts?
How do I get access, and who is it for?
What is still reconstructed today can be booked from next month.
Onboarding is personal and in small groups: companies with real stablecoin payments, and the tax firms guiding them through it. Free during the pilot phase, preferential terms afterwards, a direct line instead of a ticket system.