Crypto data sources for CPAs: What’s trustworthy and what isn’t

TLDR

• Clients will send a mix of high-quality systems-of-record data (exchange APIs/CSVs, wallet addresses) and low-quality context-only materials (screenshots, PDFs, spreadsheets). Treat them differently.
• Start with exchange transaction history and on-chain wallet data to build a complete activity record across venues—especially when assets move between platforms or into self-custody.
• Use a crypto subledger (e.g., CoinTracker) to normalize and reconcile transactions across exchanges and wallets, then validate completeness by reviewing unmatched inflows/outflows and reconciling year-end holdings.
• Form 1099-DA can help, but it won’t eliminate data gaps. Accurate reporting still depends on complete source identification, consistent ingestion, and documented reconciliation across all venues.

Crypto data is messy, and not all sources are equal

In traditional tax work, practitioners are accustomed to standardized third-party reporting such as Forms 1099, broker statements, and Schedule K-1s. In crypto, by contrast, “the file the client sent” can range from a complete, system-generated API export to a manually maintained spreadsheet with gaps, errors, or estimates.

In practice, many firms accept whatever digital asset files a client uploads to the portal and assume that all CSVs are functionally equivalent. They are not. Different data sources vary widely in completeness, structure, and reliability, and those differences directly affect how confidently transactions can be classified, reconciled, and reported.

This is not about auditing clients or independently verifying every transaction. Tax preparers are generally entitled to rely on information provided by clients unless it appears incorrect, inconsistent, or incomplete. However, when crypto data contains obvious gaps, unexplained transfers, or internally inconsistent activity, relying on low-quality inputs can lead to misreported gains, missed income, or unresolved basis questions that surface later.

The introduction of Form 1099-DA does not eliminate these issues. Even with broker reporting, large portions of a client’s crypto activity may still fall outside standardized forms, including activity on non-U.S. exchanges, transfers between platforms, self-custody wallets, and decentralized protocols. These gaps exist regardless of whether an asset is ultimately treated as covered or noncovered.

For that reason, firms benefit from viewing crypto data through a practical hierarchy of reliability. Some sources provide objective, third-party records that support accurate reconciliation. Others are useful only as supplemental context. This guide outlines a framework for evaluating the data clients provide, understanding its limitations, and determining how much reliance is reasonable in preparing an accurate return.

The data hierarchy: From most to least reliable

Not all crypto data sources provide the same level of completeness or traceability. When preparing a return, firms should prioritize data that originates directly from systems of record, such as exchange transaction ledgers or blockchain activity, over secondary summaries or reconstructed files. These sources tend to include the timestamps, identifiers, and transaction-level detail needed to reconcile activity across platforms.

This hierarchy becomes most relevant when data is incomplete or fragmented, such as when assets move between exchanges, into self-custody, or through decentralized protocols. In those situations, higher-quality primary data makes it easier to identify missing activity, link related transactions, and resolve gaps in acquisition history. The sections below outline how different crypto data sources typically compare in reliability and how firms can use them effectively during reconciliation.

Source type 1: Direct exchange / broker data

This is the foundation of crypto tax reporting. It includes native CSV exports or API connections from both U.S. custodial exchanges and non-U.S. platforms.

U.S. custodial exchanges (Issue Form 1099-DA)

Examples: Coinbase, Kraken, Gemini, Robinhood, Binance.US

What you typically receive:

• Form 1099-DA (beginning with 2025 transactions, issued in early 2026)
• Full transaction history via CSV export or API
• Disposition details (dates, quantities, proceeds)
• Acquisition information where available, depending on how and where the asset was acquired and held

Note: Even when acquisition information appears on broker statements, practitioners may still need to reconcile or adjust basis based on external activity, transfers, or incomplete history.

Non-U.S. exchanges (Do NOT issue 1099-DA)

Examples: KuCoin, Binance.com, Bybit, Bitfinex

Critical distinction: Non-U.S. exchanges are not subject to U.S. information reporting requirements and will not issue Form 1099-DA. CSV exports or API data are therefore the only way to obtain transaction-level detail from these platforms.

Strengths of exchange data

• Structured & Standardized: Transaction-level detail typically includes timestamps, assets, quantities, fees, and internal transaction IDs
• Third-party source: Data reflects activity recorded by the custodian that executed or facilitated the transaction
• Anchor point for reconciliation: Exchange data often provides the clearest record of executions, deposits, withdrawals, and internal movements
• Acquisition visibility (where available): Exchange records frequently contain purchase dates and prices for assets acquired directly on the platform

Limitations to be aware of

• Incomplete historical coverage: APIs and exports may be limited by lookback periods or account history constraints, leaving gaps for long-term holders
• No cross-platform awareness: Exchanges cannot see activity that occurs after assets are transferred out, including movement to other exchanges or self-custody
• Not tax-native data: Exchange exports are transaction records, not tax determinations. Classification, sourcing, and gain or income treatment must be determined during reconciliation
• Transfer-driven gaps: When assets are deposited from external wallets or other platforms, acquisition details are often missing and must be established from other records

Firm guidance

Prefer API connections whenever available. APIs generally provide the most complete and consistent transaction history across trades, transfers, rewards, and internal movements. Compared to CSV exports, APIs reduce the likelihood of incomplete coverage caused by file limits, activity-type separation, or date-range constraints.

Non-U.S. exchanges require direct data collection. Because non-U.S. platforms do not issue Form 1099-DA, transaction history must be obtained directly from the exchange via API or native CSV exports. Without this data, activity on these platforms will not be reflected in the client’s tax file.

Use exchange data to establish acquisition history and reconcile transfers. Exchange records are often the primary source for purchase dates, prices, and execution details, particularly when assets are later moved between platforms or into self-custody.

Request historical data beyond the current tax year. Dispositions reported in the current year frequently depend on acquisition activity from prior years. Reviewing earlier exchange history also allows firms to assess whether digital asset activity was previously reported accurately and whether corrective action or amendments may be appropriate.

Source type 2: Onchain data (Wallets and blockchain records)

For activity involving self-custody wallets and decentralized protocols, blockchain records are the authoritative source of transaction history. This includes assets held outside custodial exchanges and transactions executed directly through smart contracts.

On-chain data is essential whenever activity occurs outside a broker’s reporting perimeter or when assets move between venues.

What Onchain data is used for

• Completing transaction history: Blockchain records capture transfers and contract interactions that never appear on custodial exchange reports.
• Reconciling cross-platform activity: When assets move between exchanges and wallets, on-chain transactions provide the linkage needed to trace activity across venues.
• Identifying decentralized activity: Trades, liquidity activity, and rewards earned through non-custodial protocols are only visible through wallet-level blockchain data.
• Supporting acquisition history: When assets are later sold on an exchange, on-chain records often provide the missing link back to earlier transactions.

Practical characteristics of onchain data

• Authoritative but low-context: Blockchain records show what occurred (transfers, contract calls), but not the economic intent. Interpretation often requires protocol-level understanding.
• Protocol abstraction: Some applications pool or abstract user activity within shared contracts, meaning wallet-level records may not tell the full story without additional interpretation.
• Not tax-ready by default: Raw blockchain data is not organized around tax concepts and must be normalized before reporting.
• Requires tooling: Manual review of explorers is insufficient for reconciliation at scale.

Common firm use cases

1. Reconciling transfers between venues

When a client moves assets from a custodial exchange into self-custody, transacts, and later returns assets to an exchange to sell, the exchange may reflect a disposition without sufficient acquisition history. On-chain transaction records establish the continuity needed to reconcile the sale to prior activity.

2. Identifying decentralized activity

Decentralized exchanges and protocols do not issue tax forms or statements. Wallet-level blockchain data is how firms identify:

• Token swaps
• Liquidity pool activity
• Yield or protocol rewards
• Asset wrapping or unwrapping

3. Capturing self-custody income events

Rewards earned directly to wallets do not appear on broker tax forms. Blockchain records establish timing and quantities, which can then be paired with pricing data for reporting.

Firm workflow guidance

• Treat blockchain data as the system of record for all self-custody and decentralized activity.
• Do not rely on block explorer screenshots or links as workpapers.
• Use tooling that can:
  1. Ingest blockchain data by public wallet address
  2. Interpret smart contract interactions
  3. Normalize transactions into a chronological ledger
  4. Match transfers across exchanges and wallets
  5. Apply pricing at transaction timestamps

Specialized crypto subledger platforms (such as CoinTracker) are designed to perform this normalization so firms can focus on reconciliation and reporting rather than manual interpretation.

Key point: On-chain data is not about determining tax outcomes in isolation. Its role is to ensure completeness and continuity of transaction history when activity occurs outside custodial reporting systems.

Source type 3: Crypto tax platforms (e.g., CoinTracker)

Crypto tax platforms function as a normalization and reconciliation layer between raw data sources (exchanges and wallets) and downstream tax reporting. They do not replace primary records. Their value lies in organizing, reconciling, and standardizing activity across venues.

What these platforms do well

• Aggregated sources: Combine activity from multiple U.S. exchanges, non-U.S. exchanges, and self-custody wallets into a single chronological ledger.
• Standardize data: Normalize asset symbols, timestamps, and transaction formats across platforms that use inconsistent conventions.
• Identify internal transfers: Match withdrawals and deposits between accounts and wallets to avoid double-counting activity.
• Apply consistent accounting treatment: Apply the firm’s selected accounting methodology (e.g., FIFO, HIFO) consistently across all activity.
• Separate transaction types: Distinguish trades and disposals from income events (staking, mining, protocol rewards) based on transaction behavior rather than platform labels.
• Reconcile broker reporting: Compare platform-calculated proceeds and gains against Forms 1099-DA to identify gaps caused by missing acquisition information or off-platform activity.

Limitations to keep in mind

• Dependent on completeness of inputs: If a wallet or exchange is missing, the ledger will be incomplete.
• Requires professional review: Outputs are not “final answers.” They require validation against client disclosures, balances, and known activity.
• Not a substitute for judgment: Complex DeFi activity, edge cases, and historical gaps still require practitioner interpretation.

Firm guidance

Treat the platform output as a reconciled transaction ledger, not an authoritative source document. These steps are about ensuring the data set is complete and internally consistent before tax reporting.

At a minimum, firms should:

• Confirm all sourced are connected: Reconcile connected exchanges and wallets to the client’s disclosures and organizer responses.
• Review unmatched inflows and outflows: Deposits or withdrawals that do not resolve to another known account typically indicate a missing data source or misclassification.
• Reconcile ending balances: The platform’s calculated holdings should align with the client’s actual year-end positions.
• Review transfer activity: Ensure assets moving between platforms retain coherent acquisition history across the ledger.
• Spot-check income classification: Confirm that reward-like inflows are treated as income events rather than nontaxable deposits.

For form 8949 preparation:

• Use platform exports as a structured input for Form 8949 preparation, not as an unquestioned source of truth.
• Adjust reported gain or loss where broker reporting lacks acquisition information or does not reflect off-platform activity.
• Maintain workpapers showing how transaction history was reconstructed across exchanges and wallets.
• Ensure the final return reflects economic reality, not just what appears on a single broker form.

Key point: Crypto tax platforms do not create data. They organize it. Their value depends on completeness of sources and professional review.

2025

Crypto Tax
Guide is here

CoinTracker's definitive guide to Bitcoin & crypto taxes provides everything you need to know to file your 2024 crypto taxes accurately.

Get startedLearn more

Other client-provided materials

In practice, firms often receive a variety of client-created or client-facing materials alongside exchange and wallet data. These materials can provide helpful context, but they are not reliable systems of record and should not be treated as primary sources for tax reporting.

This category includes client-prepared spreadsheets, screenshots, PDFs, app views, and verbal or written narratives.

What these materials are useful for

• Providing context: Notes explaining why assets moved, why records are missing, or what a particular transfer represented.
• Identifying gaps: Highlighting exchanges, wallets, OTC trades, or historical activity that may require further data collection.
• Preserving history: In limited cases, PDFs or statements from defunct platforms may be the only remaining reference to prior activity.

Used appropriately, these materials help guide discovery and reconciliation. Used improperly, they introduce uncertainty and unsupported assumptions.

Key limitations

• Not systems of record: Client-created or client-facing materials are summaries, not authoritative transaction ledgers.
• Incomplete by nature: Screenshots and balance views lack acquisition history and transaction detail.
• Not independently verifiable: Without underlying exchange records or blockchain data, figures cannot be substantiated.
• Prone to inconsistency: Dates, amounts, and classifications are often estimated, rounded, or mislabeled.
• Insufficient for reporting on their own: These materials cannot support gain, loss, or income calculations without corroborating data.

Practical firm guidance

• Treat client-prepared spreadsheets, screenshots, PDFs, and narratives as supplemental context only.
• Use them to identify what data is missing, not to replace missing transaction history.
• Do not report gains, losses, or income based solely on estimates, summaries, or memory.
• When underlying records are unavailable, document the limitation, the efforts made to obtain data, and the basis for any conservative reporting position.

Common red flags that warrant follow-up include:

• Rounded or estimated amounts
• Missing transaction dates or identifiers
• Unexplained inflows or outflows
• Balances that do not reconcile to exchange or wallet data

Key point: These materials help explain activity, but they do not establish it. Accurate reporting still depends on exchange records, wallet-level blockchain data, and professional reconciliation.

Putting it together: Best practices for firms

Once firms understand the relative strengths and limitations of different crypto data sources, the remaining challenge is operational consistency. The goal is not to over-engineer the process, but to ensure that data collection and review are repeatable, complete, and defensible.

The "gold standard" workflow:

Step 1: Map the universe

Begin by confirming where the client’s digital assets were held or used during the year. This typically includes:

• U.S. custodial exchanges
• Non-U.S. exchanges
• Self-custody wallets
• Decentralized protocols or applications
• Any closed or defunct platforms with historical activity

This step is about scoping, not collecting every record at once.

Step 2: Ingest primary data sources

Collect transaction history directly from systems of record:

• Exchanges: Prefer API access where available; otherwise, obtain native CSV exports covering all activity types.
• Self-custody wallets: Capture public wallet addresses and ingest on-chain transaction history.

At this stage, the objective is completeness, not tax classification.

Step 3: Normalize and reconcile activity

Use a crypto subledger platform (such as CoinTracker) to:

• Combine exchange and wallet data into a unified ledger
• Identify transfers between accounts and wallets
• Normalize timestamps, assets, and transaction formats
• Surface missing data sources or unresolved activity

This step replaces manual spreadsheet reconciliation and highlights gaps early.

Step 4: Validate the dataset

Before preparing tax forms, perform reasonableness checks:

• Confirm all disclosed exchanges and wallets are connected
• Review unmatched deposits or withdrawals that suggest missing data
• Reconcile calculated year-end holdings to the client’s actual positions
• Ensure transfers between venues retain coherent acquisition history

Only after the dataset is internally consistent should tax reporting begin.

Step 5: Prepare tax reporting outputs

Use reconciled transaction data as structured input for Form 8949 and income reporting. Where broker forms omit acquisition information or fail to reflect off-platform activity, adjustments should be supported by the reconstructed transaction history and documented in workpapers.

Step 6: Document assumptions and limitations

Maintain clear workpapers that show:

• Data sources relied upon
• How transaction history was reconstructed across venues
• Any known gaps, assumptions, or client-provided context
• How discrepancies between broker forms and reconciled data were resolved

This documentation supports both internal review and future inquiries.

Data acceptance guidelines

To support consistency across engagements, firms benefit from setting clear expectations around what types of crypto data are relied upon and how they are used.

Primary sources (preferred)

• Exchange APIs
• Native CSV exports from exchanges
• Public wallet addresses used to retrieve blockchain data

Supporting materials

• Client-downloaded CSVs (when transaction IDs and timestamps are intact)
• PDF statements from exchanges, including defunct platforms
• Blockchain transaction hashes referenced by the client

Contextual evidence only

• Screenshots or app views
• Client notes or narratives explaining activity
• Bank statements showing fiat movements

Client-created summaries, estimates, or recollections should never replace transaction-level records, but they may help identify what additional data needs to be collected.

Key point: Consistent processes matter more than perfect data. Firms that apply the same intake, reconciliation, and review standards across clients are better positioned to identify gaps early and avoid downstream issues.

Special considerations for 2026 and beyond

Beginning January 1, 2026, some U.S. custodial platforms will begin reporting cost basis to the IRS for certain assets. In practice, your workflow should pivot on a single question: does the platform have complete acquisition information for the units being sold?

Where broker basis reporting helps most (starting 2026):

• Digital assets acquired on or after January 1, 2026 and held continuously at the same U.S. custodial exchange may include broker-reported cost basis and acquisition details.
• Firms should still review for reasonableness and reconcile to known transfers, fees, and prior-year positions.

Where gaps will still be common (including 2026+):

• Assets acquired before January 1, 2026
• Assets transferred between exchanges or into/out of self-custody
• Assets routed through DeFi before being sold on an exchange

In these situations, brokers may show proceeds with missing or incomplete acquisition history. The fix is the same as today: rely on exchange transaction history (API/CSV), wallet-level on-chain records, and prior-year records to reconstruct acquisition history and support basis.

Practical takeaway for firms: expect a mixed environment after 2026; some dispositions with broker-reported basis, many dispositions where basis still must be established from underlying data sources and reconciled across venues.

Data quality = risk management

Crypto tax work is rarely derailed by technical tax rules alone. More often, issues arise from incomplete, inconsistent, or fragmented data. The same activity can appear very different depending on whether it is sourced from an exchange ledger, a wallet address, or a client-created summary. How firms evaluate and prioritize those sources directly affects reporting accuracy and downstream risk.

Every time a firm relies on secondary or summary materials instead of systems of record, it increases the likelihood of:

• Incorrect or unsupported cost basis (overstated or understated gains)
• Missing taxable events (e.g., off-exchange trades, DeFi activity, wallet-level rewards)
• Reconciliation issues between years or platforms
• Additional exposure during review, amendment, or examination

Form 1099-DA will improve reporting in some situations, but it does not eliminate reconciliation. Transfers between platforms, self-custody activity, decentralized protocols, and historical transactions will continue to create gaps that standardized forms do not resolve on their own.

Firms that scale their crypto practices successfully don't just work harder; they enforce stricter data standards. They:

1. Prioritize exchange and on-chain data as systems of record
2. Use subledger tools to normalize and reconcile activity across venues
3. Treat client-created materials as context, not evidence
4. Apply consistent intake, review, and documentation standards across engagements

The alternative, accepting whatever lands in the client portal and working backward at filing time, leads to rework, missed issues, and avoidable risk.

In crypto, data quality is not a theoretical concern. It is an operational one. Firms that enforce clear data standards and repeatable workflows spend less time untangling records, face fewer surprises at filing, and are better positioned to support their work if questions arise later.