Building the AccountReport Section in DAC8 XML

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

---

Overview

The AccountReport section is the core of every DAC8/CARF XML submission. It contains the identifying information for each reportable user and a summary of their crypto-asset transactions during the reporting period. Each AccountReport element represents one reportable person in one receiving jurisdiction.

This article walks through every field in the AccountReport section with practical implementation guidance.

AccountReport Structure

<AccountReport>
  <DocRefId>DE2026.CARF.000001</DocRefId>

  <AccountHolder>
    <Individual>
      <Name>
        <stf:FirstName>Jean</stf:FirstName>
        <stf:MiddleName>Pierre</stf:MiddleName>
        <stf:LastName>Dupont</stf:LastName>
      </Name>
      <Address>
        <stf:CountryCode>FR</stf:CountryCode>
        <stf:Street>15 Rue de Rivoli</stf:Street>
        <stf:City>Paris</stf:City>
        <stf:PostCode>75001</stf:PostCode>
        <stf:CountrySubentity>Ile-de-France</stf:CountrySubentity>
      </Address>
      <TIN issuedBy="FR">FR1234567890123</TIN>
      <BirthInfo>
        <BirthDate>1985-07-14</BirthDate>
        <City>Lyon</City>
        <CountryCode>FR</CountryCode>
      </BirthInfo>
      <Nationality>FR</Nationality>
    </Individual>
  </AccountHolder>

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

  <TransactionSummary>
    <TransactionType>EXCHANGE</TransactionType>
    <NumberOfTransactions>47</NumberOfTransactions>
    <AggregateGrossProceeds currCode="EUR">28500.00</AggregateGrossProceeds>
    <CryptoAssetDetails>
      <AssetCode>BTC</AssetCode>
      <TotalUnits>0.85000000</TotalUnits>
    </CryptoAssetDetails>
  </TransactionSummary>
</AccountReport>

Field-by-Field Guide

DocRefId

<DocRefId>DE2026.CARF.000001</DocRefId>

A unique document reference identifier for this specific account report. This ID must be unique not only within this message but across all messages you have ever submitted. It is the key used for corrections and amendments.

Recommended approach: Use a format that encodes the jurisdiction, year, and a sequence number, such as DE2026.CARF.000001. Store these IDs permanently in your database alongside the user record so that you can reference them in future correction submissions.

AccountHolder

The AccountHolder section identifies the reportable person. This can be either an Individual or an Entity (organisation).

Individual Account Holders

Name fields:

<Name>
  <stf:FirstName>Jean</stf:FirstName>
  <stf:MiddleName>Pierre</stf:MiddleName>
  <stf:LastName>Dupont</stf:LastName>
</Name>

Use the name as it appears in the self-certification provided by the user. The MiddleName field is optional. If your platform does not collect middle names, omit the element entirely rather than submitting an empty value.

Address:

<Address>
  <stf:CountryCode>FR</stf:CountryCode>
  <stf:Street>15 Rue de Rivoli</stf:Street>
  <stf:City>Paris</stf:City>
  <stf:PostCode>75001</stf:PostCode>
</Address>

The address should be the user's residence address as declared in their self-certification. The schema supports both structured address fields (Street, City, PostCode) and a free-text AddressFree field. Where possible, use structured fields for better data quality. If your system only stores a single address string, use AddressFree:

<Address>
  <stf:CountryCode>FR</stf:CountryCode>
  <stf:AddressFree>15 Rue de Rivoli, 75001 Paris, France</stf:AddressFree>
</Address>

Tax Identification Number (TIN):

<TIN issuedBy="FR">FR1234567890123</TIN>

The issuedBy attribute must contain the ISO country code of the jurisdiction that issued the TIN. A user may have TINs from multiple jurisdictions; include all that are relevant to the receiving country.

Important: If a TIN is unavailable and the jurisdiction does not issue TINs, you may need to indicate this using the appropriate reason code as defined in the schema. Do not fabricate TIN values.

Birth Information:

<BirthInfo>
  <BirthDate>1985-07-14</BirthDate>
  <City>Lyon</City>
  <CountryCode>FR</CountryCode>
</BirthInfo>

Date of birth is in YYYY-MM-DD format. Birth city and country are additional identifiers that help tax authorities match records. These fields may be required if a TIN is not available.

Entity Account Holders

For corporate or organisational users, use the Entity element instead of Individual:

<AccountHolder>
  <Entity>
    <Name>CryptoTrading SARL</Name>
    <Address>
      <stf:CountryCode>FR</stf:CountryCode>
      <stf:AddressFree>20 Avenue des Champs-Elysees, 75008 Paris</stf:AddressFree>
    </Address>
    <TIN issuedBy="FR">FR98765432100</TIN>
  </Entity>
</AccountHolder>

Entity reports follow the same overall structure, but birth information is not applicable.

AccountNumber

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

This is the internal account identifier your platform uses for this user. It allows the tax authority to cross-reference with future reports and corrections. Use whatever unique identifier your system assigns to users (user ID, account number, etc.).

TransactionSummary

<TransactionSummary>
  <TransactionType>EXCHANGE</TransactionType>
  <NumberOfTransactions>47</NumberOfTransactions>
  <AggregateGrossProceeds currCode="EUR">28500.00</AggregateGrossProceeds>
  <CryptoAssetDetails>
    <AssetCode>BTC</AssetCode>
    <TotalUnits>0.85000000</TotalUnits>
  </CryptoAssetDetails>
</TransactionSummary>

Each TransactionSummary covers one transaction type for one crypto-asset. If a user traded both BTC and ETH in exchange transactions, you would include two TransactionSummary blocks with TransactionType set to EXCHANGE -- one for BTC and one for ETH.

Key fields:

• TransactionType: The category of transaction (see the transaction types article for codes)
• NumberOfTransactions: Count of individual transactions in this category during the reporting period
• AggregateGrossProceeds: Total value of proceeds in the reporting currency. The currCode attribute must be a valid ISO 4217 currency code
• CryptoAssetDetails: Identifies the specific crypto-asset and the total units transacted

Multiple TransactionSummary Blocks

A single AccountReport can contain multiple TransactionSummary blocks. For example, if a user conducted both exchange and transfer transactions across multiple crypto-assets:

<AccountReport>
  <DocRefId>DE2026.CARF.000001</DocRefId>
  <AccountHolder><!-- ... --></AccountHolder>

  <TransactionSummary>
    <TransactionType>EXCHANGE</TransactionType>
    <!-- BTC exchange summary -->
  </TransactionSummary>

  <TransactionSummary>
    <TransactionType>EXCHANGE</TransactionType>
    <!-- ETH exchange summary -->
  </TransactionSummary>

  <TransactionSummary>
    <TransactionType>TRANSFER</TransactionType>
    <!-- BTC transfer summary -->
  </TransactionSummary>
</AccountReport>

Practical Tips

• Always validate TINs against known country formats where possible, but do not reject a TIN solely because you cannot validate its format -- formats vary significantly across jurisdictions.
• Store DocRefIds permanently. You will need them for any future corrections.
• Use structured addresses when your data allows it. Free-text addresses are acceptable but harder for tax authorities to process.
• One AccountReport per user per jurisdiction per file. Do not combine multiple users into a single AccountReport.