Eine Kartenzahlung erreicht Ihre Bücher über einen Acquirer-Bericht, der die Bestellung bereits nennt. Eine USDC-Überweisung erreicht Sie nur mit einer Adresse, einem Betrag und einem Transaktions-Hash, sonst nichts. Der Abgleich von Krypto-Zahlungen funktioniert, wenn die Rechnung die geschäftliche Referenz enthält, denn die Überweisung kann sie nicht liefern.
Dieser Leitfaden richtet sich an Finanz- und Betriebsteams bei Händlern, Zahlungsdienstleistern (PSPs) und E-Geld-Instituten (EMIs), die Stablecoins annehmen und in Euro abrechnen. Er listet die Felder auf, die jeder Rechnungsdatensatz benötigt, zeigt, wie Teilzahlungen und Zahlungen in der falschen Kryptowährung zu behandeln sind, wie Webhooks und die API das Hauptbuch speisen und welche EU-Regeln bestimmen, wie lange Sie all das aufbewahren müssen.
Wichtige Momente
Kurz gesagt
- Eine ERC-20-Überweisung enthält nur Absender, Empfänger und Betrag. Die Bestellreferenz muss auf der Rechnung stehen, nicht in der Zahlung.
- Bepreisen Sie die Rechnung in EUR und buchen Sie diesen Euro-Betrag. Der Krypto-Betrag ist eine abgeleitete Zahl, die Sie für den Prüfpfad aufbewahren.
- Der größte Teil der Arbeit steckt in den Ausnahmefällen: Teilzahlungen, abgelaufene Rechnungen, die falsche Kryptowährung. Prüfen Sie diese täglich, nicht erst zum Monatsende.
- Nutzen Sie den Webhook als Auslöser, lesen Sie die Rechnung per ID erneut als maßgebliche Quelle und ziehen Sie die Rechnungsliste nächtlich als Sicherheitsnetz und als Quelle Ihres CSV-Exports ab.
Warum ist der Abgleich von Krypto-Zahlungen schwieriger als bei Karten?#
Der Abgleich von Krypto-Zahlungen ist schwieriger, weil eine Blockchain-Überweisung kein Feld für Ihre Bestellnummer hat. Bei Ethereum definiert der ERC-20-Token-Standard (EIP-20) das Transfer-Ereignis als `Transfer(address _from, address _to, uint256 _value)`: Absender, Empfänger und Betrag. Es gibt kein Memo, keine Rechnungsnummer und keinen Kundennamen.
Bank- und Kartenzahlungen sind umgekehrt aufgebaut. Eine SEPA-Überweisung hat ein Verwendungszweckfeld, das der Zahler ausfüllt, und der Abrechnungsbericht eines Acquirers ordnet jede Kartentransaktion Ihrer Händlerreferenz zu. Ihr Buchhaltungssystem gleicht über diese Referenz ab.
Bei Stablecoins kommen drei weitere Probleme hinzu:
- Der Betrag ist selten rund. Eine in USDC bepreiste Rechnung über 250 EUR ergibt eine Zahl wie 279,2846 USDC, sodass zwei ähnlich hohe Rechnungen leicht gleich aussehen können.
- Die Zahlung ist nicht sofort endgültig. Ethereum erzeugt alle 12 Sekunden einen Block, aber laut ethereum.org (Seite aktualisiert im Oktober 2026) „dauert es etwa 15 Minuten, bis ein Ethereum-Block finalisiert ist.“ Eine Überweisung kann sichtbar sein und trotzdem noch nicht zählen.
- Zahler machen Fehler. Sie senden zu wenig, zweimal, eine andere Kryptowährung oder zahlen, nachdem die Rechnung abgelaufen ist.
Die Verknüpfung muss also bestehen, bevor der Zahler bezahlt: eine Rechnung pro Bestellung, mit Ihrer Bestell-ID und einer eigenen Zahladresse, damit jede eingehende Überweisung auf einem Datensatz landet, der bereits weiß, wofür sie bestimmt ist.
Welche Felder benötigt jeder Krypto-Rechnungsdatensatz?#
Jede Rechnung braucht einen festen Satz an Feldern, die vier Dinge miteinander verbinden: Ihre Bestellung, den Euro-Preis, die Überweisung auf der Blockchain und den endgültigen Status. Fehlt eines davon, muss jemand von Hand abgleichen. Die folgende Tabelle verwendet die Feldnamen der ItisPay-Rechnungs-API; andere Anbieter verwenden für dieselben Konzepte andere Namen.
| Feld | Inhalt | Warum die Buchhaltung es braucht |
|---|---|---|
| invoice_id | Vom Anbieter vergebene eindeutige ID | Primärschlüssel für jede Abfrage und jede Hauptbuchzeile |
| order_id | Ihre Bestell- oder Vertragsnummer, eindeutig pro Bestellung | Die Verbindung zu Ihrem ERP, Shop oder CRM; die Referenz, die Kartenzahlungen Ihnen kostenlos liefern |
| order_name | Kurzbeschreibung der Bestellung | Ermöglicht einer Person, eine Ausnahme zu prüfen, ohne den Shop zu öffnen |
| fiat_amount, fiat_currency | Preis in EUR | Der Umsatz, den Sie buchen |
| currency, crypto_amount | Fakturierte Kryptowährung und fälliger Betrag | Zeigt, was der Zahler senden sollte |
| actual_crypto_amount_paid | Was tatsächlich eingegangen ist | Erkennt Unter- und Überzahlungen |
| currency_paid | Verwendete Kryptowährung, falls abweichend von der fakturierten | Markiert Zahlungen in der falschen Kryptowährung zur Prüfung |
| network, address | Blockchain-Netzwerk und Zahladresse | Belegt, wohin das Geld gesendet wurde; nötig für jede Nachverfolgung oder Rückerstattung |
| transactions (tx_hash, amount, status) | Eine Zeile pro eingehender Überweisung | Eine Rechnung kann mehrere Überweisungen erhalten; jeder Hash ist Ihr Beleg auf der Blockchain |
| status | new, pending, completed, expired, cancelled, paid_partial | Entscheidet, ob Sie buchen, versenden, nachfassen oder schließen |
| created_at, updated_at, expires_at | Zeitstempel | Stichtag zum Monatsende und Nachweis, wann die Bestellung bezahlt wurde |
Zwei davon leisten den größten Teil der Arbeit. `order_id` ist die Referenz, die eine Blockchain-Überweisung nicht übertragen kann; setzen Sie sie aus Ihrem eigenen System und machen Sie sie eindeutig pro Bestellung, niemals pro Kunde. Die Liste `transactions` ist wichtig, weil eine Rechnung nicht immer in einem Schritt bezahlt wird: Jede Überweisung erhält eine eigene Zeile mit Hash und Status, sodass Sie sehen, welche Überweisungen den bezahlten Betrag ergeben.
Speichern Sie den Krypto-Betrag mit allen Nachkommastellen in einer separaten Spalte. Ihr Hauptbuch rechnet in Euro-Cent; die Krypto-Spalten sind Belege, keine Buchwerte.
Welcher Euro-Betrag wird gebucht?#
Buchen Sie den Euro-Preis der Rechnung. Wird die Rechnung in EUR ausgestellt, rechnet der Anbieter sie zum aktuellen Kurs in einen Krypto-Betrag um, und der Zahlende überweist diesen Betrag. Wird die Zahlung auf Ihr Konto in Euro abgerechnet, ist der Euro-Betrag auf der Rechnung Ihr Umsatz, und der Krypto-Betrag ist nur ein technisches Detail des Zahlungswegs.
Das ist der Hauptgrund, warum Teams, die Krypto-Zahlungen automatisch mit Umrechnung in EUR annehmen, selten überhaupt Krypto-Buchhaltung benötigen: Es liegt keine Münze in der Bilanz, die zum Monatsende bewertet werden müsste.
Es ändert sich, wenn Sie die Stablecoins behalten. Das IFRS Interpretations Committee entschied im Juni 2019, dass Kryptowährungsbestände unter IAS 2 (Vorräte) fallen, wenn sie im gewöhnlichen Geschäftsverlauf zum Verkauf gehalten werden, und andernfalls unter IAS 38 (immaterielle Vermögenswerte). Seine Definition einer Kryptowährung schließt Vermögenswerte aus, die zwischen dem Halter und einer anderen Partei einen Vertrag begründen. USDC ist anders: Circle erklärt, dass USDC „1:1 gegen US-Dollar einlösbar“ ist, und seit Juli 2024 gibt Circle USDC und EURC in der EU als E-Geld-Token aus, auf Basis einer E-Geld-Lizenz der französischen Aufsichtsbehörde ACPR. Wie ein gehaltener Stablecoin einzuordnen ist, ist eine Frage für Ihren Abschlussprüfer. Die Abrechnung in EUR bei Eingang vermeidet diese Frage.
Wie gehen Sie mit Teilzahlungen und falschen Coins um?#
Behandeln Sie jede Rechnung, die nicht `completed` ist, als Ausnahme mit einem Verantwortlichen und einer Frist. Der größte Teil des Abstimmungsaufwands bei Krypto-Zahlungen fällt hier an; eine vollständig bezahlte Rechnung gleicht sich von selbst ab.
Hier ist die Bedeutung jedes Status für die Buchhaltung, anhand der ItisPay-Status:
| Status | Was passiert ist | Was die Buchhaltung tut | Ausliefern oder freigeben? |
|---|---|---|---|
| new | Rechnung offen, nichts eingegangen | Nichts zu buchen | Nein |
| pending | Eine Überweisung ist eingegangen, noch nicht endgültig | Auf die Statusänderung warten | Nein |
| completed | Vollständig bezahlt | Umsatz zum EUR-Preis buchen, Bestellung freigeben | Ja |
| paid_partial | Ein Teil des Betrags ist eingegangen | Rest nachfordern, erstatten oder einvernehmlich schließen | Hängt ab |
| expired | Zeit abgelaufen ohne vollständige Zahlung | Bestellung schließen; auf verspätete Überweisungen prüfen | Nein |
| cancelled | Sie haben die Rechnung storniert | Keine Buchung; neu ausstellen, falls der Kunde weiterhin zahlen möchte | Nein |
Teilzahlungen#
Eine Teilzahlung bedeutet meist, dass die Wallet oder Börse des Zahlenden eine Gebühr vom Betrag abgezogen hat oder der Zahlende den Betrag falsch eingegeben hat. ItisPay erfasst jede Überweisung separat, sodass eine zweite Überweisung die Rechnung vervollständigen kann. Die Rechnung hat außerdem die Einstellung `allowed_error_percent`: eine kleine Toleranz, die pro Rechnung festgelegt wird, sodass eine Zahlung, die um einen geringen Bruchteil zu niedrig ist, weiterhin als bezahlt gilt. Legen Sie sie einmal als Richtlinie fest, zum Beispiel auf einer Höhe, die Sie auch bei einer Banküberweisung abschreiben würden, und ändern Sie sie nicht von Fall zu Fall.
Kommt der Rest nie an, entscheiden Sie innerhalb einer festen Anzahl von Tagen: Sie akzeptieren den Fehlbetrag und schreiben ihn ab, erstatten den eingegangenen Betrag oder stornieren die Bestellung. Halten Sie die Entscheidung im Rechnungsdatensatz fest, damit der Abschlussprüfer sieht, warum einer bezahlten Bestellung weniger Geld zugrunde liegt.
Falscher Coin oder verspätete Zahlung#
Sendet der Zahlende einen anderen Stablecoin als den in Rechnung gestellten, zeigt das Feld `currency_paid` dies an. Buchen Sie ihn nicht automatisch: Prüfen Sie Betrag und Euro-Wert und akzeptieren oder erstatten Sie ihn dann. Eine Überweisung auf eine abgelaufene Rechnung ist ähnlich. Das Geld liegt on-chain, doch Ihre Bestellung ist geschlossen, also muss jemand entscheiden, ob die Bestellung wieder geöffnet oder das Geld zurückgegeben wird. Wird eine Bestellung auf Ihrer Seite annulliert, storniert man die Rechnung über die API (eine Statusaktualisierung), damit Ihre Unterlagen sie als geschlossen ausweisen, bevor eine verspätete Zahlung eingeht.
Wie sollten Webhooks und die API den Abgleich von Krypto-Zahlungen speisen?#
Verwenden Sie drei Ebenen: Der Webhook teilt Ihnen mit, dass sich etwas geändert hat, ein frisches Abrufen der Rechnung zeigt, was zutrifft, und ein nächtlicher Abruf aller Rechnungen fängt alles auf, was die ersten beiden übersehen haben.
- Jede Rechnung kann eine `callback_url` enthalten; der Anbieter sendet Statusaktualisierungen dorthin. Behandeln Sie die Nachricht als Auslöser, nicht als Beweis.
- Bei jedem Webhook rufen Sie `GET /invoices/{invoice_id}` auf und handeln auf Basis von Status und Beträgen in dieser Antwort. Das schützt Sie vor gefälschten oder wiederholten Aufrufen Ihres Endpunkts, da der API-Aufruf Ihren API-Schlüssel erfordert.
- Machen Sie den Handler idempotent: Derselbe Status kann zweimal eintreffen. Schlüsseln Sie Ihren Buchungseintrag nach `invoice_id` und Status, sodass eine Wiederholung nichts verändert.
- Listen Sie jede Nacht Rechnungen sortiert nach `updated_at` auf, die neuesten zuerst, und blättern Sie bis zu Ihrem letzten Lauf zurück; prüfen Sie außerdem jede Rechnung erneut, die noch `new`, `pending` oder `paid_partial` ist. Gleichen Sie sie mit Ihrem Journal ab. Alles, was in den Unterlagen des Anbieters bezahlt, in Ihren aber offen ist, ist eine Ausnahme.
Zum Testen bietet ItisPay einen Endpunkt, der eine Statusänderung für eine Rechnung simuliert, und einen, der den letzten Webhook anhand von `invoice_id` oder `order_id` erneut sendet. Verwenden Sie das erneute Senden, wenn Ihr Server nicht erreichbar war. Teams, die mehrere Zahlungsmethoden über eine gemeinsame Ebene zur Zahlungsorchestrierung leiten, wenden dasselbe Muster auf jeden Zahlungsweg an.
Wie erstellen Sie einen CSV-Export für die Buchhaltung?#
Erstellen Sie den Export über die API für die Rechnungsliste, mit einer Zeile pro Rechnung plus einer Zeile pro Transfer. Bei ItisPay filtert `GET /invoices` nach Status, Coin und Erstellungsdatum, sortiert nach Datum oder Betrag und liefert bis zu 100 Rechnungen pro Seite zusammen mit der Seitenanzahl. Ein kleines Skript kann die Seiten für einen Tag oder einen Monat durchlaufen und die Spalten aus der Feldtabelle oben schreiben.
Zwei Dateien sind besser als eine:
- `invoices.csv`: invoice_id, order_id, fiat_amount, fiat_currency, currency, crypto_amount, actual_crypto_amount_paid, status, created_at, updated_at. Die Buchhaltung importiert diese Datei und gleicht sie mit den Verkäufen ab.
- `transfers.csv`: invoice_id, tx_hash, amount, currency, transfer status, time. Das ist die Nachweisdatei für den Prüfer.
Importieren Sie die Rechnungsdatei wie einen Kartenabrechnungsbericht in Ihr Buchhaltungstool: eine Zeile pro Bestellung, in Euro, mit der Bestell-ID als Abgleichsschlüssel.
Welche EU-Regeln prägen die Aufzeichnungen zu Krypto-Zahlungen?#
Drei EU-Regeln bilden den Rahmen. Keine davon macht einen Händler zum Anbieter von Kryptowerte-Dienstleistungen (CASP), doch sie bestimmen, welche Daten vorhanden sind und wie lange sie aufbewahrt werden.
- Geldtransferverordnung (EU) 2023/1113. Seit dem 30. Dezember 2024 muss der CASP des Zahlers sicherstellen, dass jeder Transfer von Angaben zum Zahler und zum Begünstigten begleitet wird, etwa Namen und Ledger-Adressen (Artikel 14). Die Daten begleiten den Transfer, sind aber nicht Teil davon. Bei Transfers über 1.000 EUR von oder an eine selbst verwaltete Wallet muss der Anbieter auf der jeweiligen Seite prüfen, ob diese Wallet seinem eigenen Kunden gehört (Artikel 14 und 16). Das ist Aufgabe des lizenzierten Anbieters, und es ist ein Grund, warum eine Zahlung in der Prüfung hängen bleiben kann.
- Aufbewahrung von Aufzeichnungen. Nach der geltenden AML-Richtlinie (EU) 2015/849, Artikel 40, bewahren Verpflichtete Transaktionsaufzeichnungen fünf Jahre lang auf, nachdem die Geschäftsbeziehung endet oder die Transaktion stattfindet. Die neue AML-Verordnung (EU) 2024/1624 behält die Fünfjahresfrist bei (Artikel 77) und gilt ab dem 10. Juli 2027.
- DAC8, Richtlinie (EU) 2023/2226. Ab dem 1. Januar 2026 melden CASP die Krypto-Transaktionen ihrer Nutzer an die Steuerbehörden. Ihre eigenen Aufzeichnungen sollten mit den Meldungen Ihres Anbieters übereinstimmen.
Wenn Sie über einen lizenzierten Partner arbeiten, trägt der Partner die CASP-Pflichten nach MiCA und diesen Regeln, wie in unserem Leitfaden zur MiCA-CASP-Lizenz erläutert. Ihre Bestellaufzeichnungen und Ihren Teil der Nachweiskette führen Sie trotzdem selbst.
Wo braucht der Krypto-Abgleich noch einen Menschen?#
Die Automatisierung übernimmt den Fall der vollständig bezahlten Rechnung. Alles Übrige braucht einen namentlich benannten Verantwortlichen und eine kurze schriftliche Richtlinie.
Wo es nicht hilft
- Rückerstattungen sind neue ausgehende Transfers, keine Stornierungen. Sie brauchen eine Auszahlung an eine Adresse oder IBAN und eigene Aufzeichnungen.
- Ein Zahler, der von einem Börsenkonto aus sendet, lässt sich nicht immer anhand der Absenderadresse identifizieren. Gleichen Sie über die Rechnung ab, niemals über den Absender.
- Zahlungen auf abgelaufene Rechnungen, doppelte Zahlungen und falsche Coins erfordern alle eine menschliche Entscheidung.
- Netzwerkgebühren und Rundungen erzeugen kleine Differenzen. Legen Sie einmal eine Toleranz fest und halten Sie sich daran.
Eine tägliche Routine für den Abgleich von Krypto-Zahlungen in fünf Schritten#
Eine kurze tägliche Routine macht den Monatsabschluss zur Formsache:
- Rufen Sie über die API die Rechnungen ab, die seit dem letzten Lauf erstellt oder aktualisiert wurden, und aktualisieren Sie die Rechnungs- und Transferdateien.
- Prüfen Sie, ob jede `completed`-Rechnung eine passende bezahlte Bestellung in Ihrem Shop oder ERP hat und umgekehrt.
- Arbeiten Sie die Ausnahmeliste ab: `paid_partial`, Zahlungen auf abgelaufene Rechnungen, falsche Coins. Schließen Sie jeden Fall mit einer schriftlichen Entscheidung ab.
- Gleichen Sie die Euro-Gutschrift auf Ihrem Bankkonto mit der Summe der abgeschlossenen Rechnungen des Zeitraums ab. Bei der Gutschrift auf eine IBAN helfen virtuelle IBANs, Zahlungsströme nach Geschäftsbereich zu trennen.
- Archivieren Sie beide Dateien mindestens fünf Jahre lang.
Wenn Sie Stablecoins akzeptieren und Euro erhalten möchten, ohne diesen Stack selbst aufzubauen, stellt ItisPay die API, Rechnungsstellung und Abgleichsdaten bereit: Rechnungs- und Bestell-IDs, Hashes pro Transfer, Status und Webhooks. Lizenzierung, KYC und Gutschrift auf Ihre IBAN laufen über unseren EU-lizenzierten Partner (CASP und Zahlungsinstitut), und die meisten Teams kommen von KYB bis zur ersten Transaktion in weniger als einer Woche.
Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechts- oder Regulierungsberatung dar.
