Tax · UK Reporting
Common Mistakes UK Traders Make When Exporting Crypto History for HMRC
Exporting your Coinbase or Kraken transaction history for HMRC sounds straightforward. Both platforms have export functions, several tax software tools will import the files, and the broad process is well documented. But in practice, a number of specific mistakes regularly cause problems — wrong date ranges, missing transaction types, misclassified wallet transfers, and incomplete historical data that produces inaccurate cost basis figures. This article covers the most common pitfalls and how to avoid them.
- The UK tax year does not match the calendar year — wrong date ranges are a common error
- Kraken requires two separate exports — trades and ledger — not just one
- Wallet transfers misclassified as disposals can produce phantom gains
- Missing older records causes cost basis errors that affect every subsequent calculation
Why this matters more now
CARF means HMRC will have your exchange data — whether your return matches or not
From 1 January 2026, UK-facing cryptocurrency exchanges including Coinbase and Kraken are required to report detailed transaction data directly to HMRC under the Cryptoasset Reporting Framework (CARF). The first reports cover the 2026 calendar year, with data due to HMRC by May 2027.
This changes the stakes significantly. In previous years, HMRC's visibility of individual crypto activity depended largely on whether users self-reported accurately. From 2027, HMRC will be able to cross-reference Self Assessment returns against exchange-reported transaction data automatically. Discrepancies between what an individual declares and what the exchange reports — including omitted transactions, incorrect gain figures, or missing income from staking — will be much easier for HMRC to identify.
This is not a reason to panic, but it is a reason to be precise. The most common errors in crypto tax reporting are not deliberate — they are the result of misunderstanding how to export data correctly, what counts as a taxable event, and how tax software processes the records it receives. Getting these right from the start is considerably easier than correcting a submitted return later.
What this means
Exporting trade history from an exchange is the first step — but HMRC's matching rules (same-day, 30-day bed-and-breakfast, section 104 pool) mean raw CSV exports cannot simply be totalled. The calculation methodology matters as much as the data itself. This is context, not advice.
Mistake 1
Using the wrong date range — exporting by calendar year instead of UK tax year
This is the single most common error, and it is entirely understandable. Both Coinbase and Kraken present their export interfaces with calendar year options and date pickers. It is easy to export January to December and assume that covers the tax year. It does not.
The UK tax year runs from 6 April to 5 April the following year. The 2024/25 tax year runs from 6 April 2024 to 5 April 2025. If you export data covering 1 January 2024 to 31 December 2024, you will include transactions from January to April 2024 that belong to the previous tax year, and exclude transactions from April to December 2024 that belong to the current one.
Tax software such as Koinly and Recap can handle this if configured correctly — they allow you to set the UK tax year dates — but only if the underlying data you import covers the right period. The safest approach is to export your full transaction history from each exchange and let the tax software apply the correct date filtering on its end. This also avoids the problem of having to re-export if you realise you have missed a period.
On Coinbase, use a custom date range set to 6 April to 5 April. On Kraken, the export function also supports custom date ranges — set both the start and end date precisely rather than using any preset options.
HMRC's crypto-specific Capital Gains Tax guidance is among the most detailed in any jurisdiction — but the manual calculations required are complex enough that errors in DIY tax returns are common, particularly around pool averaging.
Mistake 2
Exporting only trades from Kraken — and missing deposits, withdrawals, and staking
Kraken's export system has two distinct export types: a Trades export and a Ledger export. They are not the same and they are not interchangeable. This catches a significant number of UK users who export one but not the other.
The Trades export covers spot trade executions — buy and sell orders. It does not include deposits, withdrawals, staking rewards, or fee records in the same format. The Ledger export covers all account movements: deposits, withdrawals, trades, fees, staking rewards, and transfers. For comprehensive HMRC reporting, you need both.
If you import only the Trades export into tax software, you will be missing staking income (which HMRC treats as taxable at the point of receipt), any deposits that established your cost basis for older holdings, and withdrawal records that are needed to track where assets went after leaving the exchange. The result is a set of records that looks complete but has significant gaps that affect the accuracy of every calculation that follows.
The process on Kraken Pro is to go to History, then export a Ledger report and a Trades report separately, using the same date range for both, and import both files into your tax software. Most major platforms including Koinly, Recap, and CoinTracking will accept both file types and merge them into a single transaction view.
Mistake 3
Wallet transfers classified as disposals — creating phantom capital gains
Moving cryptocurrency from an exchange account to a personal wallet — for example from Coinbase to a Ledger hardware wallet — is not a disposal for UK tax purposes. It is a transfer between your own accounts. No asset has been sold, exchanged, or given away. No Capital Gains Tax event has occurred.
The problem is that tax software cannot always tell the difference between a withdrawal from an exchange and a sale. When you withdraw Bitcoin from Coinbase to a personal wallet, the Coinbase export records it as a debit from your exchange account. If the tax software does not recognise the destination address as belonging to you, it may treat the withdrawal as a disposal — meaning it calculates a gain or loss on the full value at the point of withdrawal, as though you had sold the Bitcoin.
This produces what is sometimes called a phantom gain — a taxable event that did not actually occur. Left uncorrected, it will inflate your declared gains significantly, potentially by the full value of every self-custody transfer you have ever made.
The fix is to review your imported transactions in the tax software before accepting any calculations, and to manually tag wallet-to-wallet transfers as transfers rather than sales. Most platforms have a specific transaction type for this. If you regularly move assets between a Coinbase or Kraken account and a hardware wallet such as a Ledger or Trezor, connecting your wallet addresses to the tax software so it can identify your own addresses automatically is worth the setup time.
Mistake 4
Only exporting recent years — and breaking cost basis calculations for older holdings
HMRC uses a specific method called share pooling to calculate the cost basis of cryptocurrency holdings. Under share pooling, all purchases of the same asset are treated as a single pool with a single average cost per unit. When you sell, the gain or loss is calculated against that average cost across the entire pool — not against the specific purchase that corresponds to the units sold.
This means that the cost basis for any asset you currently hold depends on every purchase you have ever made of that asset, going back to your first transaction. If you only import data from the last two years but you first bought Bitcoin in 2020, your tax software does not have the 2020 purchase data and cannot correctly calculate your cost pool. It will either show an incorrect average cost or flag an error.
The practical implication is that you should always import your full transaction history when setting up a tax software account, not just the current tax year. Both Coinbase and Kraken allow you to export the complete history of an account back to the date it was opened. If your account predates the exchange's current export interface, you may need to request older data via their support team.
If you have used multiple exchanges over the years, the same applies across all of them. A Kraken purchase from 2019 and a Coinbase purchase from 2022 of the same asset both contribute to the same HMRC cost pool. Tax software can consolidate records from multiple exchanges, but only if all the data has been imported.
Mistake 5
Missing staking rewards and referral bonuses — which HMRC treats as income, not gains
Crypto received through staking, referral bonuses, airdrops, or promotional rewards is treated by HMRC as miscellaneous income at the point of receipt — not as a capital gain. This means it is taxable at Income Tax rates based on the GBP value of the crypto received on the day it was credited to your account.
This distinction matters because it changes both the rate at which the income is taxed and where it needs to appear in a Self Assessment return. Income from staking goes in the miscellaneous income section, not the Capital Gains section. When the asset is later sold, the cost basis for that asset is its GBP value at the time it was received as income — not zero.
Staking rewards appear in Kraken's Ledger export as staking entries. On Coinbase, they typically appear in the transaction history as rewards. Both should be imported into tax software and classified correctly. If they are missing from your export — for example because you exported Trades only from Kraken — they will not appear at all, leaving your income declaration incomplete.
The annual Income Tax-free threshold for miscellaneous income is separate from the Capital Gains allowance. If your total staking and reward income for the year is below the trading allowance of £1,000, it may not be taxable — but it still needs to be tracked and assessed.
Mistake 6
Assuming the tax software calculation is correct without reviewing it
Tax software automates a significant amount of work, but it is only as accurate as the data it receives. Importing a set of records and accepting the gain figure it produces without reviewing the underlying transactions is a common mistake — and one that CARF makes riskier than it used to be.
Before accepting any calculation, it is worth reviewing the transaction list for obvious errors. Check that wallet transfers are classified as transfers rather than disposals. Check that staking rewards are classified as income. Check that any exchange-to-exchange transfers — for example, withdrawing from Coinbase and depositing to Kraken — are not being treated as a sale on one side and a new purchase on the other with no connection between them.
Most reputable tax platforms flag transactions that require manual review. These flags are worth working through rather than dismissing. A single misclassified transfer can produce a significantly incorrect gain figure that then flows through to the Self Assessment return.
If in doubt about a specific transaction type or classification, HMRC's cryptoassets manual is publicly available on GOV.UK and covers most common scenarios including airdrops, forks, DeFi activity, and gifting. For complex situations involving multiple exchanges, large volumes, or unusual transaction types, consulting a tax professional with cryptocurrency experience is advisable.
Quick reference
Export checklist for UK traders
- Date range: Use 6 April to 5 April, not calendar year. Or export full history and let tax software filter.
- Kraken exports: Download both Ledger and Trades exports — not just one.
- Coinbase exports: Use the full transaction history report from the Reports section, not just recent activity.
- Wallet transfers: Review and manually classify exchange-to-wallet movements as transfers, not disposals.
- Full history: Import data back to your first ever transaction on each platform — not just recent years.
- Staking and rewards: Confirm these appear in your import and are classified as income, not gains.
- Multiple exchanges: Import from every platform you have used, including any no longer active.
- Review before filing: Check for flagged transactions before accepting any tax calculation.
Market impact snapshot
The growth of CARF data-sharing means that HMRC will increasingly be able to cross-reference self-assessed crypto gains against exchange-reported data from 2026 onwards.
Further reading
CARF and UK regulatory context
For more on how HMRC's new reporting framework affects UK crypto holders, and the broader UK regulatory picture, the following articles provide additional factual context.