Enquire Now

FATCA 2 / CRS Correction Filing Checklist

Pre-Submission Verification for Correction and Void Filings

Aligned with FATCA XML v2.0.1 §5 (Corrections) & CRS XML v3.0 User Guide §5

0 of 0 items completed INCOMPLETE

Correction Filing Information

MessageTypeIndic = FATCA2 (correction)
About this checklist

This checklist covers the full correction workflow for FATCA 2 (IRS IDES and local authority) and CRS correction filings. Each item references the specific section of the FATCA XML v2.0.1 or CRS XML v3.0 User Guide. Not all items apply to every correction — use the scope selector above to filter relevant items.

Filter by Category:
All Items Critical Important FATCA 2 CRS Void Only

FATCA 2 / CRS Correction Filing Checklist

FI:

ID:

Jurisdiction:

Original Year:

Reviewer:

Correction Type:

Section 1: Correction Trigger & Impact Analysis

Determine why the correction is needed and its scope

Correction Reason Documented
Critical Both
Document the specific reason for the correction — data error, missed account, incorrect classification, missing TIN, or schema non-compliance. This determines both the correction scope and the applicable CorrectionReason code in the XML.
FATCA XML v2.0.1 User Guide §5.1 | CRS XML v3.0 User Guide §5.1
Correction Scope Identified
Critical Both
Confirm whether the correction is account-level (specific accounts corrected), message-level (whole submission corrected), or a full void. Each scope requires a different XML structure and message indicator.
FATCA XML v2.0.1 §5.2 | CRS XML v3.0 §5.2 | ATO FATCA Reporting Guide
Correction vs Void Decision
Critical Both
Determine whether the correct action is a correction (amend data) or a void (retract the entire filing). A void is used when the filing should not have been made at all — e.g., wrong reporting FI, duplicate submission, or entity incorrectly classified as reportable.
FATCA XML v2.0.1 §5.3 (Void filings) | CRS XML v3.0 §5.3
Downstream Impact Assessed
Important Both
Determine whether the correction affects year-end reconciliation, CRS exchange with treaty partners, or FATCA withholding calculations. Notify affected internal teams (Tax, Treasury, Controllership) before submission.
Internal governance | OECD CRS Handbook §5
Correction Deadline Confirmed
Important Both
Confirm the correction deadline for the jurisdiction. Many authorities allow corrections to be filed throughout the year; some require corrections within a specific window after the original filing. Late corrections may trigger penalties.
Local authority guidance | IRS IDES Filing Deadlines

Section 2: Original Filing Identification

Locate and verify the original submission details

Original MessageRefID Located
Critical Both
Retrieve the MessageRefID from the original filing. This is the unique identifier for the original submission and must be referenced in the correction's CorrMessageRefID element.
FATCA XML v2.0.1 §5.4 | CRS XML v3.0 §5.4
Original DocRefIDs Identified
Critical Both
Retrieve the DocRefID for every account being corrected or voided. Each original DocRefID must be referenced exactly (character-for-character) in the correction's CorrDocRefID element.
FATCA XML v2.0.1 §5.5 | CRS XML v3.0 §5.5
Original Filing Schema Version Confirmed
Important Both
Confirm which schema version the original filing used. The correction must use the same or a newer schema version. If the original used CRS v2.0 and the jurisdiction now requires v3.0, the correction must be filed under v3.0.
FATCA XML v2.0.1 release notes | CRS XML v3.0 migration guidance
Original Submission Receipt Retrieved
Important Both
Retrieve the acknowledgement or receipt ID from the original submission. This confirms the original filing was accepted by the tax authority and is on record as a valid filing to correct.
Local authority portal | IRS IDES acknowledgement
Original Filing Still Active
Critical Both
Verify the original filing has not already been corrected, voided, or superseded. Attempting to correct an already-corrected filing will fail validation. Check the local authority's filing history for prior corrections.
Local authority filing history | IRS IDES transaction log

Section 3: Correction Chain Setup

Build the XML correction chain with proper identifiers

New DocRefID is Unique
Critical Both
The correction must use a new DocRefID that has never been used before — in any prior filing, for any jurisdiction. Reusing a DocRefID is one of the most common rejection causes. Keep a global registry of DocRefIDs issued.
FATCA XML v2.0.1 §5.6 | CRS XML v3.0 §5.6
CorrDocRefID Matches Original Exactly
Critical Both
The CorrDocRefID must match the original filing's DocRefID character-for-character. Case sensitivity matters. Whitespace or typo differences will cause validation failure.
FATCA XML v2.0.1 §5.6 | CRS XML v3.0 §5.6
CorrMessageRefID Set (for Message-Level Corrections)
Critical Both
For message-level corrections and voids, the CorrMessageRefID element must reference the original message's MessageRefID. This element is required at the message level, not per account.
FATCA XML v2.0.1 §5.7 | CRS XML v3.0 §5.7
MessageTypeIndic Set Correctly
Critical Both
Set the message indicator per schema:
  • FATCA: FATCA1 (new), FATCA2 (correction), FATCA3 (void)
  • CRS: CRS701 (new), CRS702 (correction), CRS703 (void)
Using the wrong code causes the filing to be treated as new data, creating duplicate records.
FATCA XML v2.0.1 §5.8 | CRS XML v3.0 §5.8
CorrectionReason Code Applied
Important Both
Where the schema requires a CorrectionReason code (e.g., India Form 61B), apply the correct code — N for new, C for correction, D for deletion, or jurisdiction-specific values per the local schema guidance.
Form 61B Schema | FATCA XML v2.0.1 §5.9 | CRS XML v3.0 §5.9
Void-Specific Fields Completed
Void only Void
For void filings, confirm the void reason is documented and the CorrDocRefID references each voided account. Voided records must not contain corrected data — only the reference to the original filing.
FATCA XML v2.0.1 §5.10 (Void) | CRS XML v3.0 §5.10

Section 4: Data Corrections Verification

Verify the corrected values are accurate and complete

Corrected Values Verified
Critical Both
Re-verify the corrected values against source documents (self-certifications, KYC records, account statements). The correction must reflect the true correct state, not a guess.
FATCA XML v2.0.1 §6 | CRS XML v3.0 §3
Only Intended Fields Changed
Critical Both
Diff the corrected XML against the original to confirm only the intended fields have changed. Unintended changes (e.g., a corrupted TIN, a shifted account balance) can invalidate the correction or introduce new errors.
Internal QA | FATCA XML v2.0.1 §5.11
No New Errors Introduced
Critical Both
Run the corrected XML through the same validation process as a new filing — XSD validation, business rules, and field-level checks. The correction should not introduce any new schema or business rule failures.
FATCA XML v2.0.1 §5.12 | CRS XML v3.0 §5.12
Corrected TIN / GIIN Validated
Important Both
If the correction involves a TIN or GIIN change, validate the new value against the correct format and (for GIINs) the current IRS FFI List. Use our GIIN Validation Tool and XML Validation Tool.
FATCA v2.0.1 §6.9 | CRS v3.0 §3.4 | IRS FFI List
Reporting FI Information Unchanged (Where Applicable)
Important Both
If the correction is account-level, the Reporting FI information should typically remain identical to the original. Changing FI-level data in a correction may be treated as a full message-level correction and require a different structure.
FATCA XML v2.0.1 §5.13 | CRS XML v3.0 §5.13

Section 5: Schema & Chain Validation

Validate against schema and correction chain integrity

Schema Version & XSD Validation
Critical Both
Validate the correction XML against FATCA XML v2.0.1 or CRS XML v3.0. Use the correct namespace and element ordering. The correction must validate cleanly before submission.
FATCA XML v2.0.1 XSD | CRS XML v3.0 XSD
Correction Chain Integrity Check
Critical Both
Verify the full chain is unbroken: original filing → original DocRefID → correction DocRefID → CorrDocRefID (matches original). If any link is missing or mismatched, the correction will be rejected by the receiving authority.
FATCA XML v2.0.1 §5.14 | CRS XML v3.0 §5.14
Business Rules for Corrections Validated
Important Both
Confirm the correction satisfies the business rules specific to corrections in the applicable user guide — separate from the general rules for new filings. Missing a correction-specific rule is a common cause of rejection.
FATCA v2.0.1 User Guide §5 | CRS v3.0 User Guide §5
Cross-Reference to Original Preserved
Important Both
Confirm that any data not being corrected (e.g., account balances, other account holders) is preserved exactly from the original filing. Do not re-transmit unchanged data in an account-level correction unless required by the local schema.
FATCA XML v2.0.1 §5.15 | CRS XML v3.0 §5.15

Section 6: Submission, Acknowledgement & Retention

File, confirm, and record the correction

Encryption & Signing Applied
Critical Both
Sign and encrypt the correction XML using the same method as the original filing — AES-256 for IDES submissions, local authority encryption for Model 1 jurisdictions.
FATCA v2.0.1 §3 (IDES Encryption) | Local authority encryption spec
Correction Submitted to Correct Channel
Critical Both
Submit to the same channel as the original — IDES for Model 2, local authority portal for Model 1. Do not mix channels (e.g., a correction to an IDES-filed original must go through IDES).
Local authority portal | IRS IDES submission guide
Correction Acknowledgement Received
Critical Both
Confirm the receiving authority has accepted the correction and returned an acknowledgement ID. If the correction is rejected, the errors must be resolved and the correction re-filed.
Local authority portal | IRS IDES response
Correction Log Updated
Important Both
Update the internal correction log with the new DocRefID, the original DocRefID, the submission date, and the acknowledgement ID. This log is essential for future audits and for tracking correction chains over time.
Internal recordkeeping | FATCA v2.0.1 §8
Original + Correction Retained Together
Important Both
Store the original filing and the correction in the same audit folder for the required retention period (6 years for India; consult local requirements). The correction is not valid without the original filing as context.
Recordkeeping requirements | Rule 114G | FATCA v2.0.1 §8 | CRS v3.0 §VII

Sign Off

Comprehensive Review
I confirm all applicable items in this correction checklist have been verified.
Compliance Officer Approval
Correction submission approved by the Designated Officer.