Was geprüft wird
| Aufbau | Wohlgeformtheit, Wurzelelement CARF_OECD, Schemaversion, vollständiger MessageSpec. |
| Wertelisten | MessageTypeIndic, DocTypeIndic, Nexus, TransferType, Länder- und Währungscodes. |
| Querregeln | Die Regeln, an denen echte Dateien scheitern: Neumeldung mit Korrektursätzen, Korrekturmeldung mit Neudaten, doppelte DocRefId, Test- und Echtdaten gemischt, Nullmeldung mit Nutzerdaten. |
| Plausibilität | Beträge ohne Währung, negative Aggregate, nicht ganzzahlige Transaktionszahlen, leere TINs. |
| Deutsche Konventionen | Meldezeitraum als Jahresende, Meldejahr ab 2026, DE als sendendes und empfangendes Land bei der Abgabe an das BZSt. |
Warum die Datei Ihren Browser nicht verlässt
Eine CARF-Datei enthält Namen, Anschriften, Steuer-Identifikationsnummern und Transaktionssummen Ihrer Kunden. Das ist der sensibelste Datensatz, den ein Krypto-Dienstleister besitzt. Ein Validator, der einen Upload verlangt, ist deshalb für die meisten Häuser unbenutzbar, unabhängig davon, wie gut er prüft.
Der Validator läuft vollständig als JavaScript in Ihrem Browser. Es gibt keinen Endpunkt, an den die Datei gesendet würde, und keinen Server, der sie speichern könnte. Sie können den Netzwerk-Tab Ihres Browsers offen lassen, während Sie prüfen: es passiert nichts.
Was der Validator nicht ist
Es ist keine Abgabe und keine Annahmebestätigung. Das BZSt führt seine eigene Prüfung durch. Die deutsche Datensatzbeschreibung (Stand 17.11.2025) ist veröffentlicht und beschreibt zusätzlich den DIP-Umschlag, in den die CARF-Nutzdaten eingebettet werden; seit dem 14.10.2026 prüft diese Seite auch den Umschlag, gegen die dip.xsd in Schema-Version 2 und die Vorprüfungen aus dem Kommunikationshandbuch DIP-Standard 2.4. Die Nutzdaten prüft sie gegen das OECD-Schema in der Fassung vom Juli 2025 und gegen die Regeln, die das Handbuch im Fließtext festlegt. Eine Enveloped-Signatur wird erkannt und gemeldet, aber nicht geprüft; Signatur, Zugangsdaten und Duplikatsprüfung bleiben Sache des BZSt. Wenn sich die deutsche Beschreibung ändert, ändern wir diese Seite und schreiben es dazu.
Was vor dem XML liegt
Ein gültiges XML ist das Ende einer Kette, die viel früher beginnt: Selbstauskünfte einholen, Ansässigkeiten und Steueridentifikationsnummern (TIN) plausibilisieren, Lücken nachverfolgen, Transaktionsdaten je Nutzer zusammenführen, und nach der Abgabe Korrekturen und Stornierungen nachziehen. Dort entstehen die Stunden, verteilt über zwölf Monate. Dieser Arbeitsablauf ist der erste Teil des Stablewerk-Backoffice: die DAC8-Meldung an das BZSt, neben den Büchern nach DATEV und dem Nachweispaket für den Prüfer.
Wenn Ihre Datei durchfällt und Sie wissen wollen, was davor fehlt: schreiben Sie uns.
Grundlage: OECD, Crypto-Asset Reporting Framework XML Schema, User Guide for Tax Administrations, Fassung Juli 2025 (Schema v1.5). Deutsche Rechtsgrundlage: Kryptowerte-Steuertransparenzgesetz (KStTG), Meldung an das BZSt bis 31.07.2027 für den Meldezeitraum 2026. Diese Seite ist ein technisches Hilfsmittel und keine Rechts- oder Steuerberatung.