All services

Review and reconciliation of Koinly and Recap tax reports.

You have a Koinly, Recap or CoinTracking report but you are not sure it is UK-correct. The most common reason it might not be is the pooling method: UK individuals must use <a href="https://www.gov.uk/hmrc-internal-manuals/cryptoassets-manual/crypto22200">section 104 pooling at average cost</a> per token, not FIFO, LIFO or specific identification, which are the defaults in US-originated software and in many account setups. A report using the wrong method produces a plausible-looking number that is still wrong. The firm reviews your export, verifies the method settings, applies <a href="https://www.gov.uk/hmrc-internal-manuals/cryptoassets-manual/crypto22250">same-day and 30-day matching</a> where the tool has not, checks swap and transfer classifications, and produces a reconciled position you can file on or disclose from.

s104
The only UK-correct pooling method: average cost per token, not FIFO or specific identification
30 days
Bed-and-breakfast rule: acquisitions within 30 days of disposal override the s104 pool
Same day
Same-day matching must be applied before the 30-day rule and the pool, and is beyond stateless tools

The challenges clients face.

FIFO and specific identification are wrong for UK individuals

<a href="https://www.gov.uk/hmrc-internal-manuals/cryptoassets-manual/crypto22200">Section 104 pooling</a> requires that every acquisition of a token goes into a single pool, and the allowable cost on any disposal is the average cost of that pool at the time of disposal. FIFO matches the earliest coins first; specific identification lets you pick. Both produce a different, usually incorrect, allowable cost under UK rules. The error can run in either direction and compounds across a multi-year history.

The same-day and 30-day rules are beyond what a stateless report can reliably apply

Under <a href="https://www.gov.uk/hmrc-internal-manuals/cryptoassets-manual/crypto22250">HMRC's matching rules</a>, a disposal must first be matched against same-day acquisitions, then against acquisitions in the following 30 days, and only then against the s104 pool. These rules exist to prevent bed-and-breakfast loss harvesting. A report that does not apply them correctly overstates losses (or understates gains) in the periods where the rules bite, and is the biggest single source of DIY calculation error for active traders.

Wallet-to-wallet transfers are not disposals, but software often misclassifies them

Moving tokens between your own wallets is not a <a href="https://www.gov.uk/guidance/check-if-you-need-to-pay-tax-when-you-sell-cryptoassets">disposal</a>. Swapping one token for another, or sending tokens to another person, is. Software that cannot reliably distinguish your own wallets from external addresses will treat internal transfers as disposals and inflate the apparent gain. A reconciliation pass catches these misclassifications before they reach a filing.

DeFi deposits and LP entries may themselves be disposals, not just receipts

Under <a href="https://www.gov.uk/hmrc-internal-manuals/cryptoassets-manual/crypto61000">HMRC's current analysis</a>, many DeFi lending deposits and liquidity-pool entries involve a transfer of beneficial ownership and are therefore disposals of the deposited tokens. This is HMRC's current view, not settled law, but it is the most under-reported event class in DIY reports and one of the most important things a reconciliation review checks. A report that treats DeFi deposits as neutral transfers will understate the gain.

How we help.

Method verification and correction to UK s104 pooling

We review your export settings and recalculate any periods where the wrong pooling method was applied. Every token's pool is reconstructed at average cost, with acquisitions sequenced correctly. The corrected pool forms the allowable-cost baseline for every disposal in the reconciled report. Where software can be corrected at the settings level, we advise on that; where a manual override is needed, we apply it.

Same-day and 30-day matching applied manually where the tool has not

We identify every disposal that falls within a matching period (same-day acquisition, or acquisition in the following 30 days) and apply <a href="https://www.gov.uk/hmrc-internal-manuals/cryptoassets-manual/crypto22250">HMRC's ordering rules</a> manually. This is the one step no stateless tool can reliably do, and it is often the difference between a defensible position and one that will not survive an enquiry. The reconciled output states which disposals were matched and against which acquisitions.

Reconciled output ready for filing or disclosure

The reconciled report feeds directly into a <a href="/services/crypto-self-assessment">Self Assessment SA108 filing</a> or, where prior years are affected, into a <a href="/services/hmrc-disclosure">voluntary disclosure</a> through HMRC's cryptoasset service. We flag any remaining uncertainties (unresolved DeFi classification, unavailable records) with the methodology used so that the filing position is transparent and defensible.

Common questions

Is Koinly accurate for UK tax?
Koinly supports <a href="https://www.gov.uk/hmrc-internal-manuals/cryptoassets-manual/crypto22200">s104 pooling</a> as a setting, but the accuracy of the output depends entirely on whether the settings are correct, whether wallet addresses are properly classified as your own, and whether all exchanges and wallets are connected. The software cannot apply the <a href="https://www.gov.uk/hmrc-internal-manuals/cryptoassets-manual/crypto22250">same-day and 30-day matching rules</a> reliably. A UK accountant review catches the gaps the tool itself cannot flag.
What pooling method should my crypto tax report use in the UK?
<a href="https://www.gov.uk/hmrc-internal-manuals/cryptoassets-manual/crypto22200">Section 104 pooling at average cost</a>, per token. Each token has one pool; the allowable cost on any disposal is the average cost of all acquisitions into that pool to date. FIFO, LIFO and specific identification (common in US software and US-oriented account setups) are wrong for UK individuals.
Why does FIFO give the wrong UK answer?
FIFO matches the earliest coins first and uses the cost of those specific coins as the allowable cost. UK rules require the pool average, which is a different number once you have multiple purchases at different prices. In a rising market, FIFO typically understates the allowable cost (overstating the gain); in a falling market it overstates it. The direction of the error depends on the price history, not on the method being conservative or generous.
What are the same-day and 30-day rules and can software handle them?
Under <a href="https://www.gov.uk/hmrc-internal-manuals/cryptoassets-manual/crypto22250">HMRC's matching rules</a>, a disposal must be matched first against same-day acquisitions, then against acquisitions in the 30 days following the disposal, and only then against the s104 pool. These rules prevent loss harvesting by selling and immediately rebuying. Most stateless tools cannot apply them reliably because doing so requires knowing the full acquisition sequence across the matching windows, not just the disposal date.
My report shows a large gain from swaps I never cashed out. Is that right?
It can be. Every swap between tokens is a <a href="https://www.gov.uk/guidance/check-if-you-need-to-pay-tax-when-you-sell-cryptoassets">disposal at sterling market value</a> at the time of the swap. If you swapped into a token that subsequently fell, the gain on the swap is still real even though the replacement token is now worth less. However, if your own wallet transfers are being misclassified as swaps, those are not disposals and the report needs correcting.
Can you work from a Recap or CoinTracking export too?
Yes. The reconciliation process applies to any UK-destined crypto tax report, regardless of which tool generated the export. The checks are the same: pooling method, same-day and 30-day matching, transfer versus disposal classification, and DeFi event treatment.
Can you fix a report that was filed on the wrong method in a previous year?
If a prior return was filed using the wrong pooling method, the corrective route is usually a voluntary amendment or a disclosure through <a href="/services/hmrc-disclosure">HMRC's cryptoasset disclosure service</a>, depending on how long ago the year was and what the under-declaration looks like. We can reconstruct the correct position and advise on the appropriate route.

Speak to a crypto tax specialist.

Tell us about your situation and we will reply within 24 hours.