Category: Troubleshooting Last Updated: 2026-02-12

---

Overview

After submitting a DAC8 report, you may discover errors that need to be corrected. Mistakes in reported amounts, incorrect TINs, omitted users, or other data inaccuracies require formal correction through the appropriate channels. DAC8, building on the Common Reporting Standard (CRS) and the broader AEOI framework, provides mechanisms for submitting corrected and voided data. This article explains when corrections are needed, how they differ from voids, and the practical steps for submitting them.

---

Problem: Errors Discovered After Report Submission

Cause

Post-submission errors can arise from many sources:

  • A user's TIN was entered incorrectly.
  • Transaction amounts were calculated using the wrong exchange rate.
  • A user's tax residence jurisdiction was wrong due to an outdated self-certification.
  • Records were duplicated or omitted.
  • The XML file had structural issues that were accepted by the portal but contained incorrect data.

When Corrections Are Needed

You should submit a correction whenever:

  • You become aware that data in a previously submitted report is materially incorrect.
  • A tax authority notifies you of an error or requests clarification.
  • Internal audit or reconciliation processes identify discrepancies.
  • A user provides updated information (such as a corrected TIN or address) that affects a previously submitted report.

There may not be a materiality threshold formally defined in all jurisdictions, so a cautious approach is to correct any known error promptly.

---

Correction vs. Void: Understanding the Difference

Correction (CorrMessageRefId / CorrDocRefId)

A correction replaces previously submitted data with updated data. Use a correction when:

  • The data was wrong but the record should still exist in the report.
  • You need to update a specific field (amount, TIN, address, jurisdiction, etc.).

A correction message typically references the original record by its DocRefId or MessageRefId and provides the corrected values.

Void (Deletion)

A void removes a previously submitted record entirely. Use a void when:

  • A record was submitted that should not have been included at all (for example, a non-reportable user was mistakenly included, or a transaction was reported under the wrong reporting period).
  • The original record is entirely invalid and should be treated as if it was never submitted.

A void message references the original DocRefId and indicates that the record should be deleted, without providing replacement data.

---

Timing of Corrections

How Quickly Should You Correct?

Most tax authorities expect corrections to be submitted as soon as reasonably practicable after the error is discovered. Specific deadlines may vary by jurisdiction, but a general best practice is:

  • Immediate or near-term: If the error is discovered shortly after the original submission deadline, submit the correction without delay.
  • Within the next reporting cycle: If corrections cannot be prepared immediately, aim to submit them before or alongside the next regular reporting cycle.
  • Upon request: If a tax authority requests a correction, comply within the timeframe specified in the request.

Can Corrections Be Submitted After the Reporting Deadline?

Generally, yes. Corrections can typically be submitted outside the normal reporting window. However, the specific rules and portals for off-cycle submissions vary by Member State. Check with the relevant tax authority regarding the availability and process for late corrections.

---

Format of Correction Messages

Correction and void messages follow the same XML schema as the original report, with specific fields used to indicate the correction type. While the exact element names depend on the version of the schema in use, the general structure is:

For a Corrected Record

  1. Include the CorrDocRefId element, referencing the DocRefId of the original record being corrected.
  2. Assign a new, unique DocRefId to the correction record.
  3. Populate all data fields with the corrected values (not just the fields that changed). The correction record typically replaces the original in its entirety.
  4. Set the CorrMessageTypeIndic (or equivalent field) to the value indicating a correction (commonly OECD2 for corrected data, though verify against the current schema).

For a Voided Record

  1. Include the CorrDocRefId element, referencing the DocRefId of the original record being voided.
  2. Assign a new, unique DocRefId to the void record.
  3. Set the CorrMessageTypeIndic (or equivalent field) to the value indicating a deletion or void (commonly OECD3, though verify against the current schema).
  4. Data fields in the voided record may be minimal or empty, as the record is being removed.

> Important: The exact element names, type indicators, and required fields for corrections and voids may differ depending on the specific DAC8 XML schema version and the receiving tax authority's implementation. Always refer to the official schema documentation and any guidance published by the relevant tax authority.

---

Practical Steps for Submitting Corrections

  1. Identify the error. Document exactly which records and fields are affected.
  2. Retrieve the original DocRefIds. You will need the DocRefId values from the original submission to reference in the correction or void.
  3. Generate the correction XML. Build the correction message following the schema, ensuring all mandatory fields are populated.
  4. Validate before submission. Run the correction XML through XSD validation to ensure it conforms to the schema.
  5. Submit through the appropriate channel. Use the same submission portal or mechanism used for the original report.
  6. Confirm receipt. Verify that the tax authority has accepted the correction. Some portals provide acknowledgment receipts or status notifications.
  7. Update internal records. Record the correction in your internal audit trail, including the reason for the correction, the date it was submitted, and the affected records.

---

Preventing the Need for Corrections

While corrections are a normal part of compliance operations, reducing their frequency saves time and effort:

  • Validate data thoroughly before initial submission.
  • Reconcile report data against source systems before generating the XML.
  • Test submissions using any available sandbox or test environments.
  • Keep user data up to date through regular self-certification renewal.

---

Disclaimer

This article provides general guidance on DAC8 correction procedures. The specific correction mechanisms, timing requirements, and message formats may vary by EU Member State and by the version of the XML schema in use. Always consult the relevant national tax authority's official documentation and, where appropriate, seek professional advice.

Need help with DAC8 reporting?

Our team handles XML generation, TIN validation, and submission for CASPs across all 27 EU Member States.

Get Expert Help