What gets checked
| Structure | Well-formedness, CARF_OECD root, schema version, a complete MessageSpec. |
| Enumerations | MessageTypeIndic, DocTypeIndic, Nexus, TransferType, country and currency codes. |
| Cross-field rules | The rules real files fail on: a new-data message carrying corrections, a correction message carrying new data, duplicate DocRefIds, test and production data mixed, a nil report containing users. |
| Plausibility | Amounts without a currency, negative aggregates, non-integer transaction counts, empty TINs (tax identification numbers). |
| German conventions | Reporting period as a year end, reportable year from 2026, DE as both sending and receiving country when filing to the BZSt. |
Why the file never leaves your browser
A CARF file contains your customers' names, addresses, tax identification numbers and transaction totals. It is the most sensitive dataset a crypto-asset service provider holds. A validator that requires an upload is therefore unusable for most firms, however well it checks.
The validator runs entirely as JavaScript in your browser. There is no endpoint the file could be sent to and no server that could store it. Keep your browser's network tab open while you validate: nothing happens.
What the validator is not
It is not a filing and not an acceptance confirmation. The BZSt runs its own check. The German record-format specification (Datensatzbeschreibung, dated 17.11.2025) is published and additionally describes the DIP envelope the CARF payload is wrapped in; since 14.10.2026 this page checks the envelope too, against dip.xsd schema version 2 and the pre-checks in the DIP communication handbook 2.4. The payload is validated against the OECD schema as of July 2025 and against the rules the User Guide sets out in prose. An enveloped signature is recognised and reported but not verified; signature, access credentials and the duplicate check remain the BZSt's business. If the German description changes, we change this page and say so.
What comes before the XML
A valid XML is the end of a chain that starts much earlier: collecting self-certifications, sanity-checking residencies and TINs, chasing gaps, consolidating transaction data per user, and carrying corrections and cancellations through after filing. That is where the hours go, spread across twelve months. That workflow is the first part of the Stablewerk back office: the DAC8 report to the BZSt, beside the books into DATEV and the evidence pack for the auditor.
If your file fails and you want to know what is missing before it: write to us.
Basis: OECD, Crypto-Asset Reporting Framework XML Schema, User Guide for Tax Administrations, July 2025 edition (schema v1.5). German legal basis: the crypto tax transparency act (KStTG), filing to the BZSt by 31.07.2027 for reporting period 2026. This page is a technical aid, not legal or tax advice.