GuideEducational · not tax advice

Missing cost basis in crypto tax software

What the warning means, why it inflates a reported gain, and a source-backed way to find the real cause before you change a single row.

Sources last checked 2026-07-19.

Most crypto tax tools raise a “missing cost basis” or “missing purchase history” warning when they see you dispose of more units of an asset than the imported history ever acquired. In other words: the file records a sell, send or trade, but not the earlier buy, deposit or reward that put those units in your account.

Koinly frames it exactly this way — it defines missing purchase history as disposing of more units than your imported acquisitions support (Koinly, “Missing purchase history for XYZ”). The warning is a data problem to diagnose, not a number to overwrite.

Why it inflates a reported gain

The consequence matters. Koinly documents that when an acquisition is missing, the disposed units are treated as having zero cost basis — which increases the reported gain on that disposal (Koinly, “Missing purchase history for XYZ”, accessed 2026-07-18).

That is a tool behaviour, not a universal rule of tax law, and it is why a missing-basis warning is worth taking seriously: left uncorrected it can overstate a gain, and papered over with an invented number it can understate one. Both are wrong for the same reason — the underlying history is incomplete.

The warning is not the same as zero basis

It helps to separate two things the tools blur together. A “missing cost basis” warning is a completeness signal: the tool has matched a disposal to no acquisition. Zero basis is different — it is a number a tool substitutes in place of the acquisition it could not find. Koinly documents treating a missing acquisition as zero cost basis, which increases the reported gain on that disposal.

The distinction matters because the IRS treats a digital asset as property, and the Form 8949 instructions explain that the basis of property you buy is usually its cost, including the purchase price and costs of purchase such as commissions. So a real acquisition has a real basis to recover; zero is a placeholder for a gap, not the true figure. The warning is asking you to find the acquisition — not to accept zero or type a number in its place.

Source: Koinly: Missing purchase history for XYZ; IRS: Instructions for Form 8949.

A transfer between your own wallets is not a disposal

When one leg of a self-transfer is missing, the surviving leg can read as a disposal with no basis. The IRS FAQ on virtual currency is explicit that moving virtual currency from a wallet, address or account belonging to you to another that also belongs to you is a non-taxable event — even if an exchange or platform sends you an information return because of the transfer (Q38). So the fix is to pair the two legs from your own records, not to invent a basis for a “sale” that never happened.

Fees deserve the same care. The Form 8949 instructions note that the basis of property you buy usually includes costs of purchase such as commissions, so a purchase fee can belong in basis rather than being deleted on sight. Koinly separately documents double-counted fees as a cause of a missing-history warning; confirm how the source records a fee before you remove a row, so you neither double-count it nor erase it.

Source: IRS: Frequently Asked Questions on Virtual Currency Transactions; IRS: Instructions for Form 8949; Koinly: Missing purchase history for XYZ.

What good records look like — and how to rebuild them

The IRS FAQ describes the records the rules expect for identifying units: either a unit’s unique digital identifier — such as a private key, public key and address — or records that show, for the units of a given asset held in one account or wallet, the date and time each unit was acquired, your basis and its fair market value at acquisition, the date and time it was disposed of, and the fair market value and proceeds at disposition (Q40).

That is the target a reconstruction aims at. Gather original exchange statements, on-chain history and platform records; rebuild missing acquisitions from those sources and import them rather than typing a figure to silence the warning. If the evidence cannot establish the transaction history or basis, preserve the gap and take the records to a qualified professional instead of guessing.

Source: IRS: Frequently Asked Questions on Virtual Currency Transactions.

Specific identification has a substantiation limit; otherwise FIFO

Lot selection is not a free choice. The IRS FAQ says you may choose which units are deemed sold, exchanged or disposed of only if you can specifically identify the units involved and substantiate your basis in them (Q39), and it sets out the identifying records that support that choice (Q40).

The limit is the substantiation. If those records do not exist, specific identification is not available, and the FAQ states that units are then deemed disposed of in chronological order, earliest first — on a first in, first out (FIFO) basis (Q41). The validator checks a file’s structure; it does not create the substantiation a specific-identification method requires, and it does not choose a lot-selection method for you.

Source: IRS: Frequently Asked Questions on Virtual Currency Transactions.

A Form 8949 or 1099-DA does not complete an incomplete history

Capital gains and losses from digital-asset dispositions are reported on Form 8949 and summarised on Schedule D (Q43), and the Form 8949 instructions add dedicated boxes (G–L) for digital-asset transactions and direct that you report sales and exchanges of capital assets — including digital assets — even if you did not receive a Form 1099-B or Form 1099-DA. The FAQ adds that you must report regardless of whether an information return arrives (Q42).

A Form 8949 or 1099-DA does not make incomplete records complete. The 2025 Form 8949 instructions contain dedicated digital-asset boxes and basis fields, but they also direct reporting even when no Form 1099-DA arrives. Compare any information return with your own acquisition and disposition records. Forms and instructions vary by tax year; confirm the version that applies on the IRS site, or with a qualified professional, before filing.

Source: IRS: About Form 8949, Sales and other Dispositions of Capital Assets; IRS: About Form 1099-DA, Digital Asset Proceeds From Broker Transactions; IRS: Instructions for Form 8949; IRS: Frequently Asked Questions on Virtual Currency Transactions; IRS: Digital assets.

Find the real cause

Work through each cause in turn. For every branch: read the symptom, find the offending rows, then verify against the real source before you change anything.

Missing acquisition history or a gap between years

Symptom. The warning names an asset you genuinely bought earlier, and the earliest transaction in the file is already a sell, send or trade of it.

Diagnose. Sort the asset's rows by time and look at the first one. If the first event disposes of units, the acquisitions that came before your import window are simply absent.

Verify before you correct. Confirm the real acquisition from the original exchange statement or an on-chain explorer, and import that historical activity from the source rather than typing an amount to silence the warning.

Source: Koinly: Missing purchase history for XYZ.

Duplicate transactions that evade automatic detection

Symptom. Balances look too high, or the same buy appears twice with a slightly different timestamp, rounding or source.

Diagnose. Look for pairs that describe the same real event. Koinly documents that its duplicate detector only catches sufficiently exact matches and can miss duplicates when you mix API and CSV imports, import trade and order files for the same activity, or have different rounding or timestamps.

Verify before you correct. Confirm which single import is authoritative for that period before deleting anything, so you remove the copy and not the only record of a real transaction.

Source: Koinly: How duplicate detection works in Koinly.

Timezone-naive timestamps imported in the wrong zone

Symptom. A disposal appears to happen before the matching acquisition, or a transaction lands in the wrong tax year around a year boundary.

Diagnose. Check whether the file states a timezone at all. Koinly documents that if a file does not identify its timezone it is assumed to be UTC, and you must choose the source timezone during import.

Verify before you correct. Confirm the exchange's export timezone from its own documentation and re-import with that zone set, rather than editing individual timestamps by hand.

Source: Koinly: CSV import timestamps are not in UTC timezone; Koinly: How to modify CSV files to import them to Koinly.

Missing airdrops, forks or reward income

Symptom. You hold or sold units that never had a corresponding buy — they arrived as an airdrop, fork, staking reward or bonus that was never imported.

Diagnose. Trace the unexplained units back to when they first appeared in the wallet. Koinly lists missing airdrops, forks and bonuses as a documented cause of missing purchase history.

Verify before you correct. Confirm the receipt on-chain or from the platform record and import it as the correct income/reward type, so the units have an origin instead of a phantom disposal.

Source: Koinly: Missing purchase history for XYZ.

Double-counted or mis-typed fees

Symptom. A tiny residual balance goes negative, or fees appear both inside a trade and again as a separate row.

Diagnose. Check whether the same fee is represented twice. Koinly lists double-counted fees as a documented cause of missing purchase history.

Verify before you correct. Confirm how the source records the fee before removing a row, so you do not delete a fee the platform expects to see.

Source: Koinly: Missing purchase history for XYZ.

Unnecessary manual transactions

Symptom. Hand-entered rows added to 'balance' the account are themselves creating the negative inventory.

Diagnose. Review any manually created transactions. Koinly lists unnecessary manual transactions as a documented cause of missing purchase history.

Verify before you correct. Confirm each manual row against a real source event and remove ones that were invented to force a balance, rather than layering another manual row on top.

Source: Koinly: Missing purchase history for XYZ.

Unmatched internal transfers between your own accounts

Symptom. A withdrawal from one wallet and the matching deposit into another are not paired, so one side reads as a disposal with no basis.

Diagnose. Look for a withdrawal and a deposit of the same asset and amount, close in time, on two accounts you control. If the pair is not matched, the software treats the two legs as unrelated.

Verify before you correct. Confirm both legs describe one real movement before tagging them as a transfer, so you do not merge two genuinely separate transactions.

Source: Koinly: Missing purchase history for XYZ.

Verify before you correct — every time

When to get a professional

This guide is educational and is not tax, legal or accounting advice. It explains how the software behaves and how to trace a data problem — it does not tell you what any transaction means for your own return.

If the history is large or spans several years, involves DeFi, NFTs or lost records, or you are unsure how a correction should be reported, consult a qualified tax professional or accountant. Bring the diagnosed data and the sources you verified against, not a guess.

Questions people ask

What does “missing cost basis” actually mean?

It means the tool found a disposal — a sell, send or trade — without an earlier acquisition to match it against. Koinly defines it as disposing of more units than your imported history acquired. It is a sign that some earlier buy, deposit, reward or transfer leg is missing or mis-recorded, not a figure you are meant to type in.

Does a missing acquisition really default to zero basis?

Koinly documents that a missing acquisition is treated as zero cost basis, which increases the reported gain on that disposal. That is how that tool behaves; other tools may differ. Treat it as a reason to find the real acquisition, not a number to accept.

How can two identical-looking transactions both survive as duplicates?

Koinly documents that its duplicate detector only catches sufficiently exact matches, and can miss duplicates when you mix API and CSV imports, import trade and order files covering the same activity, or have different rounding or timestamps. Two records of one real event can look different enough to slip through.

Should I just edit the timestamps to fix the ordering?

Not by hand, one row at a time. Koinly documents that a file with no stated timezone is assumed to be UTC and that you choose the source timezone during import. Confirm the exchange's export timezone and re-import with that setting, rather than nudging individual times until the order looks right.

Is this tax advice?

No. This is an educational explanation of how crypto tax software behaves and how to trace a data problem to its cause. It is not tax, legal or accounting advice. For how a correction should be reported on your return, consult a qualified tax professional.

Sources

Direct official pages, each checked on the date shown.

Read this

Educational only — not tax, legal or accounting advice, and not a substitute for a qualified professional.

Vendor behaviour and documentation change over time. Every claim here is attributed to a dated official source; check the linked page for the current wording before you rely on it.