Correcting a CARF filing: amendments, deletions, and the identifiers behind them

You will get something wrong in a CARF filing at some point. A user's residence changes after the fact, a figure was off, a record should never have been sent. The answer is not to resend the whole report and hope the authority reconciles it. CARF has a precise way to make corrections, taken from the CRS and the wider OECD schemas, and it lives in a small set of identifiers. Learn them and amendments are routine. Miss them and every fix risks making the original error worse.

The two indicators that control everything

Corrections are governed by two type indicators, one at the message level and one at the record level.

• MessageTypeIndic sits in the header and declares what the whole file is. A file is either new information or a set of corrections; you do not casually mix the two. A corrections file tells the authority to expect amended, not fresh, records.
• DocTypeIndic sits on every individual document inside the file, the reporting CASP block and each user record, and says whether that specific document is new, an amendment of one sent before, or a deletion of one sent before.

Get these two out of step, a corrections file carrying documents flagged as new, or the reverse, and the file fails validation before the substance is even read.

DocRefId and CorrDocRefId: the back-reference

Every document you ever send carries a unique DocRefId. To correct or delete one later, the amending document references the exact DocRefId of the original through a CorrDocRefId. That back-reference is the whole game: it is how the authority knows which of the thousands of records you already filed this one replaces or removes. It is also why identifier discipline on the first filing matters so much, a point we make in the errors that get filings rejected.

If your original submission used duplicate or unstable DocRefIds, you have no reliable handle to point back at, and a clean amendment becomes impossible. A tidy first filing is what turns every future correction into a one-line operation instead of a reconciliation project.

Corrections, deletions and resends

In practice you will use three kinds of change. A correction amends a record already accepted, for example updating a residence or a corrected gross amount, and carries the new data plus the CorrDocRefId of the record it replaces. A deletion removes a record that should not have been filed at all, referencing the original with no new data. And there is a resend path for the narrow case where the authority asks for a previously accepted record again unchanged. Knowing which of the three a given fix is prevents the common mistake of deleting-and-recreating when a simple correction was called for.

Amending the whole message

Just as records carry a DocRefId, the message itself carries a MessageRefId, and a corrections file references the earlier message through a CorrMessageRefId where required. This keeps the chain of submissions coherent, so an auditor can follow what you filed, what you changed, and when, across a whole reporting period.

Why it has to be auditable

Corrections are a governance matter as much as a technical one. You should be able to show, for any record, its full history: the original filing, each amendment, the reason, and the date. A regulator will not trust a correction process that leaves no trail.

How Kryptos handles it

Our CARF and DAC8 reporting platform assigns stable, unique identifiers from the first filing, builds correction and deletion messages that reference the right originals through CorrDocRefId, keeps the MessageTypeIndic and DocTypeIndic consistent, and retains the full amendment history, so a fix is a click rather than 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.

About the author

Sukesh Tedla

Founder & CEO