Im Fokus: Scope, Nutzeridentifikation, Transaktionsdaten, erstes Berichtsjahr 2026 und die Verbindung zum OECD Crypto-Asset Reporting Framework (CARF).
Warum DAC8 für Finance mehr ist als ein Steuerthema
Mit DAC8 erweitert die Europäische Union den automatischen Informationsaustausch im Steuerbereich auf Krypto-Assets. Die Regeln gelten seit dem 1. Januar 2026. Reporting Crypto-Asset Service Providers müssen ab diesem Zeitpunkt relevante Nutzerdaten und meldepflichtige Transaktionen erfassen. Die erste Berichtsperiode ist damit das Kalenderjahr 2026; die Informationen werden im Folgejahr an die Steuerbehörden übermittelt und zwischen den Mitgliedstaaten ausgetauscht.
Das klingt zunächst nach einer Aufgabe für Tax oder Compliance. Operativ liegt die Herausforderung jedoch in den Daten. Kundendaten, Steueransässigkeit, TIN, Asset-Typ, Transaktionsart, Gegenwert und Transferinformationen entstehen in unterschiedlichen Systemen. Ohne abgestimmtes Datenmodell kann ein Reporting-Team am Jahresende nicht zuverlässig rekonstruieren, welche Nutzer und Transaktionen in welchem Umfang meldepflichtig waren.
Wer steht im Mittelpunkt?
DAC8 richtet sich vor allem an Reporting Crypto-Asset Service Providers und bestimmte Crypto-Asset Operators. Der Anwendungsbereich ist bewusst breit und knüpft an Krypto-Assets und Dienstleistungen an, die Transaktionen für Nutzer ermöglichen. Die Richtlinie baut zugleich auf dem internationalen OECD-Standard CARF auf. Dadurch entsteht eine stärkere Verbindung zwischen EU-Regeln und dem globalen Austausch von Steuerinformationen.
Für Unternehmen ist eine saubere Scope-Analyse entscheidend. Nicht jedes Unternehmen, das Kryptowährungen besitzt, wird dadurch selbst zum Reporting Provider. Umgekehrt kann ein Geschäftsmodell in den Anwendungsbereich fallen, auch wenn es nicht als klassische Börse wahrgenommen wird. Services, Nutzergruppen, Zulassungsstatus und die konkrete Rolle bei Exchange- und Transfertransaktionen müssen deshalb dokumentiert werden.
2026 ist das Datenjahr, nicht das Vorbereitungsjahr
Ein häufiger Planungsfehler besteht darin, die erste Meldung 2027 als eigentlichen Projekttermin zu betrachten. Die Europäische Kommission stellt jedoch klar, dass die Datenerfassung für das erste Berichtsjahr bereits am 1. Januar 2026 beginnt. Fehlerhafte oder fehlende Stammdaten lassen sich später nur mit erheblichem Aufwand korrigieren.
Finance und Tax sollten daher einen monatlichen oder quartalsweisen Readiness-Check etablieren. Dabei wird geprüft, wie viele Nutzer eine gültige steuerliche Selbstauskunft besitzen, welche TIN-Prüfungen offen sind, wie Transaktionen klassifiziert werden und ob Werte konsistent in einer Berichtswährung berechnet werden. Das Ziel ist ein laufend prüfbarer Datenbestand statt eines einmaligen Jahresend-Exports.
Welche Daten müssen zusammenkommen?
Die Meldearchitektur verbindet Identifikations- und Transaktionsdaten. Auf Nutzerebene spielen unter anderem Name, Anschrift, Steueransässigkeit, Steueridentifikationsnummer und Geburtsdaten eine Rolle. Auf Transaktionsebene müssen relevante Käufe, Verkäufe, Tauschvorgänge und Transfers nach den anwendbaren Kategorien aggregiert und bewertet werden.
Für die Buchhaltung entsteht eine Schnittstellenfrage: Der steuerliche Reporting-Datensatz ist nicht identisch mit dem Hauptbuch. Trotzdem sollte eine belastbare Reconciliation möglich sein. Gebührenumsätze, Kundenverbindlichkeiten, Fiat-Zahlungsströme und Bestände müssen erklären können, warum das operative Reporting bestimmte Volumina ausweist. Differenzen sind nicht automatisch Fehler, aber sie brauchen definierte Ursachen und dokumentierte Brücken.
CARF und DAC8: ähnlich, aber Governance bleibt lokal
DAC8 basiert in wesentlichen Teilen auf dem OECD Crypto-Asset Reporting Framework. Das erleichtert eine international konsistente Architektur, ersetzt aber nicht die Prüfung nationaler Umsetzungsdetails. Unternehmen mit mehreren EU-Standorten müssen klären, wo eine Registrierung erforderlich ist, welche Behörde zuständig ist und welche lokalen Fristen oder Dateiformate gelten.
Eine gute Governance trennt deshalb einen globalen Datenstandard von lokalen Reporting-Layern. Die Kernlogik für Nutzer- und Transaktionsklassifikation kann zentral entwickelt werden; die Meldung, Freigabe und Kommunikation mit Behörden bleibt je nach Rechtsraum steuerbar. Änderungen an CARF-FAQs, EU-Durchführungsformaten oder nationalen Vorgaben werden über ein Regulatory Change Log in das Datenmodell überführt.
Kontrollen, die ein Prüfer sehen will
Ein belastbarer Prozess braucht mehr als ein fertiges XML. Zu den Kernkontrollen gehören die Vollständigkeit der Nutzerpopulation, die Validierung steuerlicher Identifikationsdaten, die nachvollziehbare Klassifikation von Assets und Transaktionen, die Umrechnung in die Berichtswährung sowie die Freigabe von Korrekturen. Jede Regeländerung sollte versioniert werden.
Besonders wichtig ist das Exception Management. Nutzer ohne vollständige Selbstauskunft, Transfers mit unklarer Gegenpartei oder Assets mit strittiger Einordnung dürfen nicht stillschweigend aus dem Datensatz verschwinden. Sie benötigen Status, Owner, Bearbeitungsfrist und dokumentierte Entscheidung. Dadurch wird aus einem regulatorischen Export ein kontrollierter Reporting-Prozess.
Bewertung und Währungsumrechnung als Datenkontrolle
Bei Krypto-Transaktionen ist nicht nur die Menge relevant. Für das Reporting müssen Werte konsistent bestimmt und in der vorgesehenen Berichtswährung dargestellt werden. Gerade bei Tauschgeschäften zwischen zwei Krypto-Assets kann ein Unternehmen nicht einfach auf einen Fiat-Zahlungsbetrag aus dem Bankkonto zurückgreifen. Es braucht eine dokumentierte Bewertungsquelle, einen Zeitstempel und eine konsistente Umrechnungsmethode.
Finance sollte deshalb festlegen, welche Markt- oder Preisquelle für welche Asset-Kategorie verwendet wird, wie illiquide Tokens behandelt werden und wie nachträgliche Korrekturen versioniert werden. Ein täglicher Kontrollreport kann extreme Preise, fehlende Kurse und ungewöhnliche Volumina markieren. Dadurch wird die Bewertung nicht erst beim regulatorischen Export sichtbar, sondern als laufender Datenqualitätsprozess betrieben.
Datenschutz und Steuertransparenz müssen zusammenpassen
DAC8 verlangt die Verarbeitung umfangreicher personenbezogener und steuerlicher Informationen. Das erhöht die Verantwortung für Zugriffsschutz, Datenminimierung und Aufbewahrung. Tax Reporting darf nicht dazu führen, dass sensible Identifikationsdaten unnötig in Analyseumgebungen, Testsystemen oder frei zugänglichen Support-Tools landen.
Ein gutes Design trennt produktive Identitätsdaten von analytischen Transaktionsdaten und verwendet eindeutige Schlüssel, wo Klartext nicht erforderlich ist. Rollen und Berechtigungen sollten regelmäßig überprüft werden. Zusätzlich braucht es einen dokumentierten Prozess für Berichtigungen, weil fehlerhafte Steueransässigkeit oder TIN nicht nur ein Datenproblem, sondern eine falsche Meldung an Behörden verursachen kann.
Praktischer 90-Tage-Plan
- Scope der Services, Gesellschaften und Nutzergruppen dokumentieren.
- Pflichtfelder aus DAC8/CARF dem operativen Datenmodell zuordnen.
- Gap-Analyse für TIN, Steueransässigkeit und historische Stammdaten durchführen.
- Transaktionsklassifikation mit Testfällen für Exchange, Transfer und Stablecoins validieren.
- Reconciliation zwischen Reporting-Daten und Finance-Kontrollsummen etablieren.
- Exception Queue und Freigabeprozess einrichten.
- Lokale Melde- und Registrierungsanforderungen je Mitgliedstaat prüfen.