Why this is possible now
Until recently the record behind a payment was a document for humans. Germany's Wachstumschancengesetz changed that: since 01.01.2025 every domestic business must be able to receive structured e-invoices in B2B. From 01.01.2027 businesses with more than EUR 800,000 in prior-year turnover must also send them, and from 01.01.2028 everyone else. Small businesses remain permanently exempt from sending, as do invoices up to EUR 250 gross.
Which means the invoice behind a stablecoin payment is increasingly a machine-readable document with a defined structure. That makes something possible which a PDF never allowed.
What gets bound together
Three things that are otherwise related only by somebody's memory. The e-invoice is identified by the SHA-256 of its exact bytes, the payment by its transaction hash, the booking by its entry hash in the audit trail. All three sit in a single entry.
The distinction that matters
The reference to the invoice sits inside the hashed entry, not beside it. That sounds like an implementation detail and it is the entire point. Beside it, one could later record that a payment settled a different invoice without breaking a single hash. Inside it, that exact swap breaks every subsequent hash in the chain.
It remains backward compatible: bookings made without an invoice keep exactly the hash they were written with. A schema addition must never invalidate history.
What is checked, and named rather than smoothed over
A matching invoice makes a booking evidenced, not correct. So the check returns a list of discrepancies rather than a yes or no:
| Amount | Invoice total against the booked gross, with a two-cent tolerance. An on-chain settlement can round; anything beyond that is a real discrepancy and gets named. |
| Currency | If the invoice is denominated differently from the booking, that appears in the findings rather than being silently converted. |
| Recipient's VAT ID | The check that earns its keep. Rule 13.1 zero-rates a supply only because a VAT ID exists. If the invoice names a different one, or none, the zero-rating rests on a number that appears nowhere in the document the customer received. |
| Invoice number | Without a number the document cannot be referenced in the books, which is precisely what the record-linking requirement asks for. |
What an auditor gets from this
Asked which invoice a payment settled, the answer is no longer "it is in the folder" but: here is the SHA-256 recorded at booking time, recompute it yourself. And because the reference sits inside the hash, it is simultaneously shown that record and booking have not been separated or swapped since.
What is not there yet
The linkage is implemented and tested, but the dashboard has no interface for it yet: records are bound programmatically today, not uploaded with a click. Bookings without an invoice remain expressly permitted. This is stated here because claiming a screen that does not exist would destroy the very argument this page makes.
If you already receive structured e-invoices and take payments on-chain: tell us how you reconcile them today. We reply personally.
Legal basis: the Wachstumschancengesetz (e-invoicing duty, in force since 01.01.2025, transitional periods to 01.01.2028), structured formats per EN 16931 (XRechnung, ZUGFeRD), the GoBD on securing and linking records, and UStG sections 3a(2) and 18a for the zero-rating the VAT ID check relates to. This page describes how something works and is not legal or tax advice.