Warum das jetzt möglich ist
Bis vor kurzem war der Beleg hinter einer Zahlung ein Dokument für Menschen. Das Wachstumschancengesetz hat das geändert: Seit dem 01.01.2025 muss jedes inländische Unternehmen im B2B-Bereich strukturierte E-Rechnungen empfangen können. Ab dem 01.01.2027 müssen Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz sie auch versenden, ab dem 01.01.2028 alle übrigen. Kleinunternehmer bleiben vom Versand dauerhaft befreit, Kleinbetragsrechnungen bis 250 Euro brutto ebenfalls.
Das heißt: Die Rechnung hinter einer Stablecoin-Zahlung ist zunehmend ein maschinenlesbares Dokument mit definierter Struktur. Damit lässt sich etwas anfangen, das mit einer PDF nicht ging.
Was verbunden wird
Drei Dinge, die sonst nur durch das Gedächtnis eines Menschen zusammenhängen. Die E-Rechnung wird über den SHA-256 ihrer exakten Bytes identifiziert, die Zahlung über ihren Transaktions-Hash, die Buchung über ihren Eintrags-Hash im Prüfpfad. Alle drei stehen in einem einzigen Eintrag.
Der Unterschied, auf den es ankommt
Der Verweis auf die Rechnung liegt innerhalb des gehashten Eintrags, nicht daneben. Das klingt nach einem Implementierungsdetail und ist der ganze Punkt. Läge er daneben, könnte man nachträglich eintragen, eine Zahlung habe eine andere Rechnung beglichen, ohne dass ein einziger Hash bricht. Liegt er darin, bricht genau dieser Austausch jeden folgenden Hash der Kette.
Rückwärtskompatibel ist es trotzdem: Buchungen, die ohne Beleg entstanden sind, behalten exakt den Hash, mit dem sie geschrieben wurden. Eine Erweiterung des Datensatzes darf niemals die Vergangenheit entwerten.
Was geprüft wird, und was benannt statt geglättet wird
Eine passende Rechnung macht eine Buchung belegt, nicht richtig. Deshalb liefert die Prüfung eine Liste von Abweichungen und kein Ja oder Nein:
| Betrag | Rechnungssumme gegen den gebuchten Bruttobetrag, mit zwei Cent Toleranz. Eine On-Chain-Abrechnung kann runden; alles darüber ist eine echte Abweichung und wird benannt. |
| Währung | Ist die Rechnung in einer anderen Währung ausgestellt als gebucht wurde, steht das im Befund und wird nicht stillschweigend umgerechnet. |
| USt-IdNr des Empfängers | Der Punkt, an dem sich die Prüfung rechnet. Regel 13.1 stellt eine Leistung nur deshalb ohne Umsatzsteuer, weil eine USt-IdNr vorliegt. Nennt die Rechnung eine andere Nummer oder gar keine, ruht die Nullbesteuerung auf einer Angabe, die im Dokument des Kunden nirgends auftaucht. |
| Rechnungsnummer | Ohne Nummer lässt sich der Beleg in den Büchern nicht referenzieren, und genau das verlangt die Belegverknüpfung. |
Was ein Prüfer davon hat
Auf die Frage, welche Rechnung eine Zahlung beglichen hat, lautet die Antwort nicht mehr "die liegt im Ordner", sondern: hier ist der SHA-256, der zum Zeitpunkt der Buchung festgehalten wurde, rechnen Sie ihn selbst nach. Und weil der Verweis im Hash liegt, ist zugleich belegt, dass Beleg und Buchung seither nicht getrennt oder vertauscht wurden.
Was heute noch nicht da ist
Die Verknüpfung ist implementiert und getestet, aber im Dashboard gibt es dafür noch keine Bedienoberfläche: Belege werden derzeit programmatisch verbunden, nicht per Klick hochgeladen. Buchungen ohne Beleg bleiben ausdrücklich zulässig. Wir schreiben das hierhin, weil eine Oberfläche zu behaupten, die es nicht gibt, genau das Argument zerstören würde, das diese Seite macht.
Wenn Sie E-Rechnungen bereits strukturiert empfangen und Zahlungen on-chain eingehen: Schreiben Sie uns, wie Ihr Abgleich heute läuft. Wir antworten persönlich.
Rechtsgrundlagen: Wachstumschancengesetz (E-Rechnungspflicht, in Kraft seit 01.01.2025, Übergangsfristen bis 01.01.2028), strukturierte Formate nach EN 16931 (XRechnung, ZUGFeRD), GoBD zur Belegsicherung und Belegverknüpfung, UStG § 3a Abs. 2 und § 18a für die Nullbesteuerung, auf die sich die USt-IdNr-Prüfung bezieht. Diese Seite beschreibt eine Funktionsweise und ist keine Rechts- oder Steuerberatung.