Resource center · Tax Transparency

Corrections, voids and resubmissions in CRS filings.

The single most expensive mistake in automatic exchange is resending a whole population to fix one record. The schema was built to avoid exactly that, and the mechanism turns entirely on two identifiers.

Guide CRS / DAC2 · Multi-jurisdiction · message corrections REGREP Regulatory Team · Reviewed 2026-07-18

Why records, not files

An exchange message carries many independent records. Receiving systems store them individually and forward them individually, so a defect in one account report does not invalidate the rest. The correction mechanism reflects that: it updates the affected record and leaves everything else in place.

Resubmitting the full population with fresh identifiers does not replace the earlier submission. It creates a second, parallel population that the receiving authority now holds alongside the first, with no link between them. Unwinding that is considerably more work than the original correction would have been.

The two identifiers

Identifier roles
Identifier	Scope of uniqueness	Purpose
Message reference	Every message ever sent by the filer to that jurisdiction.	Identifies the transmission and anchors the message being corrected.
Document reference	Every record ever created by the filer, permanently — not per file, not per period.	Identifies the individual record so a later correction can point at it.

Both are allocated once and never reused. The practical consequence is that identifier allocation belongs to a central service that persists across reporting periods, not to the process that builds a file. Regenerating a file from source data must reproduce the same document references for the same records, or every correction path is lost.

A record includes its parent. The reporting financial institution element carries its own document reference and can itself be corrected. Changing institution-level data is not the same operation as changing an account report, and the two have separate references.

Correction, deletion and resend

The document type indicator on each record states what the record is doing. Four states matter in practice:

New data — a record not previously reported for the period.
Correction — a replacement for an earlier record, carrying the message and document references of the record it replaces.
Deletion — withdrawal of an earlier record that should not have been reported, again carrying the earlier references.
Resend — the same data sent again where the receiving system requires it, without asserting a change.

A single message may carry corrections and deletions together, but a message that carries them must not also introduce new data. Mixing the two is one of the more common file-level rejections.

Which action applies

Choosing the action
Situation	Action
A reported figure or identity field was wrong	Correction, pointing at the original record.
An account was reported that was never reportable	Deletion. Correcting it to a nil value leaves a record asserting the account was in scope.
A reportable account was omitted	New data in a subsequent message, with a fresh document reference.
The holder’s residence jurisdiction was wrong	Delete the record sent to the wrong jurisdiction, and send new data to the correct one. A correction cannot move a record between jurisdictions.
The whole submission went to the wrong period	Delete the population and resubmit against the correct reporting period. Confirm the approach with the authority first.

Correcting a correction

A correction is itself a record with its own document reference, so a second correction points at the first correction rather than at the original. The chain has to be followed accurately; pointing a second correction back at the original leaves the receiving system holding two competing replacements for the same record. Retain the chain, not just the current state, because the authority sees the sequence.

Operating rules that hold

Allocate identifiers centrally and persist them alongside the source record, not inside the generated file.
Never regenerate identifiers when rebuilding a file, including after a failed or partial submission.
Record the submission outcome per record, so the set eligible for correction is known without reading the file back.
Treat a rejected file as unsent and a rejected record within an accepted file as sent — the two have opposite correction consequences.
Confirm the local layer. National portals add their own correction rules, windows and status codes. The schema permits an action the portal may not accept.

Official sources

Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.

Council Directive 2014/107/EU (DAC2) amending Directive 2011/16/EU as regards mandatory automatic exchange of information in the field of taxationEUR-Lex · Directive · the reporting obligation being corrected
OECD — Common Reporting Standard XML Schema and User Guide, in particular the message header and document specification sectionsOECD · document type indicators and reference semantics · consult the current edition
European Commission, Directorate-General for Taxation and Customs Union — DAC2 overviewEuropean Commission · exchange mechanics and timing

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.

At a glance

Mechanism: Record-level updates carried by a document specification block, not whole-file replacement.
Anchors: A permanent message reference and a permanent document reference per record.
Actions: New data, correction of an earlier record, or deletion of one.
Constraint: References must be unique across every message a jurisdiction has ever received from the filer.
Local layer: National portals add their own rules on top; confirm before the first correction.