Category: XML Templates Last Updated: 2026-02-12 Applies To: EU DAC8 / OECD CARF XML Schema
---
Overview
The MessageSpec element is the header of every DAC8/CARF XML report. It tells the receiving tax authority who is sending the data, where it is going, what type of message it is, and which reporting period it covers. Getting any of these fields wrong can result in rejected submissions or misrouted data.
This article explains each field in the MessageSpec section with practical guidance on how to populate them correctly.
The MessageSpec Structure
<MessageSpec>
<SendingCompanyIN>DE1234567890</SendingCompanyIN>
<TransmittingCountry>DE</TransmittingCountry>
<ReceivingCountry>FR</ReceivingCountry>
<MessageType>CARF</MessageType>
<MessageRefId>DE2026.MSG.FR.00001</MessageRefId>
<CorrMessageRefId/>
<ReportingPeriod>2026-12-31</ReportingPeriod>
<Timestamp>2027-03-15T10:30:00Z</Timestamp>
</MessageSpec>
Field-by-Field Guide
SendingCompanyIN
<SendingCompanyIN>DE1234567890</SendingCompanyIN>
This is the identification number of the entity submitting the report. Depending on the jurisdiction, this could be:
- A local tax identification number (TIN) assigned to the Reporting Crypto-Asset Service Provider (RCASP)
- A Global Intermediary Identification Number (GIIN) if the jurisdiction uses one
- A registration number assigned during RCASP registration
Practical note: This value must exactly match what the tax authority has on file for your entity. A mismatch will likely cause the submission to be rejected at the gateway level. Confirm the expected format with your local tax authority before first submission.
TransmittingCountry
<TransmittingCountry>DE</TransmittingCountry>
The ISO 3166-1 alpha-2 country code of the jurisdiction from which the report is being transmitted. This is typically the country where the RCASP is registered or established for DAC8 purposes.
Important: If your platform is registered in multiple EU member states, the transmitting country should correspond to the specific registration under which you are filing. Under the DAC8 single-registration mechanism, this would be the member state of registration.
ReceivingCountry
<ReceivingCountry>FR</ReceivingCountry>
The ISO 3166-1 alpha-2 country code of the jurisdiction that should receive this report. Each XML file is addressed to exactly one receiving country.
Practical note: You must generate a separate XML file for each receiving jurisdiction. If you have reportable users tax-resident in France, Germany, and Italy, you produce three separate XML files, each with a different ReceivingCountry value.
MessageType
<MessageType>CARF</MessageType>
For DAC8 crypto-asset reporting, this value should be CARF. This distinguishes the message from other automatic exchange of information formats (such as CRS or FATCA). Some jurisdictions may define additional message type values; check local guidance.
MessageRefId
<MessageRefId>DE2026.MSG.FR.00001</MessageRefId>
A unique reference identifier for this specific message. This ID must be unique across all messages you have ever sent. It is used to reference this message in future corrections or amendments.
Recommended format: While the schema does not mandate a specific format, a practical convention is:
{CountryCode}{Year}.MSG.{ReceivingCountry}.{SequenceNumber}
For example: DE2026.MSG.FR.00001
This makes it easy to trace messages back to specific reporting periods and jurisdictions. Whatever format you choose, ensure your system stores these IDs permanently so you can reference them when submitting corrections.
CorrMessageRefId
<CorrMessageRefId/>
This field is used only when submitting a correction or amendment to a previously submitted message. For an original (first-time) submission, leave this element empty or omit it if the schema allows.
When submitting a correction, populate this with the MessageRefId of the original message being corrected:
<CorrMessageRefId>DE2026.MSG.FR.00001</CorrMessageRefId>
See the article on corrections and amendments for detailed guidance on how correction workflows operate.
ReportingPeriod
<ReportingPeriod>2026-12-31</ReportingPeriod>
The last day of the calendar year covered by the report, in YYYY-MM-DD format. DAC8 reporting is on an annual basis aligned to the calendar year.
For the first DAC8 reporting year (2026), this value is 2026-12-31. The first reportable period under DAC8 begins January 1, 2026, as specified in Article 8ad(6) of the directive. Do not use the first day of the year or any other date.
Important: The reporting period is the calendar year in which the reportable transactions occurred, not the year in which you are submitting the report. A report filed in 2027 covering 2026 activity would show 2026-12-31.
Timestamp
<Timestamp>2026-03-15T10:30:00Z</Timestamp>
The date and time when the XML message was generated, in ISO 8601 format. Use UTC (indicated by the Z suffix) to avoid timezone ambiguity.
Practical note: Generate this timestamp at the moment of XML file creation, not at the time data was extracted. If you regenerate a file, update the timestamp accordingly.
Common Mistakes to Avoid
- Reusing MessageRefId values. Every message must have a globally unique reference. Using duplicate IDs will cause rejections or data integrity issues.
- Wrong ReceivingCountry. Double-check that user records are matched to the correct jurisdiction. A French tax resident's data sent to Germany benefits nobody.
- Incorrect ReportingPeriod format. It must be the last day of the year (
YYYY-12-31), not the first day or any arbitrary date.
- Non-UTC timestamps. While some systems may accept local times with offset notation, UTC is the safest choice and avoids any ambiguity.
- SendingCompanyIN mismatch. If your registered ID with the tax authority changes (e.g., after a corporate restructuring), update this field immediately. Stale IDs cause silent failures.
Validation Checklist
Before submitting, verify that:
- [ ]
SendingCompanyINmatches your registered tax authority ID exactly - [ ]
TransmittingCountryis the correct ISO alpha-2 code for your registration - [ ]
ReceivingCountrymatches the tax residency of the users in this file - [ ]
MessageTypeis set toCARF - [ ]
MessageRefIdis unique and stored in your records - [ ]
CorrMessageRefIdis empty for original submissions - [ ]
ReportingPeriodisYYYY-12-31for the correct year - [ ]
Timestampis in ISO 8601 UTC format
Getting the MessageSpec right is the foundation of a successful DAC8 submission. Errors here affect the entire file and are often the first thing validated by receiving systems.
Need help with DAC8 reporting?
Our team handles XML generation, TIN validation, and submission for CASPs across all 27 EU Member States.