A CARF filing that fails schema validation bounces. Here are the recurring XML errors, from DocRefId collisions to bad TINs, and how to catch them first.
The CARF report is an XML file against a defined schema, and tax authorities validate it on receipt. If it doesn't pass, it bounces, and you're re-filing against a deadline. Most rejections aren't exotic. They're the same handful of structural errors, and every one of them is catchable before you submit.
Usually for structural reasons rather than wrong numbers: duplicate or reused MessageRefId and DocRefId values, invalid TIN formats or country codes, a MessageTypeIndic that doesn't match the records, empty required elements, or a file built to the wrong schema version.
It is the unique reference for each document inside a CARF message. It must be unique across submissions, and a correction has to reference the exact DocRefId it amends, so identifier hygiene is essential for both first filings and later fixes.
Validate the XML against the specific schema each authority accepts before you submit, including any national envelope, and check identifiers, TIN formats, and country codes. Catching these at a validation gate avoids re-filing against a deadline.
Austrian providers must withhold 27.5% KESt on crypto gains. Here's what triggers it, how the moving-average basis works, and how to automate the filing.
Withhold KESt at source and your users' crypto tax is final, no return needed. Use a foreign provider and they self-declare. Here's why the difference matters.
Austria requires the gleitender Durchschnittspreis for crypto, not FIFO. Here's how the moving-average basis works and why it complicates withholding.
Generate an audit-ready report aligned to your jurisdiction. No credit card required.
Each message and each record carries unique references, a MessageRefId for the file and a DocRefId for every document inside it. Reuse one across submissions, or duplicate one within a file, and the schema rejects the whole thing. Corrections make this sharper still: an amendment has to point back at the exact DocRefId it replaces, so sloppy identifier hygiene breaks not just the first filing but every fix after it.
A taxpayer identification number that doesn't match the expected format, or a residence country code that isn't a valid ISO entry, is one of the most common rejection reasons. This is why the format check belongs at onboarding, not at filing, a point we make in the CARF self-certification and TIN validation workflow.
The schema expects the file to declare what it is, a new report, a correction, a nil return, through the MessageTypeIndic and related fields, and the body has to match that declaration. Mixing new and corrected records incorrectly, or leaving a required element empty, fails the XSD even when every number is right.
The CARF XML schema has versions, and jurisdictions move to new ones on their own timelines. A file built to last year's schema, or to the OECD baseline where a country requires its own national envelope, gets rejected on arrival even though it's technically valid CARF. Sweden's KU94 is the classic example of a national format a generic build doesn't produce.
The fix is to validate hard, before anything leaves the building, against the exact schema each authority accepts. Our CARF and DAC8 reporting platform runs a multi-tier XSD gate on every file and generates the national envelopes, not just the OECD baseline, so a filing doesn't bounce on a structural error you could have caught. The blocking and cure-period side of compliance is covered in the CARF 60-day rule, and the OECD exchange-of-information hub publishes the schema and user guide.