Correcting a CARF filing: amendments, deletions, and the identifiers behind them
Fixing a CARF report is not refiling it. A guide to MessageTypeIndic, DocTypeIndic, DocRefId and CorrDocRefId, and how corrections and deletions work.
Sooner or later you'll get something wrong in a CARF filing. A user moves and their residence changes after the fact. A figure was off. A record went out that should never have been sent. Resending the whole report and hoping the authority reconciles it is not the fix. CARF borrows a precise correction mechanism from CRS and the wider OECD schemas, and the whole thing rests on a handful of identifiers. Learn them and amendments become routine. Miss them, and every fix risks compounding the original mistake.
The two indicators that control everything
Two type indicators govern corrections. One sits at the message level, the other at the record level.
- MessageTypeIndic lives in the header and declares what the whole file is. A file carries either new information or corrections, and you don't mix the two. A corrections file tells the authority to expect amended records rather than fresh ones.
- DocTypeIndic sits on every document inside the file, the reporting CASP block and each user record alike. It says whether that document is new, an amendment of one you sent before, or a deletion of one you sent before.
Get the two out of step, say a corrections file carrying documents flagged as new, and the file fails validation before anyone reads the substance.
DocRefId and CorrDocRefId: the back-reference
Every document you send carries a unique DocRefId. To correct or delete one later, the amending document points at the original's exact DocRefId through a CorrDocRefId. That back-reference is everything. It's how the authority knows which of the thousands of records already on file this one replaces or removes. It's also why identifier discipline on the first filing matters so much, something we cover in the errors that get filings rejected.
Duplicate or unstable DocRefIds on the original submission leave you with no reliable handle to point back at, and a clean amendment becomes impossible. Get the first filing tidy and every future correction is a one-line operation instead of a reconciliation project.
Corrections, deletions and resends
Three kinds of change come up in practice. A correction amends a record that's already been accepted, updating a residence or a corrected gross amount, and it carries the new data plus the CorrDocRefId of the record it replaces. A deletion pulls a record that should never have been filed, referencing the original with no new data. There's also a resend path, for the narrow case where the authority asks for a previously accepted record again, unchanged. Work out which of the three a given fix is, and you avoid the common trap of deleting and recreating when a correction was all you needed.
Amending the whole message
Records carry a DocRefId; the message itself carries a MessageRefId. Where required, a corrections file references the earlier message through a CorrMessageRefId. That keeps the chain of submissions coherent, so an auditor can follow what you filed, what you changed, and when it happened, across a whole reporting period.
Why it has to be auditable
Corrections are a governance matter as much as a technical one. For any record, you should be able to show its full history: the original filing, each amendment, why it happened, and when. A regulator won't trust a correction process that leaves no trail.
How Kryptos handles it
Our CARF and DAC8 reporting platform assigns stable, unique identifiers from the very first filing. It builds correction and deletion messages that point at the right originals through CorrDocRefId, keeps MessageTypeIndic and DocTypeIndic in sync, and holds on to the full amendment history. A fix becomes a click, not a hand-built XML edit. For how corrections sit inside the wider file, see the CARF XML schema, section by section, and the OECD exchange-of-information hub for the correction rules in full.
