Koinly vs ChainTax

Often classified as a sale — creates phantom capital gain on tokens deposited into the pool.

Classified as cost basis change — deposited tokens exit S104 pool, LP token enters. No taxable event.

May be classified as a disposal of ETH and acquisition of new ETH — creates a taxable event where none exists.

Classified as non-taxable transfer. Cost basis carries across chains automatically.

Usually correct for the initial stake, but rebase rewards are hard to detect from transaction history alone.

Initial stake correctly classified as capital gain — ETH→stETH is a token swap (disposal of ETH, acquisition of stETH) under HMRC guidance (CRYPTO40100), not a simple deposit. Rebase detection is a known limitation for both tools.

Generally correct for simple deposit/withdraw cycles.

Classified as non-taxable transfer at high confidence. aToken interest is a known limitation for both tools.

Supports Section 104 as an option alongside FIFO, LIFO, and others. UK users must select the correct method.

Section 104 is the only method — it's what HMRC requires. No risk of selecting the wrong one.

Implemented, but the interaction with B&B matching and S104 can produce different results than HMRC guidance.

Applied first in strict HMRC priority order: same-day, then 30-day B&B, then S104 pool. Working shown for each.

Does not compute Box 51. Users must manually split disposals by the 30 October 2024 boundary and calculate the blended rate.

Automatically splits disposals at the 30 October 2024 boundary. Box 51 adjustment computed and included in the SA108 report.

Supported — carries losses to offset future gains.

Supported — losses reduce net gain to the annual exempt amount only, not below, matching HMRC rules.

Koinly supports Section 104 but requires you to configure UK mode. Default cost basis method selection errors — many UK users file with FIFO or LIFO by mistake because the default differs by region.

Section 104 is the only method — matches what HMRC requires automatically. No region setting, no chance of wrong-method filing.

Koinly pools across exchanges — handled correctly when both are imported.

Same pool behaviour. Plus every disposal shows which source exchange fed the pool, and the per-disposal Section 104 snapshot before and after.

Koinly will update for CARF-format reports when HMRC publishes the schema. No special reconciliation view planned.

ChainTax is designing a CARF-matched view that highlights discrepancies between what HMRC received and what you are filing. Roadmap item for 2027 filing season.

Koinly does not auto-compute Box 51. Whether you are on Coinbase, DeFi, or both, you manually split disposals at the 30 October 2024 boundary and calculate the blended rate.

Auto-computed regardless of exchange/DeFi mix. Box 51 is on the PDF report ready to transcribe.

Shows gain/loss per transaction. No detail on which matching rule was applied or how the cost basis was derived.

Every disposal shows: matching rule (same-day, B&B, or S104), the pool snapshot before and after, the price source, and a confidence rating.

Uses market data but does not expose which source was used per transaction.

Every event shows its price source (DefiLlama, CoinGecko, or manual) and whether the price is high, medium, or low confidence.

The accountant receives a report with final numbers. Verifying the methodology requires trusting the tool.

The accountant can trace every disposal from raw transaction to final gain — matching rule, S104 pool state, price source. Nothing is a black box.