How to Submit DAC8 Corrections and Amendments

Category: XML Templates Last Updated: 2026-02-12 Applies To: EU DAC8 / OECD CARF XML Schema

---

Overview

After submitting a DAC8/CARF XML report, you may discover errors in the data or receive updated information from users. The OECD CARF framework provides a structured mechanism for submitting corrections and amendments. Understanding how this works is critical -- incorrect correction submissions can create data integrity issues that are difficult to resolve.

This article covers the correction workflow, the XML structure for corrections, and the difference between corrections and void messages.

When Corrections Are Needed

Common scenarios that require a corrected submission:

• A user updates their self-certification with a new TIN or address
• You discover an error in aggregate transaction values
• A user's tax residency was incorrectly assigned
• Transaction data was incomplete or duplicated in the original report
• The tax authority requests a correction after reviewing your submission

Correction vs. Void

The CARF schema supports two types of corrective actions:

Correction (CorrDocRefId)

A correction replaces a previously submitted AccountReport with updated data. The original report is superseded by the corrected version.

Use when: The data for a user needs to be updated but the user should still appear in the report.

Void (CorrDocRefId with empty AccountReport)

A void cancels a previously submitted AccountReport entirely. It indicates that the original report should be treated as if it was never submitted.

Use when: A user was reported in error (e.g., they are not actually tax-resident in the receiving jurisdiction, or they are not a reportable person).

XML Structure for Corrections

Correcting an AccountReport

To correct a previously submitted account report, include the CorrDocRefId element referencing the original DocRefId, and provide a new DocRefId for the correction:

<CARFBody>
  <ReportingFI>
    <!-- Same reporting entity details -->
  </ReportingFI>

  <AccountReport>
    <!-- New unique DocRefId for this correction -->
    <DocRefId>DE2026.CARF.000001.C1</DocRefId>

    <!-- Reference to the original DocRefId being corrected -->
    <CorrDocRefId>DE2026.CARF.000001</CorrDocRefId>

    <!-- Updated account holder information -->
    <AccountHolder>
      <Individual>
        <Name>
          <stf:FirstName>Jean</stf:FirstName>
          <stf:LastName>Dupont</stf:LastName>
        </Name>
        <Address>
          <stf:CountryCode>FR</stf:CountryCode>
          <stf:AddressFree>22 Boulevard Haussmann, 75009 Paris, France</stf:AddressFree>
        </Address>
        <!-- Corrected TIN -->
        <TIN issuedBy="FR">FR9876543210987</TIN>
        <BirthInfo>
          <BirthDate>1985-07-14</BirthDate>
          <City>Lyon</City>
          <CountryCode>FR</CountryCode>
        </BirthInfo>
      </Individual>
    </AccountHolder>

    <AccountNumber>USR-00042-PLATFORM</AccountNumber>

    <!-- Corrected transaction summary -->
    <TransactionSummary>
      <TransactionType>EXCHANGE</TransactionType>
      <NumberOfTransactions>48</NumberOfTransactions>
      <AggregateGrossProceeds currCode="EUR">29100.00</AggregateGrossProceeds>
      <CryptoAssetDetails>
        <AssetCode>BTC</AssetCode>
        <TotalUnits>0.87000000</TotalUnits>
      </CryptoAssetDetails>
    </TransactionSummary>
  </AccountReport>
</CARFBody>

Voiding an AccountReport

To void (cancel) a previously submitted report, use CorrDocRefId and provide a minimal or empty AccountReport with an appropriate indicator:

<AccountReport>
  <!-- New DocRefId for the void action -->
  <DocRefId>DE2026.CARF.000001.V1</DocRefId>

  <!-- Reference to the original report being voided -->
  <CorrDocRefId>DE2026.CARF.000001</CorrDocRefId>

  <!-- DocTypeIndic indicates this is a void/deletion -->
  <DocTypeIndic>OECD3</DocTypeIndic>
</AccountReport>

> Note: The exact mechanism for voids (whether a DocTypeIndic element or an attribute is used) depends on the final schema version. The OECD CRS uses DocTypeIndic codes such as OECD1 (new data), OECD2 (corrected data), and OECD3 (deletion/void). The CARF schema is expected to follow a similar pattern, but verify against the published XSD.

Correcting the MessageSpec

When submitting a correction file, the MessageSpec should reference the original message:

<MessageSpec>
  <SendingCompanyIN>DE1234567890</SendingCompanyIN>
  <TransmittingCountry>DE</TransmittingCountry>
  <ReceivingCountry>FR</ReceivingCountry>
  <MessageType>CARF</MessageType>
  <MessageRefId>DE2026.MSG.FR.00002</MessageRefId>
  <!-- Reference to the original message being corrected -->
  <CorrMessageRefId>DE2026.MSG.FR.00001</CorrMessageRefId>
  <ReportingPeriod>2026-12-31</ReportingPeriod>
  <Timestamp>2027-05-20T09:15:00Z</Timestamp>
</MessageSpec>

Key points:

• MessageRefId must be a new, unique value (not the same as the original)
• CorrMessageRefId references the MessageRefId of the original submission
• ReportingPeriod remains the same as the original (you are correcting data for the same year)
• Timestamp reflects when the correction was generated

Correction Chains

If you need to correct a correction, reference the most recent DocRefId, not the original:

Original:    DocRefId = DE2026.CARF.000001
Correction:  DocRefId = DE2026.CARF.000001.C1  -->  CorrDocRefId = DE2026.CARF.000001
Correction2: DocRefId = DE2026.CARF.000001.C2  -->  CorrDocRefId = DE2026.CARF.000001.C1

Always reference the immediately preceding version. Do not skip intermediate corrections.

Timing Requirements

The timing for submitting corrections depends on the jurisdiction, but general principles apply:

• Errors discovered before the filing deadline: Correct and resubmit before the deadline. Some jurisdictions may treat pre-deadline corrections differently from post-deadline amendments.
• Errors discovered after the filing deadline: Submit the correction as soon as reasonably practicable. Most jurisdictions expect corrections within a defined period (often 30 to 90 days of discovering the error).
• Tax authority-requested corrections: Respond within the timeframe specified in the request.

Practical Implementation Guidance

Database Requirements

Your system must permanently store:

• Every DocRefId ever generated, linked to the user and reporting period
• Every MessageRefId ever generated, linked to the receiving jurisdiction and reporting period
• The status of each report (original, corrected, voided)
• The correction chain (which DocRefId corrects which)

Generating Correction Files

A correction file can contain a mix of new reports, corrections, and voids. For example, a single file might contain:

<CARFBody>
  <ReportingFI><!-- ... --></ReportingFI>

  <!-- Corrected report for User A -->
  <AccountReport>
    <DocRefId>DE2026.CARF.000001.C1</DocRefId>
    <CorrDocRefId>DE2026.CARF.000001</CorrDocRefId>
    <!-- ... corrected data ... -->
  </AccountReport>

  <!-- Voided report for User B (reported in error) -->
  <AccountReport>
    <DocRefId>DE2026.CARF.000002.V1</DocRefId>
    <CorrDocRefId>DE2026.CARF.000002</CorrDocRefId>
    <DocTypeIndic>OECD3</DocTypeIndic>
  </AccountReport>

  <!-- New report for User C (not in original submission) -->
  <AccountReport>
    <DocRefId>DE2026.CARF.000050</DocRefId>
    <!-- No CorrDocRefId -- this is new data -->
    <!-- ... user C data ... -->
  </AccountReport>
</CARFBody>

Testing Corrections

Before submitting corrections to production:

1. Validate the correction file against the XSD schema
2. Verify that all CorrDocRefId values reference valid, previously submitted DocRefId values
3. Confirm that new DocRefId values are unique
4. Test the correction workflow end-to-end in a sandbox environment if your tax authority provides one