Last Updated on April 16, 2026 by Patrick Camuso, CPA
Quick answer (read this first):
What crypto tax software does: It calculates gains and losses from the transaction data imported into it. It applies an accounting method to whatever inventory it has and produces a report.
What it cannot do: Identify records it was never given, verify that transfers were correctly matched, substantiate fair market valuations for income events, or produce a defensible tax position from incomplete data.
The core problem: For investors with multi-year histories, cross-platform activity, and DeFi or self-custody positions, the software almost always has incomplete data. The output looks complete but it usually is not. Crypto tax software fails with historical portfolios.
What Software Actually Does
Crypto tax software is a calculation engine. It receives transaction data through API connections, CSV imports, or manual entry, applies an accounting method to that data, and produces a gain and loss report.
When the input is complete and correctly classified, the output is reliable. When the input has gaps, errors, or misclassifications the common condition for any investor with more than two or three years of activity the output reflects those deficiencies without identifying them. The report appears complete but the basis figures it contains are not accurate.
This limitation is not specific to any one platform. Software calculates from whatever data it has been given. Transactions it never received, it cannot account for.
The Most Common Ways Software Fails
Missing transaction history
Every major crypto tax platform relies on data imports. Exchange APIs return data within their documented limits, which often exclude transactions beyond a certain date, account migrations, or activity from deprecated product lines. CSV exports from exchanges frequently omit partial fills, fee breakdowns, internal transfers, and certain transaction types. Platform migrations where an exchange upgraded its infrastructure and historical exports are no longer available create complete gaps.
When software does not receive a transaction, it has two options either assign zero basis to the asset when it appears later in the inventory, or flag the lot as unreconciled. Most platforms default to zero basis silently. The gain and loss report proceeds as if the acquisition never happened.
Platform failures and shutdowns
FTX, Celsius, Voyager, BlockFi, and a range of smaller platforms ceased operations with limited notice, taking transaction histories with them. In some cases, partial records are recoverable through bankruptcy claims processes or archived platform data, but for many investors those records are gone. Software that was connected to these platforms before they failed may have incomplete imports that were never flagged as incomplete the connection simply stopped returning data at the point of shutdown. The inventory from that point forward carries whatever gaps the shutdown created.
Unmatched transfers
A wallet-to-wallet transfer is not a taxable event. The original lot, with its original basis and acquisition date, moves from one account to another. For software to handle this correctly, both the sending side and the receiving side must be imported and matched.
When the sending side is missing because the originating exchange was not connected, or the CSV was incomplete the software sees an asset arriving at a wallet with no acquisition record. It treats the deposit as a new acquisition at either zero basis or the market price at the time of receipt, depending on the platform’s default. The original lot is effectively abandoned in the software’s inventory and replaced with a phantom lot.
This is one of the most common sources of both phantom gains and understated basis in software output. It is also nearly invisible in the gain and loss report, because the report shows a number for every disposal it just does not show that the number was calculated from an incorrectly reconstructed lot.
Misclassified DeFi interactions
DeFi activity liquidity pool deposits and withdrawals, wrapped token conversions, bridge transactions, yield claims, and protocol-level exchanges requires classification before it can be calculated. The classification question is whether the event is a taxable disposal or a nontaxable transfer.
Software platforms make these classifications automatically based on their internal logic, and different platforms classify the same events differently. A liquidity pool deposit that one platform treats as a taxable disposal of the underlying assets may be treated as a nontaxable transfer by another. The resulting basis figures diverge, sometimes substantially, and neither treatment has necessarily been validated against the taxpayer’s specific facts.
For investors with significant DeFi history, the classification decisions embedded in software output may account for large portions of the reported gain or loss and those decisions were made automatically without the investor’s knowledge or review.
Layer 2 networks, bridges, and application-layer protocols create an additional indexing limitation. Activity on certain networks may not be fully captured by standard blockchain explorers or software import tools, particularly for transactions executed in earlier years. Where on-chain data is incomplete, the software cannot identify what it is missing.
The HIFO documentation failure
Many investors believe they are using HIFO highest-in, first-out because their software displays it as the selected accounting method. That assumption frequently fails under scrutiny.
HIFO is a lot selection strategy under specific identification, not a standalone IRS-recognized method. For HIFO results to be defensible, the software must have generated and preserved contemporaneous lot identification records at the time of each disposal, showing that the highest-basis lot was designated before the transaction executed. Most platforms produce HIFO gain and loss totals without generating those records. The investor sees a HIFO result on the report. What they actually have is undocumented FIFO the IRS default that applies when valid specific identification records cannot be produced.
The tax exposure from this failure can be significant. If the HIFO output showed materially lower gains than FIFO would have produced, and those HIFO positions cannot be substantiated in an examination, the IRS will recalculate using FIFO. The difference between what was reported and what FIFO would have produced becomes additional tax owed, with potential penalties on top.
Method inconsistency across years
Software platforms update their classification logic, change API behavior, and adjust default accounting method settings across product versions. Investors who have used the same platform for multiple years may be working with an import history where different years were processed under different platform logic producing an internally inconsistent lot inventory without any visible indication that this occurred.
Method elections can also be changed inadvertently. Reimporting data, resetting the account, or switching between plan tiers can alter how prior year transactions were classified. The current year report is produced from whatever state the platform is in now, which may not reflect the same treatment applied when the original returns were filed.
Valuation gaps for income events
Staking rewards, mining income, airdropped tokens, and liquidity mining distributions require fair market valuation at the time of receipt. The basis of those lots equals the income recognized, and the income recognized equals the fair market value at the moment of receipt.
Software platforms use price feeds to supply these valuations. For major assets on liquid markets, those price feeds are generally reliable. For thinly traded tokens, newly launched protocols, and assets received during periods of thin liquidity or extreme volatility, the price feed may be imprecise, unavailable, or defaulted to a timestamp that does not match the actual receipt time.
The basis figures produced for income-type acquisitions carry as much uncertainty as the underlying price data. That uncertainty is not disclosed in the gain and loss report.
Stale or incomplete imports
API connections expire, exchange permissions change, and rate limits restrict the volume of historical data that can be retrieved in a single session. Investors who set up their software accounts years ago and have not actively maintained the connections may be working with imports that are partially current and partially stale without knowing which portions of their history are missing.
Software does not distinguish between a complete import and an incomplete one. Both produce a report. The completeness of the underlying data is the investor’s responsibility to verify, and most investors do not have the visibility to do so.
What the Gain and Loss Report Does Not Disclose
The gain and loss report produced by crypto tax software does not show which lots carry zero basis because a prior acquisition was never imported, which transfers were correctly matched and which were assumed, which DeFi classifications were applied automatically and which have been reviewed against the taxpayer’s specific facts, which income valuations derived from reliable price data and which were estimated or defaulted, whether reported HIFO results are supported by contemporaneous lot identification records, which portions of the import history are complete and which contain gaps, or whether the accounting method applied in the current year is consistent with prior year treatment.
All of that information is visible only at the lot level in the underlying inventory, not in the summary report. Most investors never review the lot-level data.
The practical consequence is that the gain and loss report filed on a tax return may reflect dozens of embedded assumptions that were never disclosed, reviewed, or verified against primary records. The return appears complete. The positions behind those numbers cannot be defended if the IRS requests substantiation.
A further complication is that not all crypto tax platforms make lot-level cost basis reports available to users. Many platforms provide only the summarized gain and loss output with total proceeds, total cost basis, net gain or loss by asset without an exportable schedule showing each individual tax lot, its acquisition date, its cost, and how it was relieved. Some platforms offer lot-level detail only on higher-tier subscription plans. Others generate it internally but do not surface it in a format the taxpayer can review or export. In either case, the investor is filing a return from numbers they cannot independently verify at the transaction level.
This matters because a gain and loss summary, without the supporting lot-level schedule, cannot be used to identify where errors exist. An inaccurate lot is invisible in aggregate output. It only becomes visible when the underlying inventory is examined position by position. Where lot-level data is not available through the platform, reconstruction from primary records is the only path to a defensible basis schedule.
The practical consequence is that the gain and loss report filed on a tax return may reflect dozens of embedded assumptions that were never disclosed, reviewed, or verified against primary records. The return appears complete. The positions behind those numbers cannot be defended if the IRS requests substantiation.
The 1099-DA Mismatch Problem
A separate and increasingly significant software limitation is that software output and broker 1099-DA reporting are two different things and they are not designed to match.
When a broker processes a disposal, it applies whatever lot identification method its system is configured to use. If the taxpayer’s software method differs from the broker’s system method, the basis figures will not reconcile. For 2026 transactions involving covered assets, brokers are reporting both proceeds and basis to the IRS. The IRS receives the broker’s basis number and the taxpayer’s return reflects the software’s basis number. Where those diverge, a discrepancy exists that the taxpayer must be able to explain and document.
The IRS has explicitly acknowledged that broker-reported basis for covered lots may not match the taxpayer’s own lot identification under the current transitional relief framework. That expected mismatch does not eliminate the reconciliation obligation. Software output that cannot be reconciled to broker-reported basis is an additional documentation problem on top of the underlying calculation issues.
The Distinction Between a Calculation and a Substantiated Tax Position
A substantiated tax position is a reported number that can be traced back to documented evidence for every lot disposed of original acquisition record, documented cost basis, continuity across transfers, and defensible fair market value methodology for any income-type receipt. A calculation is a number produced by a software platform from whatever transaction data it received.
When the IRS requests documentation to support reported basis, the response must consist of primary records, not software output. Software output is the product of applying an accounting method to data. Where that data was incomplete, the method was correctly applied to defective inputs.
The operative question in any examination is whether every disposal on the return can be traced to a specific acquisition lot with a documented cost basis, a documented acquisition date, and unbroken lot-level continuity from acquisition through disposal. For most investors with multi-year histories across multiple platforms, that standard cannot be met using software output alone.
When Software Is Sufficient and When It Is Not
Software is sufficient when:
- Transaction history is complete and continuously imported from a small number of platforms
- No transfers between wallets or exchanges occurred, or all transfers are correctly matched
- DeFi activity is limited or absent
- The investor has been actively maintaining and reviewing the software account since the beginning of their activity
- The accounting method in use is FIFO, no specific identification claims have been made, and the lot inventory has been reviewed at the lot level
Software is not sufficient when:
- Activity spans more than two or three years across multiple platforms
- Wallets or exchanges that are no longer accessible were used in prior periods
- Platforms that have since shut down including FTX, Celsius, Voyager, or others were used at any point
- Significant DeFi, self-custody, or cross-chain activity occurred
- The investor has never reviewed the lot-level inventory for accuracy
- Zero-basis lots appear in the inventory without explanation
- HIFO or specific identification results are being reported without contemporaneous lot documentation
For most investors who have been active in the space since 2020 or earlier, the honest assessment is that software alone has not produced a defensible tax position. It has produced a calculation from incomplete data, and that calculation has been filed.
What a Defensible Position Actually Requires
Producing a defensible tax position from a historical portfolio requires starting at the lot level, not the report level. It means reviewing the underlying inventory to identify missing acquisitions, unmatched transfers, and misclassified events. It means going back to primary sources exchange records, on-chain data, email confirmations, and bank records to fill gaps that the software was never given. It means reviewing DeFi classifications against the specific facts of each interaction. And it means producing a lot-level inventory schedule that can be traced back to evidence for every entry.
Reconstruction is an evidentiary process that uses software as a tool for organization and calculation but depends on human review and judgment at every step where data is incomplete or classification is uncertain.
For investors who have relied on software output as their only tax record, the gap between what was filed and what is defensible may be significant. Identifying and closing that gap is the work of reconstruction.
For investors whose software output has never been reconciled at the lot level, our crypto cost basis reconstruction services and complete cost basis reconstruction guide cover the full process. For a full breakdown of how Form 1099-DA reporting works and what it means for basis substantiation, see our IRS Form 1099-DA guide. Work with a crypto CPA established in this market since 2016.
Contact us to discuss your situation
Frequently Asked Questions
Is crypto tax software accurate?
For investors with simple, continuous transaction histories on a small number of well-connected platforms, software can be accurate. For investors with multi-year histories, cross-platform activity, self-custody wallets, or DeFi involvement, software output typically contains errors that are not visible in the gain and loss report but are visible at the lot level. The accuracy of any software output depends entirely on the completeness and correctness of the underlying data.
Why does my software show a gain or loss if my records are incomplete?
Software produces a report from whatever data it has. If acquisitions are missing, it assigns zero basis to the affected lots. If transfers are unmatched, it creates phantom lots. If DeFi events are misclassified, it applies the wrong tax treatment. In every case, the report is complete it accounts for every transaction it knows about. It does not flag the transactions it was never given.
How do I know if my software output is wrong?
The clearest signals are zero-basis lots in the inventory, large numbers of unmatched transfers in the reconciliation report, DeFi transactions that were classified automatically without review, and exchanges or wallets that were never imported. If the software was connected to all platforms without gaps and every transfer is matched, the output is more likely to be reliable. If there are known gaps, the output is not complete.
My software says I used HIFO. Is that enough?
HIFO is a lot selection strategy under specific identification, which requires contemporaneous lot-level identification records showing that the highest-basis lot was designated before each disposal. Most software produces HIFO gain and loss totals without generating those underlying records. If the records do not exist, the IRS will treat the position as FIFO regardless of what the software report shows.
Can I fix my software output myself?
Minor corrections adding a missing transaction, correcting a misclassified transfer can sometimes be made within the software. For historical portfolios with significant gaps, the corrections required go beyond what most investors can identify or implement without access to primary records and knowledge of how the lot inventory should look at each point in time. Reconstruction at that level generally requires professional involvement.
Does using better software solve the problem?
Changing software does not fix incomplete records. The underlying data gaps follow the investor regardless of which platform is used. A different platform may have better import infrastructure or more accurate DeFi classification logic, but it cannot reconstruct acquisition history that was never recorded. The starting point for any accurate calculation is complete records, not better software.
Will my software match what my broker reports on Form 1099-DA?
Not necessarily, and not automatically. Brokers apply their own lot identification method when calculating reported basis for covered assets. If the broker’s method differs from the taxpayer’s software method, the basis figures will not match. The IRS receives both numbers. Where they diverge, the taxpayer must be able to explain the difference with documentation. Software output alone is not sufficient to resolve that discrepancy.
