CARF crypto reporting

CARF is the OECD's global answer to crypto tax transparency — a worldwide standard for reporting and automatically exchanging crypto data between tax authorities. This page explains what it is, who must report, the timeline, and how CryptaCount produces the reports.

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

What CARF is

The Crypto-Asset Reporting Framework (CARF), published by the OECD in 2023, is a global standard requiring Reporting Crypto-Asset Service Providers (RCASPs) to identify their users, determine their tax residence, and report their crypto transactions — which tax authorities then automatically exchange with each other. It's modelled on the Common Reporting Standard (CRS) used for traditional financial accounts, extended to crypto. In the EU, CARF is implemented as DAC8. DAC8 →

The timeline

CARF is being adopted worldwide: a large number of jurisdictions — the majority of the OECD Global Forum's membership — have committed to begin exchanges, most starting in 2027 (some in 2028). Practically, providers collect data from the start of the relevant reporting year and file the following year, with the first international exchanges beginning around 2027.

Who's in scope

RCASPs are defined broadly — exchanges, brokers, certain wallet providers, and other intermediaries facilitating crypto transactions for customers. CARF also requires reporting of certain wallet transfers (including to self-hosted wallets), widening the data captured beyond simple trades. If you operate a platform, fund, or service handling crypto for others, assess whether you're an RCASP.

What it requires

Due-diligence and self-certification to establish each user's identity and tax residence, and annual reporting of transaction data in the OECD's prescribed XML schema — which is then exchanged between participating jurisdictions.

How CryptaCount helps with CARF

• Maintains the transaction-level records and user data reporting requires
• Generates CARF reports in the required format for filing
• Handles CARF and DAC8 together where both apply, from one integrated process
• Keeps a complete, auditable trail behind every reported figure

Compliance & reporting → · See the sub-ledger →

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

What CARF asks of a reporting business, in plain terms

Stripped of the acronyms, CARF is an information-reporting regime: the businesses it covers have to know who their customers are, where those customers are tax-resident, and what crypto activity flowed through them, then hand a structured summary of that to a tax authority that shares it with others. For an in-scope provider the obligation is therefore less about your own profit-and-loss and more about being able to render an accurate, attributable account of other people's transactions that passed across your platform. That distinction matters operationally, because the records that satisfy your statutory accounts under IFRS → or US GAAP → are not automatically the records that satisfy a reporting framework — the two ask different questions of the same underlying data.

Who actually carries the obligation is a question of substance rather than self-description. A business that merely holds crypto for its own treasury is in a very different position from one that facilitates transactions for customers, and the framework is deliberately drawn to capture intermediaries of many shapes. If your organisation operates an exchange, a brokerage, a custody or wallet service, or any platform where customers transact through you, the prudent starting point is to assume you may be in scope and to confirm your precise status against the official text and your advisor rather than assume the rules are aimed at someone else.

How CARF reporting reaches into your books

Even though CARF is a reporting framework rather than an accounting standard, preparing for it pulls hard on your bookkeeping. The customer balances and movements you report have to tie back to the same ledgers that produce your financial statements; if the two diverge, you are left explaining why your reported figures and your accounting figures tell different stories about the same wallets. In practice this means the crypto sub-ledger → that records every customer movement becomes the single source the report is built from, so that a number appearing on a regulatory return can be traced to the same posting that fed your trial balance.

It also changes what you capture at the moment a transaction happens. A book entry only needs enough to value and classify the movement; a reportable record additionally needs the counterparty attribution — which customer, in which jurisdiction, doing what type of activity — carried alongside it. Building that attribution in at the point of capture, rather than reconstructing it at filing time, is what keeps the eventual report defensible. The journal entries → behind each movement are where that contextual data naturally lives, so a sub-ledger that already stores rich per-transaction metadata gives you most of what the framework wants without a separate parallel system.

The data and audit trail CARF reporting depends on

A credible CARF report rests on a chain of evidence that runs from the raw on-chain or exchange event all the way to the figure you submit. At a minimum that chain needs the transaction-level detail — date, asset, quantity, and value — joined to customer identity and residence data and to the classification of the activity, all preserved in a form you can reproduce on request. Because reporting frameworks are built on the premise that authorities can cross-check what providers send, the credibility of your submission depends on every reported total being decomposable back into the individual movements that make it up.

• Immutable transaction records — the underlying events captured once and never silently overwritten, so a figure can always be re-derived from source.
• Customer and residence attribution — each reportable movement tied to the verified party behind it, since the framework reports activity by person, not just in aggregate.
• Valuation provenance — where each value came from and the date it was struck, so an auditor or authority can see how a converted figure was reached.
• Change history — a record of corrections and restatements, because a report submitted last year may need an explainable amendment this year.
• Reconciliation linkage — a visible thread from the report back to the same ledger that produced your statutory accounts.

The reconciliation challenge behind a CARF return

The hardest part of reporting is rarely the format — it is making sure the population is complete and consistent. Crypto activity arrives from many venues at once: several chains, multiple exchanges, custody systems, and internal transfers, each with its own identifiers and quirks. Before any of it can be reported, the same economic event has to be recognised once and only once, duplicates from overlapping data feeds have to be collapsed, and internal movements between your own wallets have to be distinguished from genuine customer activity. Get that wrong and a report is either overstated by double-counting or understated by silent gaps — both of which are exactly the kind of discrepancy a cross-border exchange of information is designed to surface.

This is where the discipline that already underpins good crypto accounting pays off twice. The deduplication, transfer-matching, and chronological ordering you need for clean books are the same controls that make a reporting population trustworthy. Rather than running a separate, lossy export just for the regulatory return, you reconcile once at the ledger level and let both your accounts and your report draw on the reconciled result, so the two can never quietly drift apart.

How a crypto sub-ledger supports CARF compliance

A purpose-built crypto sub-ledger is the natural backbone for CARF because it already does the unglamorous work the framework assumes: ingesting activity from every wallet and venue, normalising it into consistent records, valuing each movement, and keeping an unbroken trail behind every figure. When the reportable data and the accounting data come from one reconciled store, producing a report becomes a matter of selecting and shaping existing records rather than rebuilding the underlying truth from scratch. That is the whole logic of the compliance and reporting → layer sitting on top of the ledger rather than beside it.

It also future-proofs you against the fact that CARF rarely travels alone. In the EU the same obligations arrive as DAC8 →, and a provider operating across borders may face aligned-but-distinct demands in several places at once. A sub-ledger that holds one reconciled dataset, richly attributed, lets you generate each framework's output from the same foundation instead of maintaining a brittle spreadsheet per regime.

Scope and timing, at a general level

On timing, the only safe generalisation is the shape rather than the specifics: reporting frameworks of this kind typically have providers collect data across a reporting period and file in the period that follows, with international exchange of the information beginning once enough jurisdictions are live. The existing page above sets out the broad adoption picture; beyond that, the precise dates, registration mechanics, and first-exchange timing for your jurisdiction are matters to confirm against the official text and your advisor, because they vary by country and continue to be implemented in stages.

On scope, the practical question for an accounting team is less "what is the legal definition" and more "which of our activities and customers fall inside the population we must report." That assessment touches the kinds of crypto-assets you handle, the nature of the services you provide, and where your customers are resident. Because the boundary can be genuinely finely balanced, it is worth documenting your scope reasoning as carefully as the figures themselves — a defensible position on why something was or was not reported is part of the audit trail.

Common pitfalls in preparing for CARF

• Treating reporting as a year-end export. Attribution data captured months after the fact is far weaker than data captured at the moment of the transaction; bolt-on exports tend to lose exactly the customer and residence context the framework needs.
• Letting the report diverge from the accounts. If your regulatory totals cannot be reconciled to your ledger, you have two versions of the truth and no way to defend either.
• Double-counting across overlapping feeds. The same movement arriving from both an exchange API and an on-chain read inflates the population unless it is deduplicated once at the ledger.
• Mislabelling internal transfers as customer activity. Moving crypto between your own wallets is not reportable customer activity, but it pollutes the report if it is not distinguished.
• Assuming one jurisdiction's approach fits all. Aligned frameworks are not identical; a process built only for one regime can quietly miss another's requirements.
• No change history. Without a record of corrections, an amended report looks like an inconsistency rather than a tracked restatement.

How CryptaCount helps with CARF

CryptaCount approaches CARF as a downstream product of a well-kept ledger rather than a separate compliance silo. It ingests activity across your wallets, chains, and connected venues into one reconciled crypto sub-ledger, carries the per-transaction context the framework cares about, and keeps an unbroken, auditable trail behind every figure — so a number on a report can always be traced to the posting it came from. Because the same reconciled dataset feeds your statutory accounts and your reporting, there is one version of the truth rather than two that have to be kept in sync by hand. Where CARF and DAC8 obligations overlap, both are produced from that single foundation, and the scope and format specifics are something to settle with your advisor against the official text.

Does CARF replace our normal crypto accounting?

No — it sits on top of it. Your accounting under IFRS → or US GAAP → measures and presents your own position; CARF is a separate, customer-attributed reporting obligation. The point of connection is the data: both should draw on the same reconciled sub-ledger → so the figures never diverge.

We operate across several countries — does that complicate CARF?

It can, because aligned frameworks like CARF and its regional implementations are similar but not identical, and your customers' residences span jurisdictions. The practical mitigation is to hold one richly attributed dataset and generate each required output from it, rather than maintaining a separate process per country. The precise multi-jurisdiction obligations are something to confirm with your advisor.

What records will an auditor or authority expect behind a CARF figure?

Broadly, a path from the reported total down to the individual transactions that compose it, with each movement's value provenance, its customer and residence attribution, and any corrections all preserved. That is exactly the kind of trail a transaction-level sub-ledger keeps as a matter of course, which is why building the report off the ledger is more defensible than building it off a flat export.

How early should we start preparing for CARF?

Earlier than the first filing date, because the quality of a report depends on data captured contemporaneously — especially customer and residence attribution that is hard to reconstruct later. Establishing a reconciled ledger with the right metadata before the first reporting period means the eventual report is a selection exercise rather than a reconstruction. The specific deadlines for your jurisdiction should be confirmed against the official text and your advisor.