Validating CARF XML: the errors that get filings rejected
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 built against a defined schema, and tax authorities validate it the moment it arrives. Fail validation and it bounces, which leaves you re-filing against a deadline. Most rejections are mundane. The same handful of structural errors, over and over, and you can catch every one before you submit.
Identifier collisions
Each message and each record carries unique references: a MessageRefId for the file, a DocRefId for every document inside it. Reuse one across submissions, or duplicate one within a single file, and the schema throws the whole thing out. Corrections raise the stakes. An amendment has to point back at the exact DocRefId it replaces, so weak identifier hygiene breaks the first filing and every fix that follows.
TIN and country-code problems
A taxpayer identification number in the wrong format, or a residence country code that isn't a valid ISO entry, ranks among the most common reasons a file gets rejected. That's why the format check belongs at onboarding rather than at filing, a point we make in the CARF self-certification and TIN validation workflow.
Message-type and structural mismatches
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. Mix new and corrected records the wrong way, or leave a required element empty, and the XSD fails you even when every number is right.
Version drift
The CARF XML schema comes in versions, and jurisdictions move to new ones on their own timelines. Build a file to last year's schema, or to the OECD baseline where a country wants its own national envelope, and it gets rejected on arrival, technically valid CARF or not. Sweden's KU94 is the classic case: a national format a generic build simply won't produce.
Catching it before submission
The fix: check every file against the exact schema each authority accepts, before it goes out. Our CARF and DAC8 reporting platform validates every file against the schema and generates the national formats on top of 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.
