GoBD explained
GoBD stands for "Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff" - the principles for properly keeping and retaining books, records and documents in electronic form, and for data access. The name is unwieldy; the substance is not. It comes down to one question: can a tax authority, years later, still reconstruct how a number in your books came to be?
The GoBD are not a law of their own. They are an administrative letter from the Federal Ministry of Finance interpreting how the existing bookkeeping duties under the German Fiscal Code (§§ 140 to 148 AO) and the Commercial Code (§ 239 HGB) apply to electronic bookkeeping. The version that governs today is dated 11 March 2024, applicable to tax periods from 1 April 2024, supplemented by a further BMF letter of 14 July 2025.
What the GoBD actually require
At the core sit a handful of principles that every entry has to satisfy:
Traceability. A qualified third party must be able to review the transaction in reasonable time, without you sitting beside them explaining it. That is the single most important sentence in the whole framework, and the one most home-built spreadsheet setups fail.
Completeness, accuracy, timeliness, order. Every transaction is recorded, valued correctly, booked promptly, and filed in an orderly way.
Immutability. This is widely misread. It does not mean an entry can never be corrected. It means a correction must not make the original content disappear: the earlier version has to stay visible, and the change has to be logged. A system where a value can be silently overwritten violates this principle, regardless of whether anyone ever actually overwrote anything.
Retention. Something changed here on 1 January 2025 that many people have not caught up with: the Fourth Bureaucracy Relief Act cut the retention period for booking receipts from ten years to eight. Ledgers, inventories, annual financial statements and management reports remain at ten years. The reduction applies to receipts whose ten-year period had not yet expired when the law took effect. So anyone still saying a flat "everything for ten years" is now wrong, and anyone saying a flat "everything for eight" is wrong too.
Why this weighs differently for stablecoin payments
With a conventional bank transfer, the bank quietly supplies a large share of what the GoBD demand: a statement, a value date, an amount in euros, a document nobody had to manufacture.
With a payment in USDC or EURC, that bank does not exist. What exists is a transaction hash, an amount in a non-euro unit, and a timestamp. The euro value does not exist on its own; it is produced, by choosing a rate source at a specific moment. That act of production is precisely where traceability either gets documented or is lost forever.
There is an irony here that usually gets missed in the debate. The blockchain transaction itself is already immutable, in a sense few accounting systems ever achieve. But what is immutable is only the payment event. The booking derived from it is a separate piece of work: valuation, account mapping, VAT logic, approval. Whether that booking satisfies the GoBD is decided not by the chain, but by the system that produces and logs the booking.
In practice this means four pieces of information belong on every on-chain entry, permanently, not in a side note:
- The transaction itself: hash, sender address, timestamp.
- The rate source with timestamp, from which the euro value came.
- The rule applied, or the reasoning behind the account mapping.
- Who approved the entry and when, and what it said before, if it changed.
Miss any one of the four and the entry cannot be reconstructed years later, which is exactly what a tax audit asks for.
What "GoBD-compliant" means, and what it does not
One point we will state plainly, against our own marketing interest: "GoBD-compliant" is not a certification. No official body certifies software as GoBD-compliant, and a private vendor's seal is not a commitment from the tax office. What does exist are procedural documentation (Verfahrensdokumentation) and auditor opinions on the design of one specific implementation.
When software advertises itself as "GoBD-compliant," that describes, at best, a design goal: that the system is built so it can uphold the principles above. Whether a given set of books is actually proper depends on the process around the tool, not only on the tool.
That applies to Stablewerk exactly as stated, without varnish: the architecture is built toward these principles (append-only logging, rate source and rule attached to every entry, logged revisions instead of silent overwrites). There is no auditor's opinion and no DATEV partnership at this point. Anyone who needs a formal assurance should settle that with their own tax firm and, where appropriate, an auditor, not with a marketing claim.
Frequently asked questions
Do the GoBD apply to small businesses and cash-basis accounting (EÜR)? Yes. The GoBD apply regardless of size or legal form, including to cash-basis filers. The extent of what is required scales with the complexity of the business, but the principles themselves apply to everyone.
Is a spreadsheet enough? On its own, generally not, because a spreadsheet does not satisfy immutability: a value can be overwritten with no trace of the prior state and no log of the change. A spreadsheet can serve as a feeder system only where a documented procedure around it ensures immutability, which usually costs more effort than the alternative.
How long do records for crypto payments have to be kept? Booking receipts for eight years since 1 January 2025; books and annual accounts still ten. The transaction hash alone does not constitute the record; what must be retained is the full documentation, including rate source and rule mapping.
Is a blockchain explorer sufficient as evidence? Not on its own. An explorer proves a transaction occurred. It does not prove at which rate it was valued, under which rule it was booked, or who approved it. Beyond that, an external service that could be shut down tomorrow is not a suitable place to retain documents subject to an eight-year obligation.
What happens if an entry has to be corrected later? It may be corrected. The original entry has to remain visible, and the correction has to be logged with its timestamp and author. Silent overwriting is the actual violation, not the correction itself.
This post is part of a glossary series covering the terms that come up constantly in crypto bookkeeping: SKR03, GoBD, EXTF, debit and credit, reverse charge. It is not tax advice. How any of it applies to a specific case belongs with your own tax firm.