How to Create a DAC8 Reporting Workflow in 2026

DAC8 turns tax reporting into an operating requirement for crypto businesses, not a year-end exercise. Knowing how to create a DAC8 reporting workflow now gives founders and compliance teams time to fix the harder problem: connecting fragmented customer, wallet and transaction data to a defensible reporting process before the first filing cycle creates pressure.

For many crypto-asset service providers, the risk is not simply submitting a late report. It is submitting incomplete, inconsistent or poorly evidenced data to a tax authority, then being unable to explain how customer tax residencies, reportable transactions and corrections were determined. A workable process must therefore combine legal scoping, data engineering, compliance controls and clear accountability.

Start with the DAC8 perimeter, not the reporting file

DAC8 extends the EU framework for administrative co-operation in taxation to crypto-assets. From 1 January 2026, in-scope reporting crypto-asset service providers are generally expected to collect and maintain the relevant information, with the first reporting and exchange cycle following for the 2026 reporting period. National implementation rules, registration routes and technical schemas can vary, so businesses operating across several EU markets should validate the position in each relevant jurisdiction.

The first decision is whether your business is a Reporting Crypto-Asset Service Provider, commonly referred to as an RCASP, for DAC8 purposes. Do not assume that a MiCA authorisation, a non-EU incorporation or a particular product label answers that question on its own. The analysis depends on the services supplied, the crypto-assets covered, the customers served and the nexus that brings the provider within EU reporting rules.

Map each legal entity and each customer-facing service. Include exchange transactions, transfers, custody-related activity where applicable, platform settlement flows and arrangements involving stablecoins or tokenised assets. The aim is to establish a written scope memo that identifies: the reporting entity, relevant jurisdictions, reportable users, reportable crypto-assets, transaction categories and exclusions.

This document should be maintained as products change. A new fiat on-ramp, a white-label arrangement or an overseas affiliate taking over customer contracting can materially alter the reporting analysis.

Build one defensible data model

DAC8 reporting cannot be reliably produced from a collection of spreadsheets at year end. Most firms hold the required information across onboarding tools, CRM systems, blockchain analytics providers, trading engines, custody platforms, payments infrastructure and manual support records. A reporting workflow needs a common data model that links these sources at customer and transaction level.

For individual customers, the core dataset will usually include legal name, address, date and place of birth where required, tax residence or residences, tax identification number, jurisdiction of issue and the evidence supporting the self-certification. For entities, it must capture legal name, registered address, tax residence, TIN, controlling persons where relevant and entity classification.

Transaction records should retain the fields needed to identify reportable activity and calculate the required annual values. This normally means transaction type, date and time, asset, quantity, value, fees, wallet or account identifiers, counterparty information where available, and the data source. Your system should also preserve the methodology used for valuation, including the pricing source and timestamp.

The commercial temptation is to build a minimum viable report from whatever data is easiest to extract. That approach creates avoidable exposure. A better standard is traceability: every amount in the final submission should be capable of being traced back to source records, transformation logic and an approved rule.

Decide which system is the source of truth

A single source of truth does not require one software platform. It requires an agreed hierarchy. For example, the onboarding system may be authoritative for identity and self-certification data, while the trading ledger is authoritative for executed trades and the custody ledger for transfers.

Document this hierarchy and assign each source a business owner. Where fields conflict, the workflow must specify which record prevails, who investigates the discrepancy and how the correction is logged. Without that discipline, teams can unknowingly create different customer tax profiles in AML, operations and tax reporting systems.

Put DAC8 due diligence into onboarding and remediation

Reporting quality starts before a customer makes a transaction. DAC8 due diligence should be incorporated into new-user onboarding, not added as a separate annual collection campaign. Obtain tax residence self-certifications in a format that is clear, complete and capable of being retained. Validate the information against existing KYC records and apply reasonableness checks where there are indicators of inconsistency.

A customer who declares one tax residence but provides an address, telephone number or payment account in another jurisdiction may require further review. The right response depends on the facts and the applicable due diligence rules. It may be a straightforward request for a revised self-certification, or it may indicate a wider KYC and AML issue.

Existing customers need a structured remediation programme. Segment them by risk and data completeness, prioritising high-volume users, customers with missing TINs, legal entities with unclear classification and accounts showing indicia of multiple tax residences. Give operations teams approved communications, escalation criteria and deadlines. Repeated chaser emails with no ownership will not resolve a legacy dataset.

Create the control framework around the workflow

A DAC8 process needs named accountability across legal, tax, compliance, finance, operations and technology. One senior owner should be responsible for the overall reporting outcome, even where technical preparation is outsourced. That owner needs authority to require data remediation, approve filing decisions and escalate material issues to management.

The operational workflow should contain controls at each hand-off. At minimum, include controls over customer classification, tax-residency validation, transaction completeness, duplicate detection, valuation logic, report generation, submission approval and post-submission corrections. Keep evidence of each control, not merely a statement that it occurred.

For high-growth firms, a practical approach is to run the process through a controlled monthly close. Extract in-scope activity, reconcile it to platform totals, identify missing customer data and investigate exceptions before they accumulate. Monthly review is usually proportionate for exchanges and platforms with material transaction volume. A smaller provider may use quarterly review, but should still monitor onboarding exceptions continuously.

Reconcile data in more than one direction

Reconciliation should not only test whether reporting data matches a transaction ledger. It should test whether all active accounts and all relevant product flows have been considered. Compare customer populations across onboarding, platform, custody and payment systems. Compare reported transaction totals against finance and operational records. Investigate unusual movements, negative values, duplicated events and transactions that lack a customer identifier.

The most damaging reporting gaps are often architectural. For instance, a platform may correctly capture spot trades but omit activity processed by a separate custody environment or an acquired entity using different identifiers. Entity-level mapping and product-flow diagrams expose these omissions early.

Test the DAC8 reporting workflow before filing season

The first reporting year should include at least one full dry run. Use production-like data to generate a draft output, test the expected schema and review exceptions as if the submission deadline were real. This exercise identifies whether values can be calculated consistently, whether mandatory fields are available and whether the organisation can produce supporting evidence within a reasonable time.

Technical validation is only one part of testing. Compliance and legal teams should review a sample of customer classifications, tax-residency determinations and edge cases, including joint accounts, corporate customers, closed accounts, migrated users and customers with changing residency. Finance should test the reconciliation and valuation approach. Senior management should receive a concise record of key decisions, unresolved risks and remediation deadlines.

If a third-party reporting platform or provider is involved, contract management matters. Confirm data responsibilities, service levels, schema updates, correction support, audit access, confidentiality and responsibility for errors. Outsourcing preparation does not transfer the regulated business's accountability for the accuracy of the submission.

Treat corrections and record-keeping as part of the design

Customer data changes. Systems are migrated. A late-discovered wallet mapping error can alter annual figures. Your workflow should define how corrections are identified, assessed, approved and submitted under the relevant national process. Maintain a correction log that records the original report, the issue, impact assessment, root cause, approval and evidence of resubmission.

Retain the records behind self-certifications, validations, transaction calculations, reconciliations, decisions and filings for the required period. The precise retention rule should be checked against the applicable DAC8 implementation legislation and related data-protection obligations. Retention must be purposeful and access-controlled, particularly where tax identifiers and identity information are involved.

A DAC8 workflow is not a filing project that ends after submission. It is a control environment that should become more reliable with every monthly review, customer remediation cycle and product launch assessment. Businesses that build it into their operating model now will be better placed to protect bankability, demonstrate compliance maturity and keep regulatory expansion from delaying commercial growth.