CARF und DAC8: Fünf Tests für Ihre Reporting Readiness
4. Oktober 2026 · Niko Sievert
Eine Meldedatei kann formal sauber sein und trotzdem systematisch falsch: weil ein Dienst bei der Reporting-Abgrenzung übersehen wurde, eine steuerliche Nutzerentscheidung nie überprüft wurde oder ein Transaktions-Feed fehlt. Wo dieselbe fehlerhafte Regel wiederholt angewendet wird, reicht das Problem über einzelne Datensätze hinaus. Eine rein technische Dateivalidierung bietet dagegen keine Gewähr.
Die folgenden fünf Tests setzen genau dort an. Sie fragen nicht nur, ob eine Datei entsteht, sondern welche Fehler sie verbergen würde. Es sind Vorschläge für interne Kontrollen, keine gesetzlich vorgeschriebene Testfolge. Sie lassen sich wiederholen, wann immer sich Produkte, Datenstrecken oder Regeln ändern.
Der Rahmen in Kürze
CARF ist der OECD-Standard für den automatischen Informationsaustausch über Kryptowerte. In der EU führt DAC8 – die Richtlinie (EU) 2023/2226 – entsprechende Sorgfalts- und Meldepflichten ein, im Kern in Anhang VI der geänderten Amtshilferichtlinie 2011/16/EU. DAC8 knüpft dabei an die Krypto-Dienstleistungen der MiCA-Verordnung an und erfasst auch Betreiber ohne MiCA-Zulassung. Für die Einordnung als meldender Anbieter ist entscheidend, ob die Dienste Tauschtransaktionen für oder im Auftrag meldepflichtiger Nutzer bewirken.
Ein Unterschied zum CRS-Grundmodell ist für den Readiness-Check besonders wichtig: Die Krypto-Meldepflicht nach DAC8 erfasst grundsätzlich auch meldepflichtige Nutzer, die im selben EU-Mitgliedstaat wie der meldende Anbieter steuerlich ansässig sind. Wer aus seiner CRS-Praxis einen ausschließlich auf ausländische Steueransässigkeiten ausgerichteten Meldebestand übernimmt, greift deshalb zu kurz.
Die ersten DAC8-Meldungen betreffen grundsätzlich das Kalenderjahr 2026; andere CARF-Staaten starten teilweise später. Maßgeblich für die konkreten Pflichten und Fristen ist die nationale Umsetzung. Parallel wurde der CRS unter anderem um bestimmte E-Geld-Produkte und digitale Zentralbankwährungen erweitert. Eine CRS-Prüfung ersetzt jedoch keine Prüfung der Krypto-Meldung.
Test 1: Anbieter, Dienst und Produkt abgrenzen
Fehlerbild: Eine Wallet erhält eine integrierte Swap-Funktion. Das Produkt geht live, die dokumentierte Scope-Entscheidung bleibt unverändert. Der neue Dienst wird bei der Datenausleitung nicht berücksichtigt. Ist er meldepflichtig, fehlen die zugehörigen meldepflichtigen Transaktionen in der Meldung.
Warum systemisch: Der Fehler entsteht vor der eigentlichen Meldelogik – bei der Frage, welche Dienste überhaupt in das Reporting einfließen. Kontrollen, die erst am bereits abgegrenzten Meldebestand ansetzen, übernehmen diesen blinden Fleck.
Leitfrage: Stimmt die dokumentierte Scope-Entscheidung noch mit dem überein, was tatsächlich angeboten wird – und welche Gesellschaft bewirkt den Tausch für wen? Weder fehlende Verwahrung noch das Etikett „DeFi“ entscheiden für sich genommen über die Meldepflicht. Bei Grenzprodukten ist zusätzlich der CRS-Bezug zu klären.
Test 2: Nutzerentscheidungen über den Lebenszyklus verfolgen
Fehlerbild: Ein Nutzer meldet einen Umzug ins Ausland, bei einem Unternehmenskunden wechselt die beherrschende Person. Das KYC-System übernimmt die Änderung, eine Überprüfung der steuerlichen Einstufung wird jedoch nicht ausgelöst.
Warum systemisch: Eine vollständige KYC-Akte belegt noch keine zutreffende steuerliche Einordnung. Fehlt die Verbindung zur steuerlichen Prüfung, bleibt dieselbe Fehlerursache bei jeder vergleichbaren Änderung bestehen. Auch die Verfahren für neue und vorbestehende Nutzer müssen jeweils funktionieren.
Leitfrage: Wenn Angaben fehlen, sich widersprechen oder sich ändern – wo wird das erkannt, wer entscheidet, und kommt die Entscheidung tatsächlich in der Reporting-Verarbeitung an? Ein neuer Nutzer, ein vorbestehender Nutzer und ein Fall mit geänderten Umständen liefern dafür unterschiedliche Perspektiven.
Test 3: Einen Nutzer unabhängig nachrechnen
Fehlerbild: Eine Mapping-Regel ordnet Übertragungen der falschen Transaktionsart zu. Die Datei ist formal korrekt, die Summen wirken plausibel – die Zuordnung ist dennoch falsch.
Warum systemisch: Die Transaktionsangaben werden grundsätzlich nach Kryptowert und Kategorie aggregiert. Die Summe legt den Zuordnungsfehler nicht offen. Dieselbe Regel wiederholt ihn bei allen betroffenen Ereignissen.
Leitfrage: Kommt man für einen meldepflichtigen Nutzer und eine bestimmte Periode, ausgehend von den Originalereignissen und unabhängig vom Reporting-Modul, zum selben Ergebnis? Falls nicht: Liegt die Ursache in den Ausgangsdaten, ihrer Bewertung oder ihrer Zuordnung? Ein sauberer Abgleich beantwortet diese Frage für den geprüften Ausschnitt, nicht für den gesamten Meldebestand.
Test 4: Die Vollständigkeit des Ausgangsbestands hinterfragen
Fehlerbild: Ein Transaktions-Feed wurde nie an die Reporting-Strecke angeschlossen. Meldung und Ausgangsbestand stimmen überein – weil beiden derselbe Feed fehlt.
Warum systemisch: Ein Abgleich auf derselben unvollständigen Datenbasis bestätigt die Übereinstimmung und lässt die Lücke unsichtbar. Auch eine fehlerfreie Rechnung beantwortet deshalb noch nicht die Frage, ob alle relevanten Quellen berücksichtigt wurden.
Leitfrage: Woher wissen Sie für eine ausgewählte Kategorie und Periode, dass Ihr Ausgangsbestand vollständig ist – und worauf stützt sich eine Bestätigung außerhalb der Reporting-Funktion? Abweichungen gehören bis zu ihrer Ursache verfolgt, nicht in einen Ausgleichsposten.
Test 5: Den Ablauf samt Korrektur durchspielen
Fehlerbild: Ein falscher Ausgangsdatensatz wird korrigiert. Die Änderung erreicht die Quelldatenbank, wird aber im nächsten Meldeentwurf nicht berücksichtigt.
Warum systemisch: Die Korrektur an der Quelle beseitigt den Fehler in der Meldung noch nicht. Ohne verlässliche Weiterverarbeitung bleiben bereits erkannte Fehler bestehen. Ein technisch akzeptierter Entwurf beweist weder den richtigen Scope noch vollständige Eingangsdaten.
Leitfrage: Wird eine in einem Testlauf bewusst eingebrachte Korrektur in den betroffenen Verarbeitungsschritten und im neu erzeugten Entwurf richtig berücksichtigt – und lässt sich später belegen, wer was auf welcher Grundlage entschieden hat?
Von der Stichprobe zur gezielten Verbesserung
Der Wert dieser Tests liegt darin, hinter einzelnen Auffälligkeiten wiederkehrende Ursachen zu erkennen. Ein fehlender Feed, eine falsche Zuordnungsregel oder eine unterbrochene Aktualisierung verlangt jeweils eine andere Antwort. Die Tests liefern Ansatzpunkte für diese Untersuchung, ohne eine vollständige Compliance-Prüfung zu ersetzen.