DocRefID and CorrDocRefID: How to File FATCA and CRS Corrections Correctly

A rejected or flagged FATCA or CRS return is fixable. A badly built correction is what causes repeat errors, follow-up notices, and wasted reporting cycles. Almost every correction problem comes down to three things: the DocRefID, the CorrDocRefID, and the indicator codes that tell the tax authority what each record is.

This guide explains how these elements work, how FATCA and CRS differ, and how to build a correction chain that is accepted the first time.

Key Takeaways:

• FATCA vs. CRS: FATCA uses IDES (ICMM notices); CRS uses local portals. Never mix them.
• The Golden Rule: A DocRefID is never reused. A correction requires a new DocRefID and a CorrDocRefID pointing to the latest valid record.
• The Indicator Trap: Use DocTypeIndic (FATCA2/OECD2) to flag individual records. Use MessageTypeIndic (CRS702) only to flag the entire CRS message.

First, know which regime and which channel you are dealing with

FATCA and CRS share an XML design, but they are separate regimes:

• FATCA reports go to the US IRS. Financial institutions in Model 2 jurisdictions, and in some cases Model 1 tax authorities, transmit them through the IRS International Data Exchange Service (IDES). The IRS responds with notifications from its International Compliance Management Model (ICMM).
• CRS reports go to the local tax authority of the reporting financial institution, such as HMRC in the UK or the Revenue Commissioners in Ireland, through that authority's own portal. The United States is not a CRS participant, so CRS returns are never filed through IDES.

Many institutions file both, but the correction rules, codes, and channels must be handled separately.

What is a DocRefID?

The DocRefID (Document Reference Identifier) is the unique identifier of a single record inside your XML file. It sits in the DocSpec block of each record, such as the reporting financial institution record and each account report.

Key rules:

• It must be unique across all your submissions, for all time. A DocRefID is never reused, not even in a correction.
• It can be up to 200 characters.
• It must follow the required format.
  • FATCA: The IRS requires the DocRefID to begin with the reporting entity's GIIN, followed by a period, then a unique value.
    Example: 98Q96B.00000.LE.250.a1b2c3d4-0001
  • CRS: OECD guidance recommends starting with the country code of the sending jurisdiction, followed by an identifier for the sender and a unique value. Check your local authority's guidance, as some prescribe an exact format.

The tax authority uses the DocRefID to track each record through its life: original, corrected, voided.

What is a CorrDocRefID?

The CorrDocRefID (Corrected Document Reference Identifier) links a correction or void back to the record it replaces. It must exactly match the DocRefID of the record being corrected.

A correction record therefore carries:

1. A new DocRefID of its own.
2. A CorrDocRefID equal to the DocRefID of the record being replaced.
3. The correct DocTypeIndic (see below).
4. For FATCA only, a CorrMessageRefID equal to the MessageRefID of the original file that contained that record.

The codes that matter: DocTypeIndic vs MessageTypeIndic

This is where most published guidance goes wrong. Corrections and voids are flagged per record with DocTypeIndic, not with MessageTypeIndic.

FATCA DocTypeIndic values

• FATCA1: New data
• FATCA2: Corrected data
• FATCA3: Void data
• FATCA4: Amended data
• FATCA11–FATCA14: Test data (new, corrected, void, amended)

Note: FATCA XML schema v2 has no MessageTypeIndic element at all. Whether a record is new, corrected, voided, or amended is shown only by the record-level DocTypeIndic.

CRS codes

DocTypeIndic (record level):

• OECD0: Resent data (used for the reporting FI record only)
• OECD1: New data
• OECD2: Corrected data
• OECD3: Deletion of data (void)
• OECD10–OECD13: Test data

MessageTypeIndic (message level):

• CRS701: The message contains new information
• CRS702: The message contains corrections to previously sent information
• CRS703: The message reports that there is no data to report (nil return)

Note: CRS703 is a nil return, not a void. In CRS you void a record with OECD3. CRS702 only labels the message; each corrected record still needs OECD2 or OECD3.

Correct vs resubmit: a rejected file is not corrected

Corrections and voids apply only to records the tax authority has already accepted.

• If an entire file is rejected at file level (for example, it fails decryption, validation, or schema checks), nothing in it was accepted. Fix the problem and resend the data as new (FATCA1 / OECD1), normally with new identifiers.
• If the file was accepted but specific records were flagged, or you later discover an error, file a correction or void that references those records.

Using a correction to "fix" a rejected file is a common cause of repeat errors, because the CorrDocRefID points at a record the authority never accepted.

Worked example: a FATCA correction

Original filing, 1 May 2026. You report Account 123 in your 2025 FATCA return.

The IRS accepts the file.

First correction, 15 June 2026. You find the account balance was wrong.

Second correction, 20 June 2026. The corrected balance was also wrong.

The second correction points to the latest valid record (...0002), not the original. Each step gets a brand-new DocRefID.

The same correction in CRS

In CRS, the message is labelled CRS702 and the account record uses OECD2:

Follow your local authority's guidance on whether the reporting financial institution record must also be included, and with which DocTypeIndic.

Voiding a record

If a record should never have been reported, such as a non-reportable account, void it instead of correcting it.

• FATCA: DocTypeIndic FATCA3, a new DocRefID, a CorrDocRefID and CorrMessageRefID pointing to the record being voided. The IRS expects the void record to repeat the data of the record it voids.
• CRS: DocTypeIndic OECD3, a new DocRefID, and a CorrDocRefID pointing to the record being deleted.

If you do not void a wrongly reported record, the authority will continue to treat that account as reportable.

Errors you are likely to see

For FATCA, the IRS reports problems through ICMM notifications:

• File-level errors mean the file was not processed. Fix the file and resend it as new data.
• Record-level errors (for example 8001 Pooled Report Error and 8007 Account Report Error) appear in a "valid file with errors" notification. The notification gives the DocRefID of each affected record, and you correct those records with FATCA2 or FATCA3.
• Duplicate or invalid DocRefIDs, and corrections that point at an invalid record, are reported as record-level errors. An invalid record is one that already failed, was voided, was already corrected, or was a duplicate.

The full list of codes and actions is in IRS Publication 5189 (ICMM Notifications User Guide). For CRS, check your local authority's status message guidance, which follows the OECD CRS Status Message schema.

Note: These reference problems are caught during processing, not by the XML schema (XSD) check. A file can pass schema validation and still contain an invalid CorrDocRefID. You can check your structure with our Free XML Validation Tool.

Best practices

1. Never reuse a DocRefID or MessageRefID. Once used, it is retired permanently.
2. Use the correct format. GIIN prefix for FATCA; country-code prefix for CRS, or the format your authority prescribes.
3. Keep a full identifier log. For every record, store the DocRefID, MessageRefID, DocTypeIndic, submission date, and authority response, plus what each correction replaced.
4. Always point to the latest valid record. Never to a record that was rejected, voided, or already superseded.
5. Separate resubmissions from corrections. Rejected files are resent as new data; accepted records are corrected or voided.
6. Use the right indicator at the right level. DocTypeIndic per record; MessageTypeIndic per CRS message.
7. Act on notifications promptly. Check the deadline stated in the IRS notification or your local authority's guidance.
8. Validate before you transmit. Schema validation catches structural errors; your own checks must catch reference errors.

How Novus Compliance handles corrections

Tracking identifiers by hand works for a few accounts. It does not work for thousands.

Novus Compliance stores every DocRefID and MessageRefID it generates, together with each record's status. When you need to correct or void a record, you load the original submission, edit the fields that changed, and the platform:

• Generates new, correctly formatted DocRefIDs and MessageRefIDs;
• Fills in CorrDocRefID, and CorrMessageRefID for FATCA, from the latest valid record;
• Applies the right DocTypeIndic (FATCA2/FATCA3 or OECD2/OECD3) and, for CRS, the right MessageTypeIndic;
• Flags records that cannot be corrected because they were never accepted.

Book a demo to see how Novus Compliance manages the full FATCA and CRS correction lifecycle.

References & Further Reading:

• IRS FATCA XML User Guide
• IRS Publication 5189 (ICMM Notifications User Guide)
• OECD CRS XML Schema User Guide
• Complete Guide to IRS IDES Error Codes

This article is general guidance, not tax or legal advice. Always confirm requirements against the current IRS FATCA XML User Guide, IRS Publication 5189, the OECD CRS XML Schema User Guide, and your local tax authority's instructions.