The Crypto Tax Three-Record Problem: Why Your 1099-DA, Tax Software, and Transaction History Produce Different Numbers

Last Updated on June 25, 2026 by Patrick Camuso, CPA

Quick answer (read this first):

What the three records are: Every crypto investor has three independent records describing the same activity: the broker’s Form 1099-DA (or Form 1099-B), the output of their accounting or tax software, and the underlying exchange and on-chain transaction history. These are not three views of the same data but three separate systems, built for different purposes by different parties, that were never designed to produce identical results.

Why it matters now: Beginning with 2025 transactions, custodial brokers report gross proceeds directly to the IRS. Beginning with 2026 transactions, basis reporting phases in for covered assets. The IRS matching system compares what brokers report against what appears on the taxpayer’s return. Where those diverge, a discrepancy exists in the system regardless of whether the underlying math is correct.

Which record controls: The taxpayer’s own records control the tax position. The 1099-DA establishes what the IRS received from the broker. Where the two differ, Form 8949 is the reconciliation mechanism, and the exchange and on-chain history is the evidence that must support whatever position is taken.

The risk that most investors miss: Most 1099-DA mismatches will not reflect fraud or deliberate underreporting. They will reflect the structural divergence between three systems that were never designed to agree. Understanding where that divergence comes from and documenting why the taxpayer’s records control is what converts a mismatch into a manageable compliance position rather than an automated notice.

Why Three Records Exist and Why They Were Never Designed to Agree

The 1099-DA crypto tax mismatch most investors encounter when their broker form, their software, and their exchange records produce different numbers is not a temporary data quality issue that better software will eventually solve. It is a structural feature of how crypto tax information is generated, and it exists because each of the three records was built by a different party to serve a different purpose for a different audience.

The broker’s Form 1099-DA is built from the broker’s own custody data, using the broker’s own lot identification system, the broker’s own valuation methodology, and the broker’s own classification logic for what constitutes a reportable disposal. It was built to satisfy the broker’s compliance obligations to the IRS, not to reflect the taxpayer’s tax position or to agree with any other data source. It goes to the IRS whether or not the taxpayer sees it, and the IRS treats it as presumptively reliable for matching purposes.

The accounting or tax software output is a calculation built from whatever data the investor provided, using the classification rules built into the platform, and reflecting the method settings the investor configured. Different platforms apply different logic to the same transaction types. Some classify the same DeFi event as taxable while others treat it as a nontaxable transfer. Some capitalize fees into basis while others deduct them separately. The output was built to help the investor calculate their taxes, not to match what any specific broker will report to the IRS. It is as accurate as the data fed into it and the configuration choices made along the way.

The exchange and on-chain transaction history is the raw record of what actually happened including the blockchain transactions, exchange order histories, wallet transfer records, and protocol-level events. It assigns no tax labels to anything and calculates no gains or losses. It captures economic activity as it occurred, with timestamps, amounts, and addresses. Both the broker and the accounting software derive their outputs from some version of this underlying record, but neither of them captures it completely or interprets it identically.

None of these three records was designed to reconcile with the others. The three-record problem has always existed, but it operated below the surface when crypto was largely a self-reported asset class with no third-party data flowing to the IRS. The digital asset compliance era changes that. With Form 1099-DA now live for 2025 transactions and basis reporting phasing in for 2026, the IRS has a standardized data anchor on the proceeds side of every covered transaction for the first time. Divergence between the broker’s view and the taxpayer’s return is now systematically visible in a way it was not before, and the compliance obligations that have always existed are now enforced through matching infrastructure that makes gaps and mismatches detectable at scale.

The structural implications of that transition are analyzed in detail in our Tax Notes Federal policy analysis co-authored with the former head of the IRS Office of Digital Assets.

Where the Records Diverge and Why

Several structural sources of misalignment operate independently and compound across a portfolio, and the compliance risk they create is most manageable when investors understand where each one originates.

Timing and Timestamps

Digital assets trade continuously across time zones with no market hours. The timestamp convention used to assign a transaction to a tax year, or to establish the fair market value at the moment of a receipt event, varies across systems. Brokers report using standardized time conventions that often differ from what exchanges record in their order histories, and both may differ from what the tax software imports and displays. For any transaction occurring near year-end, the assignment to a tax year can differ across the three records without any error by any party. A December 31 disposal in the investor’s records can surface as a January 1 transaction in broker reporting if time conventions are misaligned, affecting the year of recognition and in some cases the holding period calculation.

Fee Treatment

Fees paid to acquire a digital asset are supposed to be added to the cost basis of the asset acquired, reducing future gain. Fees paid on disposal are supposed to reduce the sale proceeds, which has the same economic effect. Fees paid to transfer assets between the investor’s own wallets are not supposed to affect basis at all under current IRS guidance. These rules are straightforward on paper and inconsistently applied in practice. Different tax software platforms treat the same gas fee differently depending on whether the platform categorizes the underlying event as an acquisition, a disposal, or an internal transfer. Brokers building their own basis calculations apply different fee allocation logic. The result is that the same transaction can produce different basis and different gain across the three records through no fault of anyone.

Transaction Classification

Whether a specific blockchain event is a taxable disposal, a nontaxable internal transfer, a receipt of income, or a protocol interaction with its own tax treatment is a classification judgment. The tax software makes that judgment automatically using logic built into the platform. The broker makes it using the broker’s own systems. The underlying blockchain record makes no determination at all. For standard purchases and sales on a single custodial exchange, classification is usually consistent across all three records. For any activity involving DeFi, cross-chain bridges, liquidity pools, staking, or wallet-to-wallet movements, classification divergence is common and consequential. A withdrawal from an exchange treated as an internal transfer by the investor but classified as a disposal by the broker creates phantom gain on the 1099-DA alongside understated basis at the destination wallet. These classification divergences are not errors in the traditional sense. They are the output of three systems applying different logic to the same event.

Lot Identification and Method Choice

The broker’s 1099-DA basis for covered assets reflects the lot identification method the broker has on file for the account, which defaults to FIFO at most custodial platforms. If the investor is using HIFO-ordered specific identification through their accounting software while the broker applies FIFO to its reporting, the 1099-DA basis will reflect different lots than the investor’s return on every covered disposal. The IRS receives proceeds from the broker and gain from the return. Where those produce different implied basis figures, a discrepancy exists in the matching system for every covered transaction. This is one of the most predictable and systematic sources of 1099-DA divergence, and it will affect every investor who uses a cost basis method in their software that differs from their broker’s default.

Wallet Boundaries

Current guidance requires basis to be tracked at the wallet or account level rather than pooled across an investor’s entire holdings. But the definition of what constitutes a single wallet for this purpose is not settled, particularly for investors using self-custody. A hierarchical deterministic wallet generates a new address for each transaction while remaining a single wallet economically. A smart-contract wallet may hold assets from multiple sources with no clear single-ownership boundary. An enterprise custody structure may aggregate assets across legal entities that each constitute separate taxpayers. Two investors with identical underlying transaction histories who draw wallet boundaries differently will compute different basis allocations, different lot inventories, and different gain figures, with all three of their independent records remaining internally consistent while diverging from each other.

Which Record Controls and What That Means in Practice

The investor’s own records control the tax position. The broker’s Form 1099-DA does not determine the investor’s gain or loss. It determines what the IRS received from the intermediary and what the matching system will compare against the return. The mechanism for reconciling the two when they differ is Form 8949. The investor reports the proceeds shown on the 1099-DA, enters the correct basis from their own records in the basis column, uses adjustments to indicate that the broker-reported basis is incorrect, and enters the difference in the adjustment column. The corrected gain flows to Schedule D. Every line where the 1099-DA basis differs from the return needs an adjustment and documentation explaining which lot was identified, when the identification was made, and why the investor’s records control.

The underlying exchange and on-chain transaction history is what that documentation must be built from. If an IRS examiner asks where a basis figure came from, the answer has to trace back to a documented acquisition event in the exchange records or blockchain history. A software-generated gain and loss summary that cannot be traced to underlying transaction data is a calculated number rather than a supported tax position, and that distinction matters when the IRS matching system flags a discrepancy.

For investors using specific identification with HIFO-ordered lot selection, the relevant question at each disposal is not what the software shows but whether the lot identification was recorded before the transaction executed and whether documentation of that identification can be produced. An HIFO gain and loss report from software that does not generate and preserve contemporaneous lot identification records does not satisfy the specific identification standard. Where that documentation is absent, the position defaults to FIFO regardless of what the software report shows, and the investor is effectively reporting HIFO results without the records to support them.

How All Three Records Come Together on the Tax Return

Form 8949 is where the three records formally converge, and understanding how each one feeds into it makes the reconciliation concrete. The broker’s 1099-DA supplies the proceeds figure for each covered disposal. The investor has no discretion here. The IRS already has that number from the broker, and the return needs to account for it.

The investor’s own records supply the basis. If the investor used HIFO-ordered specific identification while the broker applied FIFO, the basis on the return will differ from what the broker’s 1099-DA implies. That divergence is expected. An adjustment captures the difference and signals to the IRS that the broker-reported basis is incorrect. The corrected gain flows to Schedule D, which determines the actual tax. For noncovered assets, where the broker reports proceeds but no basis, the investor supplies basis from their own records with no adjustment needed, because the broker was never required to report basis for that lot. For DeFi, self-custody, and foreign exchange activity with no broker reporting at all, the investor supplies both proceeds and basis entirely from their own records.

The important point is that this process only works cleanly when the three records are reconciled before filing. An investor with gaps, classification errors, or undocumented method divergences is filling in numbers that may survive as filed but cannot be defended if the IRS follows up.

When an investor uses a different cost basis method than the broker, the divergence is permanent at the inventory level. The lots relieved on the investor’s return are different lots than the broker relieved, and the remaining inventory in the investor’s records diverges from what the broker believes remains after every disposal. That gap compounds with each subsequent year because the 2026 return already anchors which lots were sold, and every future 1099-DA must be reconciled against that filed position going forward. Early errors compound the same way. A misclassified transfer that assigned zero basis in 2021 produces a wrong-basis lot that distorts every calculation built on top of it for as long as that lot remains in inventory.

This is why the transitional relief period ending December 31, 2026 matters operationally. Investors using HIFO through their accounting software without a standing order with the broker are building a permanent lot pool divergence into their records that requires active reconciliation management in every subsequent filing year. Planning means establishing the right broker-level instructions before December 31, not after the first 2027 transactions execute. The full mechanics are covered in our IRS Notice 2026-20 analysis.

When the Records Cannot Be Reconciled

The three-record problem has a harder version that goes beyond methodological divergence. In portfolios with multi-year histories across multiple exchanges, self-custody wallets, and DeFi activity, the underlying transaction history itself is often incomplete.

When an exchange has no record of an acquisition because the asset was purchased years ago, the exchange closed, the export was incomplete, or the wallet was never reconciled, the accounting software either assigns zero basis to that lot or omits it entirely. The calculation proceeds with a wrong basis figure, and the software-generated gain and loss report looks complete because the software filled the gap with a default assumption rather than flagging it. The broker’s 1099-DA reports proceeds from the disposal without any basis information because the broker has no custody lineage for an asset that predates the broker’s tracking. The IRS receives proceeds with no corresponding basis, the investor’s return reflects a gain calculated from zero, and the result is a substantially overstated tax liability rooted in a data gap that software output cannot identify or cure.

A wallet-to-wallet movement that the accounting software treats as a disposal creates phantom gain on the sending side, removes the lot from inventory, and creates a new lot at the destination with no acquisition history. The next disposal from that wallet calculates gain from zero basis because the original lot is no longer in the inventory where it should be. The broker’s 1099-DA reflects a real disposal at the destination that the investor’s records cannot trace to any acquisition, which means the cost basis the investor’s software assigns to that disposal cannot be substantiated from the exchange records. This is exactly the kind of structural gap that becomes visible when the three records are reconciled against each other and that cannot be resolved by adjusting software settings or rerunning the calculation.

When the underlying transaction history has these kinds of gaps, reconciling the three records exposes them rather than resolving them. The software shows a basis for a lot that does not have a documented acquisition event in the exchange history. The 1099-DA shows proceeds for a disposal that cannot be matched to a lot in the software inventory. These signals indicate that the records are not simply diverging at the method level. The underlying data has structural gaps that require reconstruction to address, and that reconstruction needs to happen before the return is filed rather than in response to an IRS notice after it.

What makes this particularly important in the current enforcement environment is that the IRS automated matching system cannot distinguish between a mechanical alignment problem and substantive underreporting. A portfolio with five years of unreconciled DeFi activity and missing transfer records will generate the same type of automated discrepancy flag as deliberate omission of income. The investor may have reported entirely in good faith and still face a CP2000 notice because the structural difficulty of aligning their three records produced a mismatch signal that looks identical to underreporting from the matching system’s perspective. Addressing that notice requires substantiation, not just a corrected calculation, which is why building the reconciliation workpaper before filing is substantially more protective than doing so in response to IRS inquiry.

The Shared Software Layer Problem

One dimension of the three-record problem that does not receive enough attention is that the three records are not always truly independent. Brokers, accounting software platforms, and the IRS enforcement systems that ingest matching data all rely on related or overlapping software infrastructure. When that shared layer embeds a classification assumption or a coverage limitation, the error does not stay in one record, it propagates across all three simultaneously. An investor whose software misclassifies a DeFi staking event may be using the same underlying classification logic the broker used. The IRS matching tools looking for discrepancies between the 1099-DA and the return may then flag a divergence that reflects a shared data quality problem rather than substantive underreporting, and neither the investor nor the broker will immediately know that the disagreement originated in the software layer both of them relied on.

This shared-layer dynamic also explains why compliant investors with detailed records can still receive automated CP2000 notices. The notice does not indicate that the IRS has concluded the investor underreported. It indicates that the automated matching system found a discrepancy between what the broker reported and what appeared on the return. Where that discrepancy reflects the structural misalignment of three records that were never designed to agree, the compliance obligation is to document why the taxpayer’s records control and respond to the notice with substantiation rather than to treat the notice as evidence of an error.

The IRS itself has contracted with some of the same crypto tax software providers that investors use to calculate their own positions. In some audit contexts, an IRS examiner may be applying the same underlying classification logic and the same default assumptions as the software that produced the taxpayer’s return. Where those tools disagree with each other because of version differences, method settings, or data completeness variations, the dispute between the examiner and the taxpayer may reflect software divergence rather than substantive underreporting. Both sides are downstream of the same shared infrastructure, and neither side may be aware that the disagreement originates in a data quality or classification problem rather than in the underlying transaction facts.

What Crypto Tax Software Does Not Tell You

Academic research by Dr. Tyler Mensor, CPA, of Texas Christian University identified several characteristics of crypto tax software that most investors do not know and that bear directly on how the three-record problem plays out under audit. We cover this in our podast, The Financial Frontier.

The first is that the software recalculates from scratch on every session. Most platforms re-pull blockchain data and recompute the investor’s entire history from the beginning each time they log in. If the platform has updated its classification logic, changed a default method, or revised how it handles a specific transaction type since the prior filing, logging in after filing can produce a different number for the same prior-year transactions that produced the filed return. The filed return and the current software output are no longer the same calculation. This means an investor who needs to explain or defend a prior-year position cannot simply log back into the software and show the examiner what the software says now, because what the software says now may not match what it said when the return was filed. The only reliable record of what the software produced at the time of filing is an export saved before or at the time of filing, combined with the underlying transaction data that supported that calculation.

The second is that good faith reliance on crypto tax software almost certainly does not provide penalty protection. Dr. Mensor reviewed the terms of service of major platforms and found a direct contradiction between their front-facing marketing and their legal disclaimers. The platforms market themselves as solving crypto tax reporting but disclaim all liability in their terms of service, explicitly stating that the platform does not provide accounting or tax advice and should not be used as a replacement for professional accounting. The penalty relief available to investors who relied on the advice of a licensed tax professional who signed their return does not extend to software platforms that disclaim professional status and bear no legal responsibility for the outputs they produce. An investor assessed an accuracy-related penalty for a position that originated in software output has no professional reliance defense to raise.

The third is that the software platform may not exist when an audit arrives. The IRS statute of limitations runs three years for most returns, six years for returns with substantial omissions, and longer in cases involving fraud. Many crypto tax platforms are small operations with low startup costs and uncertain longevity. If the platform an investor used in 2024 is acquired, pivoted, or shut down by 2028 or 2030, the investor cannot access it to reproduce the calculation that supported the filed return. Without a contemporaneous export of the full transaction history and the methodology applied at the time of filing, the investor has no basis figures traceable to any documented calculation process. What remains is a filed return showing numbers whose origin cannot be explained and an enforcement system that expects the investor to substantiate every position from records they own, not from a platform they no longer have access to.

What Defensible Reconciliation Requires

Proceeds on the return should match what the broker reported on the 1099-DA. Where they do not, the source needs to be documented. Every disposal where the 1099-DA basis differs from the investor’s own basis needs an adjustment and the lot-level documentation explaining why, whether that is a HIFO versus FIFO divergence, a noncovered asset where the broker reported no basis, or an event the investor is treating as a nontaxable internal transfer rather than a disposal. Every lot needs to be traceable to a documented acquisition event in the exchange records or on-chain history. If a lot cannot be traced, that gap requires reconstruction before the return is filed, not after an IRS inquiry arrives.

The reconciliation itself should be retained as a workpaper. When the IRS follows up, the reconciliation is the first document that needs to exist, and assembling it under audit pressure is substantially harder than completing it before filing.

For investors navigating this for the first time, our 1099-DA compliance services and crypto cost basis reconstruction services address the full reconciliation and documentation process. For a deeper understanding of the 1099-DA mechanics, 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

What is the three-record problem in crypto tax?

The three-record problem is the structural divergence between the three independent data sources that describe a crypto investor’s activity: the broker’s Form 1099-DA tax reporting, the investor’s accounting or tax software output, and the underlying exchange and on-chain transaction history. These systems were built by different parties for different purposes and were never designed to produce identical outputs. Divergence across them is not a software bug or a user error but the predictable result of three independent systems applying different logic to the same underlying activity.

Why does my 1099-DA show different basis than my crypto tax software?

The most common cause is lot identification method: if the investor is using HIFO-ordered specific identification in their software while the broker defaults to FIFO, every covered disposal will reflect different lots and different basis. Other sources include fee treatment differences, timing convention differences for assets transferred between accounts, and classification differences on events the broker treats as covered disposals but the investor treats as nontaxable internal transfers. The investor’s records control the tax position, and the divergence between the investor’s basis and the broker’s reported basis is managed through Form 8949 Code B adjustments supported by the investor’s lot-level documentation.

Which record controls when my 1099-DA differs from my return?

The investor’s own records control. The broker’s Form 1099-DA establishes what the IRS received from the intermediary. Where the investor’s position differs, Form 8949 Code B adjustments bridge the gap with documentation of why the investor’s records control. The underlying exchange history and on-chain transaction record is the evidentiary foundation that must support the investor’s position if the IRS asks where the basis figures came from.

Do I need to match my return exactly to my 1099-DA?

Proceeds reported on the return should generally match what the broker reported on the 1099-DA. Basis does not need to match, and for investors using specific identification with cost-basis-ordered lot selection, it generally will not. The reconciliation obligation is to explain the basis difference on Form 8949 with adjustment Code B and supporting lot documentation, not to conform the return to the broker’s basis calculation.

What is a Form 8949 adjustment?

An adjustment on Form 8949 signals to the IRS that the broker-reported basis is incorrect. The investor reports the proceeds from the broker’s form, enters their own correct basis, marks the adjustment code to flag the discrepancy, and enters the difference between the broker figure and the correct figure in the adjustment column. The corrected gain flows through to Schedule D. Every adjustment needs documentation showing which lot was used, what it cost, and why the investor’s records control.

What happens when my lot pool diverges from the broker’s?

When an investor uses a different cost basis method than the broker, the remaining lot inventory in the investor’s records reflects different lots than what the broker believes is still in the account. That divergence grows with each disposal and is permanent once embedded in a filed return. Every future 1099-DA from that broker will reference lots that the investor’s records have already treated differently, and Form 8949 Code B adjustments are the mechanism for reconciling the broker’s reporting each year going forward.

What if my records are missing acquisitions that explain proceeds on my 1099-DA?

Missing acquisition history means the IRS receives proceeds from a sale with no corresponding basis the investor can substantiate. The information needs to be reconstructed from whatever evidence exists, including exchange records, on-chain data, and secondary documentation, with conservative assumptions documented where gaps remain. Software output showing zero basis or an estimated figure is not reconstruction. See our crypto cost basis reconstruction guide for how the process works.

Is this something my tax software can fix automatically?

No. Software calculates from the data it receives. When that data has gaps, or when the broker classified an event differently than the software did, the divergence is invisible to the platform and cannot be resolved by rerunning the calculation. Reconciling the three records is an analytical process that requires comparing what each system produced, identifying where they differ and why, and building documentation that explains the gaps. Our 1099-DA compliance services address this for investors navigating it for the first time.