How many hours do accountants lose stitching together CSVs and API dumps from multiple exchanges and wallets? Practices face mismatched fields, missed on-chain transfers and weak audit trails. These issues inflate fees and raise the risk of HMRC enquiries. A concise, workflow-led process removes guesswork and protects client records.
Bitcoin Tax API & CSV Tools for Accountants enable a combined API-and-CSV workflow to extract trades from major exchanges. They normalise records into a standard CSV template, reconcile wallets and trades, and produce HMRC-ready reports. Implement scoped API keys, pagination handling and automated rate-limit retries. The approach saves accountants time, reduces errors and creates audit-proof evidence for UK capital gains reporting.
Summary of the process
The sequence below shows the end-to-end workflow an accounting practice applies for compliant crypto reporting. Follow these steps to move from raw export to HMRC-ready submission.
- Collect: gather scoped API access or raw CSVs and KYC proofs from the client.
- Ingest: pull data with pagination, or import CSVs; hash and log every raw source.
- Normalise: map all sources to a standard CSV with UTC timestamps and trade IDs.
- Reconcile: match exchange records to chain receipts and wallet exports.
- Report: produce HMRC-format CSVs, reconciliation certificate and supporting evidence.
A simple workflow reduces repeated fixes and saves time.
Why this workflow
A consistent process reduces manual adjustments and audit risk. HMRC expects traceable cost basis and disposal records.
What HMRC needs
The basic required items are timestamps (UTC), unique trade IDs, counterparty and exchange IDs and fee breakdowns for each disposal. See the HMRC cryptoassets guidance for source rules and record keeping.
Step 1: data ingestion
The ingestion phase secures raw evidence and establishes traceability. Firms either use scoped APIs or accept client CSV exports.
API first approach
Use read-only, scope-limited API keys where available. Request keys that exclude withdrawal permissions and log the key fingerprint and expiry.
CSV fallbacks
When APIs are unavailable, request raw CSVs and proof of export time. Hash each file (SHA-256) and record the hash in the import job.
Ingestion practical notes
The most frequent error at this point is importing multiple exchange CSVs without deduplicating internal transfers. This causes double-counted disposals and inflated gains.
Use read-only API keys where possible and require a screenshot of API creation showing scopes and timestamp. Store API keys encrypted and enforce a risk-based rotation policy: rotate high-use or high-risk keys quarterly, revoke unused keys immediately and rotate lower-risk keys at least annually. Document each rotation event in the audit log and revoke credentials if misuse or unexpected activity is detected.
Accountant-led multi-client workflow:
- For accounting practices the ingestion and reconciliation pipeline must be designed around per-client isolation and clear delegation. Start by capturing client consent and a short consent manifest that lists which exchange API keys or CSV exports are authorised, the permitted scopes (read-only, trade history, wallets) and an expiry date. Use role-based access controls in the practice platform so junior operators can queue imports while senior staff approve reconciliations.
- Maintain per-client cursors so incremental imports resume without reprocessing history.
- Store an immutable audit trail that records operator ID, timestamps and the consent manifest.
Implement a delegation pattern where clients either provide scoped API keys or grant OAuth-style access that can be revoked. Default to a trial import for a single tax year before running bulk jobs. This workflow aligns operationally with HMRC crypto guidance and supports wallet reconciliation and Bitcoin reporting across multiple clients while reducing cross-client data exposure.
Step 2: normalisation & mapping
Normalisation reduces schema differences and ensures consistent cost-basis calculation. Produce a canonical CSV with fixed columns per client.
Standard CSV template
The canonical file must include these columns: utc_timestamp, txn_id, source_exchange_id, wallet_address, txn_type, asset, amount_asset, asset_price_fiat, fiat_currency, fiat_value_total, fee_asset, fee_fiat, counterparty_id, receiving_address, note, import_hash.
Example CSV header and one sample row:
utc_timestamp,txn_id,source_exchange_id,wallet_address,txn_type,asset,amount_asset,asset_price_fiat,fiat_currency,fiat_value_total,fee_asset,fee_fiat,counterparty_id,receiving_address,note,import_hash
2021-08-09T14:23:00Z,cb12345,coinbase,1A1zP1...,trade,BTC,0.005,40000,GBP,200,0.0001,4,coinbase_exchange,1BvBMSE...,spot trade,sha256:abc123...
Accounting mappers
Map fiat_value_total to ledger entries and record fees on separate nominal codes. Use contacts or tracking categories for counterparty_id in Xero and QuickBooks.
Practical CSV mappings to Sage, Xero and QuickBooks:
- Once you have a canonical crypto CSV, provide explicit column-to-ledger mappings so bookkeeping is repeatable. Example mappings: map utc_timestamp to transaction date (UTC) in the ledger, txn_id to the transaction reference field, fiat_value_total to the disposal/proceeds nominal code (e.g. Sage nominal 7000 or a client-specific sale code), fee_fiat to a fees nominal code (e.g. 7080) with fee_asset written to the description, and counterparty_id to the contact name or tracking category in Xero/QuickBooks. For Sage MTD compatibility ensure the CSV date format is ISO 8601 and currency codes are GBP.
- For Xero use the contact and tracking category fields to preserve exchange identities.
- For QuickBooks map each disposal line to a product/service called ‘Crypto disposal’ and record fee lines separately.
Including these crypto CSV templates and specific ledger mappings reduces manual journal edits. It improves data normalisation and ensures the reconciliation certificate ties each normalised row back to a ledger entry.
Step 3: reconciliation & audit evidence
Reconciliation proves provenance and resolves mismatches between chain, exchange and wallet records. Create a formal reconciliation certificate for each client.
Chain matching
Match withdrawals and deposits by transaction hash, amount and timestamp tolerance. Use provenance records from Chainalysis or equivalent when value or origin is uncertain.
Duplicate detection
Detect internal transfers by identical asset, similar timestamp and zero net economic change. Mark these as internal and exclude them from disposal counts.
Reconciliation certificate
Provide a one-page certificate summarising sources, rows imported, normalisation rules, chosen cost-basis method and CSV hash. Include links or snapshots of chain proofs and exchange confirmations.
Reconciliation certificate
Client: [Client name]
Period: [Start] to [End]
Sources: [Coinbase.csv], [Binance API pull]
Imported rows: 4,321
Normalisation: canonical_v1.2 (FIFO applied)
CSV hash: sha256:...
Signed by: [Operator ID]
The evidence shows the core items tax examiners require: methods, hashes and source links.
Retention periods depend on filing type and taxpayer circumstances. As a conservative default many firms retain tax and reconciliation evidence for at least six years from the end of the relevant tax year. Confirm the exact retention requirement for specific clients, for example businesses, trustees or shortened regimes. Record that retention decision in the reconciliation certificate.
Always link each normalised row to its raw source and provenance record.
API patterns and rate limit handling
Robust API consumption prevents data loss and respects provider rules. Use cursor pagination and exponential backoff for reliability.
Use cursor-based fetches and persist the last cursor per client. Continue fetching until the cursor shows no further pages.
Python
cursor = saved_cursor
while cursor:
resp = GET('/transactions', params={'cursor':cursor,'limit':500})
process(resp.data)
cursor = resp.next_cursor
save_cursor(client_id, cursor)
Rate limit handling
Use exponential backoff with jitter and honour Retry-After headers. On HTTP 429 inspect Retry-After, sleep that duration, then retry. Otherwise back off as min(2**attempt * base, max) with random jitter. Log every 429 response with timestamp and attempted retry count.
Security of API pulls
Hash raw API payloads and store them with metadata. Maintain an append-only log of imports including operator ID, client consent reference and API scope.
Concrete API examples and robust retry patterns: Real integration code helps avoid lost records. For example, Binance REST v3 requires a querystring signature using HMAC SHA256. Build the query string with timestamp. Compute signature = HMAC_SHA256(secret, query_string).hexdigest(). Then send GET /api/v3/myTrades?symbol=BTCUSDT×tamp=... With header X-MBX-APIKEY: your_key. For Coinbase Pro include CB-ACCESS-KEY, CB-ACCESS-SIGN and CB-ACCESS-TIMESTAMP.
The sign value is a base64 HMAC SHA256 of timestamp + method + requestPath + body. For pagination handling persist the last-returned cursor or timestamp per client and loop until the provider returns no next page.
See "Rate limit handling" above for retry strategy. Log every 429 and persist retry counts so long-running imports can resume safely. These concrete exchange API patterns—API keys, pagination handling and rate-limit retries—are essential to ensure full history capture without violating provider limits.
Edge cases and tax treatments
Complex events need explicit rules and written assumptions. Document every estimation and its source.
Staking and rewards
Treat staking rewards as taxable income at receipt. Record fair market value in GBP at receipt and use that value as cost basis for later disposals.
Airdrops, forks and OTC
Record airdrops and forks at the point of receipt with a market valuation. For OTC deals, obtain trade confirmations and counterparty identification and retain proof.
Hard-to-trace flows
When provenance is missing, apply a reasonable, documented method for valuation. Keep chain analysis screenshots and provider confirmations as supporting evidence.
An anonymous case: a high-net-worth client sold an OTC lot without counterparty details. The absence of trade confirmations forced a conservative valuation and a manual disclosure to HMRC. This underlines why OTC records must enter the workflow at ingestion.
Errors that ruin the result
Certain operational mistakes create audit exposure and rework. Identify and remove these from firm processes.
Common importer mistakes
Importing exchange CSVs without deduplicating internal transfers causes double-counted gains. Always group transfers and flag internal moves.
Security mistakes
Sharing full-access API keys or keeping keys unencrypted exposes firms to data breaches and regulatory scrutiny. Use KMS and rotate keys quarterly.
Documentation failures
Failing to record the normalisation method leaves calculations undefended. Record the chosen method per tax year in the reconciliation certificate.
When not to apply this method
The workflow is unnecessary when a custodian delivers a certified HMRC-ready report. It also does not apply where a client only transfers assets between personal wallets without disposals.
Many small investors with zero disposals or gains below reporting thresholds do not need full normalisation. For multi-client firms, avoid running full import jobs for clients who have no taxable events.
Keep a checklist to decide: if the provider supplies a verifiable HMRC-formatted report, store it and perform a spot-check reconciliation only.
For firms with high-volume active clients, scale by applying incremental imports and per-client cursors to avoid reprocessing full histories.
Request scoped API access and run a trial import for one client within three business days to validate mappings and permissions before batch processing.
Frequently asked questions
How do accountants export HMRC‑ready CSVs?
Use a canonical CSV template that includes UTC timestamps, unique trade IDs and fee breakdowns. Map source fields to the canonical columns and include hashes and raw source references.
Start with a single-client trial to validate mappings and address edge cases. Confirm the chosen cost-basis method and record it in the reconciliation certificate.
Can Binance CSVs be used directly for UK CGT?
Yes, but only after normalisation and verification. Binance CSVs often use local timestamps and inconsistent fee fields. Convert timestamps to UTC and verify cost basis.
Keep the raw Binance export and the normalised file. Log the mapping rules and include snapshots when preparing the HMRC submission.
How to reconcile chain transactions to exchange
Match by txid, amount and timestamp within a tolerance window. Use chain analysis where origin or linkage is unclear, and attach screenshots as proof.
Flag fuzzy matches for manual review. Record the matching tolerance and the tool used in the reconciliation certificate.
What security steps are essential when sharing
Require read-only, scope-limited API keys and a screenshot of creation showing scope and timestamp. Store keys encrypted and rotate them every three months.
Do not accept passwords or full-access keys. Log key fingerprints and the operator who requested access.
How long must records be retained for HMRC?
Keep records for at least six years from the end of the relevant tax year. This retention period satisfies HMRC audit expectations and supports inquiries.
Store hashes, raw exports and reconciliation certificates together to present a coherent audit trail.
Are there HMRC risks with OTC trades?
Yes, OTC trades carry provenance risks and require counterparty evidence. Obtain trade confirmations, invoices and chain proofs and record them with the normalised CSV.
If counterparty information is missing, document valuation attempts and provide a defensible methodology in the reconciliation certificate.
Final checklist and next steps
Every implementation must produce a repeatable, auditable output. The checklist below is the minimum firms should enforce before filing.
- Obtain client consent and scoped API keys or CSV exports.
- Hash and log raw sources; store payloads encrypted.
- Normalise to the canonical CSV and map to accounting nominal codes.
- Deduplicate internal transfers and reconcile chain txids.
- Record the cost-basis method and produce a reconciliation certificate.
| Tool |
API |
CSV import |
HMRC templates |
Multi-client features |
| Koinly |
Yes |
Yes |
Yes |
Team accounts |
| CoinLedger (CryptoTrader.Tax) |
Yes |
Yes |
Yes |
Accountant plans |
| CoinTracker |
Limited |
Yes |
Exports only |
Shared access |
| Accointing |
Yes |
Yes |
Templates |
Client folders |
| TaxCalc |
No |
Yes |
UK-focused |
Practice mode |
1. Collect: scoped API keys or raw CSV, KYC proof, consent
2. Ingest: paginated API pulls or CSV import; hash sources
3. Normalise: canonical CSV with UTC timestamps and trade IDs
4. Reconcile: chain matching, deduplication and certificate
5. Report: HMRC-ready CSV and attachments
When a client only moves coins between private wallets and no disposals occur, the full workflow is unnecessary. Also skip full normalisation when a regulated custodian supplies a verified HMRC-ready report. In those cases preserve source files and run a spot-check reconciliation only.
The legal and regulatory context includes the Money Laundering Regulations 2017, the Data Protection Act 2018 and HMRC guidance published in recent years. Firms must balance AML checks, data protection and tax reporting.
Which cost basis method should firms use?
HMRC requires a specific matching hierarchy for disposals: same-day matches first, then 30-day bed-and-breakfast rules, and finally Section 104 pooling for remaining holdings. Firms should implement that matching order by default, document any client-requested elections (for example HIFO) and record the chosen and applied method in the reconciliation certificate alongside worked examples for the tax year in question.
