A crypto tax-software output is a starting point, not a finished return. The aggregator was given a set of accounts, addresses, and transactions; it produced a set of gain/loss totals, ordinary-income figures, and a draft Form 8949. The corrected return position has to reflect the reconciled truth of what actually happened across every wallet, exchange, protocol, and chain the taxpayer touched. When the software output and the reconciled ledger disagree, the corrected amended return follows the reconciled ledger.
That posture matters because crypto tax software has known and documented limitations. Wallets get missed. Chains get partially imported. Transfers between the taxpayer’s own wallets get double-counted as sales. DeFi protocol events default to zero-basis dispositions when the protocol is not supported. NFT marketplace activity is reported inconsistently. Stablecoin swaps disappear into the noise. Fee handling varies. A Form 1040-X filed from an unreconciled software run can compound the original error instead of correcting it.
The fast decision table
| Situation | Reconciliation posture | Why |
|---|---|---|
| The software output’s gain/loss total does not match a hand-checked sample of dispositions | Source-ledger reconciliation before any amendment | A material sample mismatch usually indicates a systemic issue (missing wallet, wrong fee treatment, wrong identification method), not a one-off bug. |
| The software output flagged a long list of “missing cost basis” or “zero-basis” lots | Acquisition-reconstruction review | Zero-basis treatment overstates gain; the corrected return needs the actual basis or a documented zero-basis position. |
| The software did not import a wallet, chain, or protocol that the taxpayer used | Inventory and import gap review | An entire chain or protocol absence is a gap, not an edge case; the corrected return must add the missing activity. |
| The software flagged DeFi or NFT activity as unsupported | Protocol-by-protocol treatment review | Each protocol category has its own facts; the corrected return needs a treatment memo, not a default zero-basis posture. |
| The software output matches the prior return but neither matches the underlying source records | Reconciliation between exchange CSVs, on-chain logs, and the reported return | The reported return may already be inconsistent with the source records the software was given. |
| The 1099-DA the taxpayer received does not match the software’s gross-proceeds total | 1099-DA reconciliation as a discrete workpaper | Broker reporting and aggregator output can diverge; the corrected Form 8949 has to address the divergence. |
| A new software run on the same data produces different totals than the prior run | Methodology audit, then reconciliation | A software version change can shift basis allocation, fee treatment, or chain support; the methodology memo has to document what changed. |
The common failure modes
Software-output errors usually cluster into a small number of categories. The reconciliation review should test each one against the taxpayer’s actual records.
Missing wallets, chains, or protocols
The software output is only as complete as the source-system inventory it was given. Common gaps:
- A self-custody wallet was never added to the aggregator
- A custodial exchange account was added but the CSV export was incomplete
- A chain (Solana, Avalanche, Tron, Layer-2 networks, alt-L1s) was supported in name but not parsed correctly
- A DeFi protocol was used but not supported by the aggregator’s parser
- An NFT marketplace was used but the marketplace’s data feed was not integrated
Each gap shows up as missing income, missing dispositions, or both. The reconciliation review should produce an inventory of every source system the taxpayer touched and confirm that the aggregator output reflects all of them.
Duplicate transfers counted as sales
When the same property moves between two of the taxpayer’s own systems (exchange to wallet, wallet to wallet, exchange to exchange), the aggregator should match the withdrawal on one side to the deposit on the other and treat the movement as a non-taxable transfer. When the match fails, the aggregator typically defaults to two events: a sale on the sending side and a purchase on the receiving side. The result is an overstated gain on the sending side and a fresh basis lot on the receiving side that does not exist in reality.
The reconciliation review needs a transfer-matching workpaper for every wallet pair the taxpayer used.
Unsupported DeFi and NFT events flagged as zero-basis
When the aggregator does not recognize a transaction type, it often defaults to treating any incoming token as zero-basis income or any outgoing token as a zero-basis disposition. The result can be material overstated gain, ordinary income that does not match the protocol’s actual economic events, or both. Common categories:
- Liquidity-pool deposits and withdrawals
- Yield farming or staking position changes inside a protocol
- Token wrap and bridge transactions
- Governance-token claims or delegation events
- NFT mints, royalty receipts, and bundled-sale dispositions
Each unsupported event needs a per-event treatment decision in a methodology memo, not a default-zero-basis posture inherited from the software.
Stablecoin swap classification
Stablecoin-to-stablecoin or stablecoin-to-crypto swaps are generally taxable exchanges under 26 USC 1001, not currency conversions. Some aggregators correctly recognize them as dispositions; others silently treat them as currency moves with no taxable event. A return that silently dropped stablecoin swaps usually understates dispositions, sometimes materially.
Fee allocation errors
Acquisition fees should generally increase basis; disposition fees should generally reduce proceeds. Aggregators handle this inconsistently. The reconciliation review should sample fee-rich dispositions, confirm the fee treatment on each, and adjust as needed.
Basis pulled from the 1099-DA instead of the taxpayer’s records
For tax year 2025, the 1099-DA generally does not report basis; for tax year 2026 and later, basis reporting begins under Treas. Reg. 1.6045-1. Once basis reporting begins, the 1099-DA basis figure may not equal the supportable basis position, especially for assets that were transferred into the broker from a self-custody wallet. The corrected return position should reflect the taxpayer’s records, not default to the broker’s number.
The reconciliation workpaper
A defensible software-output reconciliation has a consistent structure:
- Source-system inventory. Every wallet, exchange, DeFi protocol, NFT marketplace, bridge, and fiat ramp the taxpayer touched, with the dates of activity.
- Aggregator input record. Which source systems were added to the aggregator, when, and how (API connection, CSV upload, address watch).
- Aggregator output snapshot. The version of the software, the run date, the gain/loss totals, the ordinary-income totals, the draft Form 8949 line counts.
- Sample disposition check. A material sample of dispositions traced from source records to aggregator output, with discrepancies flagged.
- Transfer-matching review. A workpaper that ties withdrawal events on one platform to deposit events on another so the same property does not appear as two separate sales.
- Unsupported-event log. Every transaction the aggregator flagged as unsupported, with a per-event treatment decision.
- 1099-DA reconciliation. Where applicable, a side-by-side of 1099-DA gross proceeds against the aggregator’s proceeds total, with explanation for any difference.
- Methodology memo. The lot-identification method, the fee-allocation rules, the basis sources, and the per-protocol treatment decisions.
- Corrected ledger. The reconciled ledger that produces the corrected Form 8949, Schedule D, and any Schedule 1 or Schedule C entries.
- Exception list. Every software output line that was rejected, with the reason and the supporting evidence.
| Failure mode | Reconciliation workpaper |
|---|---|
| Missing wallet or chain | inventory delta, source records for the missed activity, corrected disposition and income totals |
| Duplicate transfer counted as sale | transfer-matching log with paired withdrawal / deposit transaction IDs, corrected basis preservation, corrected Form 8949 |
| Unsupported DeFi or NFT event | per-event treatment memo with protocol mechanics, corrected income/disposition treatment, basis flow |
| Stablecoin swap dropped | swap event log, treatment memo citing exchange-as-disposition framing, corrected Form 8949 |
| Fee allocation error | sample-based fee audit, corrected basis and proceeds, methodology memo |
| 1099-DA / aggregator mismatch | side-by-side reconciliation, supporting records for the taxpayer’s position, corrected schedules |
| Version-change drift | prior run snapshot, current run snapshot, delta analysis, methodology memo for the change |
Multi-year considerations
Software-output errors compound across years. A missed wallet in year one means dispositions in year two of units from that wallet may carry the wrong basis or wrong holding period. A duplicate-transfer error in year one can create phantom basis lots that the software then uses for dispositions in year two. A reconciliation that fixes year one without checking year two is incomplete.
The amended-return file should walk the basis schedule forward through every later year, document the carryforward effects, and confirm that the corrected position is consistent across the years still open for amendment under 26 USC 6501 and 26 USC 6511.
What to upload for a software-output reconciliation review
Upload the documents that allow a practitioner to evaluate the software output against the actual records:
- the originally filed federal return for each year at issue, and any prior amendments
- the crypto tax software output (PDF, CSV, or screenshot of the gain/loss totals and draft Form 8949)
- the software’s exception or error report if one was produced
- exchange account CSV exports for every custodial account touched
- on-chain transaction logs or block-explorer references for self-custody wallets
- a list of self-custody wallet addresses with the chains they hold
- DeFi protocol histories, NFT marketplace records, bridge transactions
- 1099-DA, 1099-B, 1099-MISC, or other information returns issued by exchanges
- fiat on-ramp and off-ramp records (bank statements, wires, exchange deposits)
- prior basis schedules or methodology notes from other professionals
- any documentation of software version changes between runs
Pre-contact reconciliation is the focus of the software-output review
The amended-return review should produce a reconciled ledger before any Form 1040-X is filed. The output is the corrected return position plus the workpaper file that defends it on review. The methodology memo is what makes the position supportable; the software output is part of the evidence trail, not the conclusion.
Next step: request a digital-asset software-output reconciliation review
Upload the original return, the crypto tax software output, the source records (exchange exports, on-chain logs, fiat records), and any 1099-DA forms through the secure intake process for a digital-asset software-output reconciliation review. The review will identify the failure modes in the software output, build the reconciliation workpaper, document the methodology, and produce the corrected ledger before filing Form 1040-X.
Sources checked: IRS, Digital assets; IRS Notice 2014-21, Treatment of virtual currency; IRS Revenue Ruling 2023-14, Staking rewards; IRS Revenue Procedure 2024-28, Safe harbor for digital assets; IRS, File an amended return; IRS, About Form 1040-X; IRS, Form 8949; IRS, Form 1099-DA; 26 USC 1001, determination of amount of and recognition of gain or loss; 26 USC 1012, basis of property – cost; 26 USC 6045, returns of brokers; 26 USC 6501, limitations on assessment and collection; 26 USC 6511, limitations on credit or refund; Treas. Reg. 1.6045-1, gross proceeds and basis reporting by brokers (final, July 2024).
By Noah Green CPA CFE – published via the Sheepdog Tax digital-asset amendment review content lane (NGO).