DAC8 crypto reporting

DAC8 brings crypto into the EU's tax-information-exchange system. From 2026, crypto-asset service providers must collect and report user and transaction data — and the first reports are due in 2027. This page explains who's in scope, the timeline, and how CryptaCount produces the reports.

General information, not legal or tax advice. Confirm your specific obligations against the directive and a qualified advisor.

What DAC8 is

DAC8 (Council Directive (EU) 2023/2226) extends the EU's Directive on Administrative Cooperation to cover crypto-assets. It requires Reporting Crypto-Asset Service Providers (RCASPs) — exchanges, brokers, certain wallet providers and other platforms facilitating crypto transactions for customers — to carry out due diligence on their users and report their identity, tax residence, and transactions to national tax authorities. It's the EU's implementation of the OECD's CARF, so the two are deliberately aligned. CARF →

The timeline

• Transposition: EU member states were to transpose DAC8 into national law by 31 December 2025.
• Data collection: reporting obligations apply from 1 January 2026 — the first reporting year.
• First reports: reports covering the 2026 calendar year are due in 2027 (broadly between January and September 2027, depending on the member state).

Who's in scope

RCASPs are defined broadly. The rules are also extraterritorial — a platform based outside the EU that serves EU-resident users can fall within scope and may need to register with a designated member state. If you operate a platform, fund, or service that facilitates crypto transactions for others, you should assess whether DAC8 applies to you.

What it requires

Collecting validated user information (including tax identification and residence), applying due-diligence procedures to new and pre-existing users, and reporting transaction-level data in the prescribed format and deadline each year.

How CryptaCount helps with DAC8

• Maintains the transaction-level records and user data the reporting depends on
• Generates DAC8 operator reports in the required format for filing
• Keeps a complete, auditable trail behind every reported figure
• Aligns with CARF so overlapping obligations are handled together

Compliance & reporting → · See the sub-ledger →

General information, not legal or tax advice. Verify against the directive and a qualified advisor.

What DAC8 asks of a reporting provider, in plain terms

At its core DAC8 brings crypto into the EU's existing machinery for exchanging tax information between member states. For a provider in scope, the obligation has three moving parts: identify your customers and establish their tax residence through due diligence, capture their reportable crypto activity over the year, and file a structured report that national authorities then share with one another. It is the EU's expression of the same logic that drives the OECD's CARF →, which is why the two are deliberately aligned and why a process built well for one tends to serve the other.

Because DAC8 is a reporting regime rather than an accounting standard, the obligation centres on other people's transactions passing through your platform rather than on your own profit and loss. That reframes what "good records" means: a movement is not adequately recorded for DAC8 just because it is correctly valued in your books — it also has to carry the customer attribution and residence context the report is built around. Establishing exactly which providers and activities fall in scope, and what each report must contain, is something to confirm against the directive and your advisor rather than infer.

How DAC8 reaches into your books

Preparing a DAC8 report leans heavily on the same ledger that produces your financial statements. The customer balances and movements you report should reconcile to the records behind your accounts, because a regulatory return that cannot be tied back to your bookkeeping invites exactly the discrepancy that an exchange-of-information regime is designed to catch. In practice the crypto sub-ledger → that already records every customer movement becomes the source the report is shaped from, so a figure on the return traces to the same posting that fed your trial balance.

It also raises the bar on what you capture when a transaction first occurs. An ordinary book entry needs enough to value and classify a movement; a DAC8-reportable record additionally needs the who and where — which customer, resident in which member state, doing what. Capturing that attribution at the point of entry, where the journal entries → for each movement are formed, is far more reliable than reconstructing it at filing time from fragmentary exports.

The data and audit trail DAC8 depends on

A defensible DAC8 report is only as good as the evidence chain beneath it, running from the original event to the figure you submit. That chain needs transaction-level detail joined to verified customer identity and residence, the classification of each activity, and a preserved record of how every value was struck — all reproducible on request. Reporting frameworks assume authorities can cross-check what providers send, so each reported total has to decompose cleanly back into the individual movements that built it.

• Validated customer information — identity and tax-residence data gathered through due diligence and kept current, since the report is organised by person.
• Transaction-level records — the underlying movements captured once, immutably, so any total can be re-derived from source.
• Valuation provenance — the source and date behind each converted value, so a figure's derivation is visible.
• Classification of activity — what each movement was, captured alongside it rather than guessed later.
• Correction history — a tracked record of any restatement, so an amended filing reads as a managed change, not an error.

The reconciliation challenge behind a DAC8 filing

As with any reporting regime, the difficulty is not the form but the completeness and consistency of the population. Customer activity arrives from many places — multiple chains, several exchanges, custody systems, internal transfers — each with its own identifiers. Before a single figure is reported, the same economic event must be recognised exactly once, overlapping data feeds must be deduplicated, and movements between your own wallets must be separated from genuine customer activity. Failing any of these leaves a report overstated by double-counting or understated by gaps, and a cross-border information exchange is precisely the mechanism that surfaces such mismatches.

The encouraging part is that the controls which give you clean books — deduplication, transfer-matching, consistent valuation, chronological ordering — are the same controls that make a DAC8 population trustworthy. Reconciling once at the ledger level, and letting both your accounts and your report draw on the reconciled result, is far more robust than producing a separate, lossy export purely for the filing and hoping it agrees with the books.

How a crypto sub-ledger supports DAC8 compliance

A crypto sub-ledger is well suited to DAC8 because it already performs the groundwork the directive assumes: pulling activity in from every venue, normalising it, valuing each movement, and holding an unbroken trail behind every figure. When the reportable data and the accounting data share one reconciled store, the filing becomes a matter of selecting and formatting existing, attributed records rather than rebuilding the underlying truth. That is the rationale for placing the compliance and reporting → capability on top of the ledger rather than alongside it as a disconnected tool.

It also handles the reality that DAC8 overlaps with its global parent. Because DAC8 is the EU's implementation of CARF, a provider facing both can generate each output from the same reconciled dataset instead of running parallel processes that must be kept in step by hand. One foundation, richly attributed, supports the CARF → and DAC8 outputs together, which is exactly how overlapping obligations should be met.

Scope and timing, at a general level

The existing page above already sets out the broad transposition-and-first-report shape, and the safe generalisation is just that: providers collect across a reporting period and file in the following one, with member states implementing the detail in their own national law. Beyond that, the precise registration mechanics, formats, and deadlines that apply to your business — including how the directive's extraterritorial reach treats a provider serving EU-resident customers from outside the bloc — are matters to confirm against the directive and your advisor, because they differ in the detail by member state.

For an accounting team the more useful framing of scope is operational: which of our customers are EU-resident, which of our activities are reportable, and can we evidence that determination. Because the boundary can be finely balanced — particularly for cross-border providers — documenting why something was or was not reported belongs in the audit trail alongside the figures. A defensible scope rationale is part of compliance, not a footnote to it.

Common pitfalls in preparing for DAC8

• Late attribution. Capturing customer and residence context at year-end rather than at the transaction loses exactly the data DAC8 is built around.
• Reports that don't tie to the books. A return that cannot be reconciled to your ledger leaves you with two versions of the truth and no defence for either.
• Double-counting overlapping feeds. The same movement seen via both an exchange API and an on-chain read inflates the population unless deduplicated once at the ledger.
• Internal transfers reported as customer activity. Your own wallet-to-wallet moves are not reportable customer activity and must be distinguished.
• Assuming non-EU means out of scope. The directive's reach can extend to providers serving EU-resident customers regardless of where the provider is based — confirm your position with your advisor.
• No correction trail. An amended filing without a tracked change history reads as an inconsistency rather than a managed restatement.

How CryptaCount helps with DAC8

CryptaCount treats DAC8 as the output of a well-maintained ledger rather than a bolt-on filing exercise. It ingests activity across your wallets, chains, and connected venues into one reconciled crypto sub-ledger, carries the customer-attributed context DAC8 reporting depends on, and keeps a complete, auditable trail behind every figure so each reported number traces back to its source posting. Because the same reconciled dataset produces your accounts and your report, there is a single version of the truth instead of two to keep aligned by hand — and where DAC8 and CARF overlap, both are generated from that one foundation. The exact scope, registration, and format specifics for your business remain matters to settle with your advisor against the directive.

How is DAC8 different from CARF in practice for our systems?

For your data and systems they are very similar, because DAC8 is the EU's implementation of CARF →. The differences live in the jurisdiction-specific detail — registration, formats, and deadlines per member state. The practical implication is to hold one reconciled, attributed dataset and generate each output from it rather than building separate processes. Confirm the specifics with your advisor.

Does DAC8 change how we recognise crypto in our own accounts?

No — your own measurement and presentation follow your accounting framework, whether IFRS → or US GAAP →. DAC8 is a separate, customer-focused reporting obligation. They connect through shared data: both should draw on the same reconciled sub-ledger → so the report and the accounts cannot drift apart.

What evidence sits behind a DAC8 figure if we are questioned?

A traceable path from the reported total to the individual customer transactions composing it, with each movement's valuation provenance, identity and residence attribution, and any corrections preserved. That is the standard trail a transaction-level sub-ledger maintains, which is why building the filing off the ledger is more defensible than off a flat export.

We're a non-EU provider with EU customers — do we need to care about DAC8?

Possibly — the directive's reach can extend based on where customers are tax-resident rather than where the provider is incorporated, and it may involve registering with a designated member state. Because this is exactly the kind of boundary that is finely balanced, your specific position should be confirmed against the directive and your advisor rather than assumed.