Reconciling exchange exports and wallets can eat days and trigger HMRC queries. Small firms risk incorrect pooling, missed same‑day rules and disputes.
A reusable pack reduces time, limits disclosure risk and standardises billing. It lets accountants deliver HMRC-safe outputs without deep crypto expertise.
Resumen del proceso
Prepare a professional Bitcoin CGT client pack and attach it to the client's Self Assessment within a scoped engagement. The pack includes a cleaned CSV, a PDF worked report and exchange-rate evidence.
It also includes an advisory note for the client and HMRC.
- Collect raw exports and KYC documents.
- Normalise and deduplicate transactions.
- Identify and exclude internal transfers.
- Apply same‑day, 30‑day and Section 104 pooling.
- Calculate per‑disposal gains/losses and aggregate the tax year totals.
- Produce CSV and PDF; deliver with engagement letter and invoice.
Short, repeatable packs speed delivery.
Step 1: intake and scoping
The intake captures required exports, identity evidence and engagement scope. The intake defines deliverables, fees and retention rules before any analysis starts.
Data request checklist
Provide a clear list of required files: exchange CSVs, wallet exports, staking receipts and a short statement of activity. The request must specify date ranges and preferred formats.
Scoping hours and pricing
Estimate hours by transaction complexity and volume. Typical ranges: 2–4 hours for holders under 200 transactions, 6–20 hours for active traders or DeFi users with 200–5,000 transactions.
Engagement letter essentials
Include tax treatment caveats for trading versus investing and a data security clause. The letter must state that the client confirms residency and supplies truthful records.
A clear engagement reduces scope disputes.
Step 2: required templates and SOPs
The pack must contain explicit templates and a short SOP so the firm applies the same process every time. A reproducible SOP cuts errors and speeds delivery.
CSV template (copyable):
utc_datetime,txid,tx_type,asset,quantity,gbp_value,fee_gbp,from_address,to_address,exchange,rate_source,original_currency
2023-03-15T14:05:00Z,txid123,disposal,BTC,0.1500,3600.00,10.00,addrFrom,addrTo,Coinbase,Coinbase-API-2023-03-15,USD
- Client details and tax year.
- Executive summary: total disposals, total gains/losses, AEA applied.
- Per‑disposal worked calculations with pooling and rule references.
- Exchange rate evidence index.
- Notes on assumptions and limitations.
Onboarding and email templates
Provide three short email templates: data request, fee estimate, and report delivery. The templates must include secure transfer instructions and a request for confirmation of residency.
Email: data request (copyable)
Subject: Crypto data required for your tax year [YYYY]
Dear [Client],
Please provide your exchange CSVs, wallet exports and any staking/airdrop records for the tax year [YYYY]. Send via the firm portal or an encrypted ZIP (password in a separate message).
Regards,
[Accountant]
Standard operating procedure
SOP step list: ingest → normalise → detect transfers → apply rules → calculate → review → deliver. Each step has an owner, a time estimate and acceptance criteria.
SOP excerpt (copyable)
- Ingest raw files and store in secure folder.
- Normalise to standard CSV template.
- Run automated transfer detection and flag likely internal transfers for manual review.
- Apply same‑day and 30‑day matching, then Section 104 pooling.
- Produce per‑disposal calculations; attach rate evidence.
- Peer review and generate PDF for client.
A short SOP improves repeatability.
Step 3: normalisation and cleansing
Normalisation converts diverse exchange exports into the standard CSV fields. Cleansing removes duplicates and marks internal transfers so they do not create artificial disposals.
Import rules and file handling
Ingest files into a secure workspace and convert timestamps to UTC. Record file provenance and checksum for each import.
Detecting internal transfers
Treat transfers between wallets or exchanges under common control as non‑disposals. The most frequent error at this stage is recording internal transfers as disposals and inflating gains.
Deduplication and reconciliation
Use txid or blockchain link as the primary dedupe key. If a txid is missing, match by timestamp, amount and counterpart to avoid false duplicates.
Keep a clear audit trail for each import.
Step 4: applying same‑day, 30‑day and pooling rules
Apply the same‑day rule first. Apply the 30‑day rule next and then Section 104 pooling. This order matches HMRC practice and changes per‑disposal cost bases materially.
Same‑day rule
Match acquisitions and disposals on the same UTC day against each other for cost basis. This can reduce taxable gain compared with FIFO in many cases.
30‑day rule
For acquisitions within 30 days after a disposal, match the disposal to the acquisition in that window next. This rule prevents quick sell‑buy sequences from creating artificial pooling benefits.
Section 104 pooling
Place remaining acquisitions into the Section 104 pool and apply average cost per asset for later disposals. This is the standard CGT mechanism for fungible assets such as Bitcoin.
When the same‑day and 30‑day matches are exhausted, the accountant calculates an average cost under Section 104 pooling. This applies to the remaining holdings. The accountant documents pool additions, disposals and resulting average cost per unit with timestamps and rate sources.
Step 5: calculations and worked examples
Produce per‑disposal calculations showing date, quantity, proceeds, cost base, fees, and gain or loss. The worked examples should show how different rules change the outcome.
Worked example: simple disposal
A sale of 0.5 BTC on 2023‑06‑10 for £10,000 with a £50 fee. Cost base from pool equals £6,000. The gain equals £3,950.
Worked example: same‑day vs pooling
An investor sells 0.2 BTC and buys 0.2 BTC the same day. Applying the same‑day rule matches the trades and sets cost base from the matched acquisition. The gain can be zero or much smaller than FIFO would show.
Comparative numeric table
| Scenario |
FIFO gain (£) |
Same‑day/30‑day gain (£) |
| Sell 0.2 BTC, buy 0.2 BTC same day |
1,200.00 |
100.00 |
| Sell 0.5 BTC, no nearby purchases |
3,950.00 |
3,950.00 |
This table clarifies rule impacts.
Step 6: exchange rates and evidence
Record the rate source, pair and timestamp for every valuation. HMRC expects evidence showing how GBP values were calculated.
Preferred rate sources
Use exchange APIs or reputable rate providers and store the raw export. Record the provider name and retrieval timestamp beside each disposal row.
Include rate_source and original_currency columns and a link or reference to the raw export in the supporting folder. This practice prevents queries over valuation differences.
Example rate documentation
Example CSV fields: rate_source=Coinbase-API-2023-03-15, original_currency=USD, conversion_method=timestamped‑rate.
Record rate evidence for every conversion.
Step 7: producing the final report and delivery
Generate a concise PDF that shows totals and provides full per‑disposal calculations in an appendix. The PDF should be suitable for attachment to a Self Assessment return and for HMRC review.
PDF contents and naming
File names should include client surname, tax year and pack type. Include a signature line for the preparer and the date of issue.
Delivery checklist
Deliver the PDF and CSV together and include the SOP summary and the engagement invoice. Ensure the transfer uses an encrypted channel and document the transfer log.
Billing and time records
Attach time records and a brief breakdown of work phases to the invoice. This helps justify fees if HMRC queries billing time on an enquiry.
Keep transfer logs linked to the client pack.
Software integrations and mapping matrix
Select a reconciliation engine that supports the required CSV fields and provides rate evidence. The choice depends on connector coverage, audit reporting and GDPR controls.
| Tool |
Exchange connectors |
Proof of rate |
Audit report |
| Koinly |
Coinbase, Binance, Kraken and others |
Timestamped rates, source noted |
Detailed audit CSV and report |
| CoinLedger |
Wide exchange and wallet support |
Historical rates with source |
Audit summary available |
| CoinTracking |
Many CSV import formats |
Rate source field supported |
Exportable calculation logs |
Connector best practice
Capture full trade history, withdrawal records and fee details from each exchange. Where APIs are unavailable, request CSV exports and document missing fields for manual mapping.
Manual mapping example
Map raw Binance columns to the standard header and compute GBP using a timestamped rate. Store the mapping logic alongside the processed CSV for auditability.
A practical integration paragraph shows the end‑to‑end flow. Import raw exchange CSVs into the chosen tax tool and produce a canonical export named realised_disposals.csv with the standard header (utc_datetime, txid, tx_type, asset, quantity, gbp_value, fee_gbp, etc.).
Export that file and import it into the firm ledger as a single journal that posts net disposal proceeds to a temporary CGT clearing account. Post corresponding acquisition cost and fees to cost buckets.
Example mapping: realised_disposals.csv 'gbp_value' → Xero Credit to 'Realised Proceeds', 'cost_base' → Xero Debit to 'Cost of Disposal', 'gain' → Xero Credit to 'Unrealised Gains/CGT Reserve'; attach the CSV as a note to the journal entry.
Reconcile the CGT clearing account to bank receipts and the tax report totals. Include a short peer‑review checklist that verifies CSV headers, checksum, and one reconciled journal entry per major disposal batch.
Errors that ruin a report
Treating internal transfers as disposals frequently creates false gains. Omitting fees from the cost base also inflates taxable gains.
Common pitfalls
Using a single undated exchange rate across a tax year invites HMRC queries. Misclassifying income events as capital disposals can produce incorrect tax calculations.
Audit triggers and red flags
Large unexplained gains, inconsistent rates, and missing chain evidence commonly prompt HMRC enquiries under the Taxes Management Act 1970. Prepare a reconciliation pack to address likely audit questions.
Review red flags before delivery.
When this method does not apply
This CGT client‑pack workflow does not apply where the client qualifies as a trader and gains are taxed as income, where the client is non‑UK resident for the tax year, or where holdings sit entirely within tax‑exempt wrappers such as ISAs or qualifying pensions. In such cases use an income tax approach, non‑resident guidance, or pension/ISA reporting rules instead.
Privacy, security and retention
Store client exports in encrypted storage and use MFA for access. Firms must keep records for the period required under HMRC rules.
Secure transfer and pseudonymisation
Use SFTP or an encrypted client portal for file transfers. Pseudonymise wallet addresses in shared working copies when possible.
Retention and AML obligations
Retain tax records for at least six years in accordance with the Taxes Management Act 1970. Retain and dispose of AML and KYC records in line with the Money Laundering Regulations 2017.
State both requirements separately and record retention justification in the client pack metadata.
Forensic and edge cases
Complex events such as forks, airdrops and staking need separate assessment for income versus capital treatment. Chain tracing and timestamped evidence support positions taken.
Forks, airdrops and staking
Record receipt date and market value at receipt for airdrops and forks. This value often forms the acquisition cost for later CGT calculations.
Chain tracing and evidence
Include txid trails, explorer links and snapshots as part of the supporting folder. Chain evidence strengthens the position if HMRC opens an enquiry.
Trader vs investor indicators
Frequency of activity, organised operations and a profit‑making business model move a client toward trading classification. The tax consequence is income tax treatment and not CGT.
Anonymised case: a client moved 1,200 BTC transactions into a single spreadsheet without deduplication. After cleansing and correct pooling, the reported gain fell by 42%, avoiding an unnecessary enquiry.
Complex DeFi and non‑standard events need concrete numeric treatment rather than only general guidance.
- For a token swap, treat the market value of the token received at the time of the swap as the disposal proceeds of the token given: for example, swapping 10 ALT tokens for 0.5 BTC where 0.5 BTC equals £3,000 at the timestamp creates a disposal with proceeds £3,000
- If the acquisition cost of the 10 ALT was £500, the capital gain on that disposal is £2,500 before fees. For liquidity‑pool tokens, value the LP token at the market value of the underlying assets at the time of disposal or when the LP token was minted, and include impermanent loss adjustments where appropriate. Staking rewards and airdrops should be recorded at the timestamped market value when received and treated initially as income (if HMRC position applies) with that value forming the acquisition cost for later CGT
- Gas and protocol fees must be captured in GBP and allocated to the relevant disposal or acquisition leg
Workflow visual
Client pack workflow (input → deliver)
1. Collect exports
2. Normalise & dedupe
3. Detect transfers
4. Apply rules
5. Calculate gains
6. Produce CSV & PDF
Pricing bands and invoice templates
Price by complexity and risk. Provide fixed fees for simple holders and time‑based fees for complex traders or DeFi clients.
Pricing guidance
Suggested bands:
- simple holder £150–£350
- active trader £450–£1,500
- complex DeFi £1,200–£6,000 depending on transactions
These bands include report preparation but exclude lengthy HMRC enquiries.
Time breakdown example
A simple holder: 2–4 hours (data intake, cleanse, calculation, PDF). An active trader: 6–20 hours (reconciliation, manual mapping, peer review).
Invoice line items
- Data ingestion and mapping, hours at £XX/hr
- CGT calculations and report, fixed fee
- Delivery and secure transfer, nominal fee
Invoice template (copyable)
Invoice to: [Client]
Description: Bitcoin CGT client pack for tax year [YYYY]
Item: Data ingestion and reconciliation. X hours
Item: Report generation and review, fixed fee
Total: £[amount]
Payment terms: 30 days
Resources and authoritative references
HMRC provides guidance in the Cryptoassets Manual which explains treatment of disposals and pooling. The Money Laundering Regulations 2017 and the Taxes Management Act 1970 set record and AML requirements.
A useful GOV.UK reference: HM Revenue & Customs.
The ICAEW and ACCA have published practitioner notes which assist firms reviewing complex cases.
For practice: prepare a compact audit file containing raw exports, mapping logic, rate evidence and the final CSV/PDF.
To obtain a ready client pack and bespoke pricing schedule, prepare the engagement letter and request the pack through the firm's normal client channel.
Frequently asked questions
What must a bitcoin CGT report include?
A Bitcoin CGT report must include a disposals CSV, a PDF with per‑disposal calculations, documented exchange rates and a note on applied matching rules. The report must allow replication of the totals by an independent reviewer.
How long does it take to prepare a client pack?
A simple pack for holders usually takes 2–4 hours. Complex cases with DeFi, staking or thousands of transactions can take 6–20 hours.
Do fees count in the cost base?
Clarification: Fees paid at acquisition (purchase fees, broker commissions paid to acquire crypto) should be added to the acquisition cost and thus increase the cost base; fees incurred on disposal (exchange withdrawal fees or selling commissions) should be deducted from the disposal proceeds when calculating the chargeable gain. Fees paid in crypto must be converted to GBP at the timestamp of the fee payment.
