Reverse charge explained
Reverse charge means the invoice goes out without VAT, and the customer accounts for the transaction in their own country. The tax does not disappear; the person who owes it changes.
For a German business supplying services to business customers elsewhere in the EU, this is the normal case rather than the exception. And for companies paid in stablecoins it is especially common, since the customers rarely sit in the same country anyway.
What actually happens
For a service supplied to a business in another EU country, the place of supply moves to where the customer is (§ 3a (2) UStG). The consequence: the transaction is not taxable in Germany. You show no German VAT because there is none to show.
The customer reports it in their own country under that country's implementation of Art. 196 of the VAT Directive, owes the tax there, and in most cases deducts it again as input tax in the same breath. Economically it is often a wash for them; administratively it is an obligation.
The invoice has to carry a note that the tax liability is reversed, and both VAT identification numbers belong on it (§ 14a (1) UStG).
The provision that is almost always cited wrongly
Here is a mistake remarkably widespread in accounting software, blog posts and account labels, and one we had sitting in our own rulebook until today: § 13b UStG is the wrong provision for the sales case.
§ 13b governs when the recipient owes German VAT. It applies when a German business buys a service from abroad. Someone selling and being paid is not the recipient but the supplier, and for them § 3a (2) UStG governs the place of supply, together with § 18a UStG for the filing.
For the booking itself this changes nothing. For the justification produced years later it changes everything: an entry documented under the wrong provision describes a different transaction from the one that happened. So we raised our rule 13.1 to version 3 on 3 September 2026. The journal entry is unchanged, the legal basis is corrected, and older entries visibly keep their old version rather than being retroactively tidied.
The booking is the easy part
1370 Verrechnung Krypto S 8.400,00
8336 Erlöse sonst. Leistung EU (RC) H 8.400,00
Two lines, no VAT account, because no German VAT arises.
A note on the account: in SKR03, 8336 is in full "Erlöse aus im anderen EU-Land steuerpflichtigen sonstigen Leistungen, für die der Leistungsempfänger die Umsatzsteuer schuldet" - revenue from services taxable in another EU country where the recipient owes the VAT. It is explicitly not the account for intra-community supplies of goods, which work differently. That was mislabelled on our side until the same day: right account number, wrong description. Anyone selling goods rather than services is in the wrong place with 8336.
The hard part: the recapitulative statement
Now the point most descriptions of reverse charge leave out, even though it is the actual work.
Every service invoiced this way triggers a Zusammenfassende Meldung (recapitulative statement, the EC Sales List equivalent) under § 18a UStG. In it you report to the Federal Central Tax Office which customer, under which VAT identification number, received what value of services from you. That filing is the cross-check: the tax authority in your customer's country reconciles whether what they declared matches what you reported here.
From that follows a requirement no bookkeeping logic can substitute for: you need your customer's valid VAT ID, and you need it at the time you supply the service. Without it you cannot file, and without it the treatment without VAT is, in case of doubt, not defensible either. A qualified confirmation check with the Federal Central Tax Office, documented with its date, is the usual evidence that the number was valid when the supply happened.
With on-chain payments this gets more awkward than usual. A wallet address carries no VAT identification number. Anyone who does not maintain a clean mapping from address to customer ends the year with amounts on 8336 that cannot be reported, because the number was never captured.
And here we are not finished ourselves: Stablewerk currently captures no VAT ID for a counterparty. The rule books to 8336 once a human has confirmed the counterparty as an EU reverse-charge case, but the number, without which the filing is impossible, appears nowhere in the system. That is a gap in the product rather than a matter of wording, and it belongs to the things that get closed before a first real client, not after.
Frequently asked questions
Does reverse charge also apply to private customers in the EU? No. Reversing the liability requires a business recipient. Different rules apply to private customers, in some cases taxation in the customer's country through the One-Stop-Shop scheme.
What about customers outside the EU? Then the transaction is usually not taxable domestically either, but it is not a reverse-charge case in the EU sense and no recapitulative statement arises. In SKR03 such revenue runs through a different account than 8336.
Does payment in USDC or EURC change anything about VAT? No. VAT treatment follows the supply relationship, not the means of payment. The payment method only changes how hard the documentation is to reconstruct.
What happens if the customer's VAT ID was invalid? Then the treatment without VAT is in question, and in the bad case you owe the tax yourself despite never having collected it. That is exactly why a documented check at the time of supply, rather than at the audit, is where this is decided.
This post closes the 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 a specific case is classified belongs with your own tax firm.