Resource center · Digital Assets

Transaction and asset type mappings for crypto reporting.

A reference sheet for the mapping layer: which ledger events fall into which reporting category, what is measured for each, and the asset identity decisions that have to be made once and applied consistently.

Dataset CARF / DAC8 · Multi-jurisdiction · transaction mapping

The reporting unit

The framework does not report trades. It reports an aggregate identified by four things together: the user, the reporting period, the crypto-asset, and the transaction category. Everything in the mapping layer exists to get ledger rows into that shape without losing or double-counting anything.

Ledger events to categories

Mapping ledger events to reporting categories
Ledger eventCategoryNote
Purchase of a crypto-asset with fiatExchange against fiatAcquisition side. Reported gross, not netted against disposals.
Sale of a crypto-asset for fiatExchange against fiatDisposal side, reported separately from acquisitions.
Trade of one crypto-asset for anotherExchange between crypto-assetsProduces an acquisition and a disposal, each valued at the time of the transaction.
Deposit received on-chainTransfer inDistinct from any exchange it subsequently funds.
Withdrawal sent on-chainTransfer outSplit by whether the destination is associated with a known provider.
Payment to a merchant in crypto-assetsTransfer, retail payment treatmentThe framework treats retail payment transactions over a defined value as a distinct case.
Movement between a user’s own accountsNot a transfer outInternal movement. Treating it as a transfer inflates the reported population.
Cancelled or reversed transactionExcludedExcluded consistently under a documented policy rather than netted arbitrarily.

What is measured

  • Value — in fiat for exchanges against fiat; at fair market value for exchanges between crypto-assets and for transfers.
  • Number of units — reported alongside value, so rounding and precision policy for fractional units matters as much as the fiat figure.
  • Number of transactions — the count behind the aggregate.
Retain the rate with the aggregate. A reported value that cannot be reproduced from a stored rate is a value you cannot defend later. One valuation source per asset, recorded, applied identically to acquisitions and disposals.

Asset identity decisions

Four decisions have to be made once and applied to every period, including retrospectively when a comparison is drawn:

  1. Asset identity. Whether the same underlying asset under different tickers, on different chains, or in wrapped and bridged forms is one reportable asset or several.
  2. User identity. Aggregation is per user, not per account, so merged accounts, sub-accounts and corporate hierarchies must resolve to one reportable person.
  3. Period boundary. The ledger timezone and the reporting calendar must agree, or transactions near period end move between periods.
  4. Reversal policy. Which corrections unwind an original transaction and which stand as separate events.

Events that need a policy

Some ledger events do not map cleanly and need a documented position rather than an implicit one: staking rewards and similar accruals; airdrops and other unsolicited receipts; forks producing a new asset; fee-only movements; and transfers to addresses that cannot be attributed to a provider. Each of these should have a written treatment that a reviewer can read, because the mapping is where a supervisor or auditor will look first.

Using this safely

This sheet describes the mapping problem, not the field-level specification. Element names, allowed values, thresholds and the treatment of individual transaction types are set out in the framework’s schema and user guide, and in any national variant a jurisdiction mandates. Interpretation in this area is developing actively, so confirm against the current edition rather than a prior cycle.

Official sources

Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.

  1. OECD — Crypto-Asset Reporting Framework XML Schema: User Guide for Tax AdministrationsOECD · message structure, transaction categories and reported measures
  2. OECD — release of the CARF and amended CRS XML schemas and interpretative guidanceOECD · scope and treatment of transaction types
  3. Council Directive (EU) 2023/2226 (DAC8) amending Directive 2011/16/EU on administrative cooperation in the field of taxationEUR-Lex · Directive · the Union implementation

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.

Keep reading

More on this framework, and the module that produces the filing.

All digital assets resources

Map once, then aggregate automatically.

Bring your ledger in the shape your systems hold it. The module handles categorisation, aggregation and schema validation.