A missing basis figure is rarely one missing number. It is usually one account you cannot log into, one export that stops in 2019, and a transfer whose history did not travel with the coins.
The work is recoverable, and most of it is bookkeeping: pull the records that still exist, say what each one proves, and write down what nothing in the file proves yet.
The evidence hierarchy below is a practitioner's method, not agency doctrine. A bank deposit is not automatically the cost of an executed trade, and a wallet movement does not establish an off-chain purchase price. Recovering evidence after the fact is a different thing from retroactively inventing a lot election you never made.
What each surviving record can prove
The task in front of you is narrower than the panic suggests: for each purchase lot with a missing or wrong number, gather the records that show what you paid, then label what those records leave open.
The 2025 Instructions for Form 8949 place that duty on you (current figure at the IRS).
Keep accurate records showing the basis of your property, and for a digital asset, basis is the cost to acquire it, including transaction fees, commissions, transfer taxes, and other acquisition costs.
Those instructions also suggest contacting your broker when basis records are lost. They go no further: no crypto-specific reconstruction method, no estimation safe harbor.
What fills that space in practice is professional method.
Camuso CPA's published approach sorts evidence into tiers, starting with recovered platform history and verified on-chain data, then correspondence and payment records, then whatever contemporaneous notes you kept.
A blank basis box is not proof that a coin cost you nothing.
It reports what the broker knows, which is a separate question from what you paid, so check what a blank or zero basis row means before you treat the gap as a tax result.
Evidence comparison, following Camuso CPA's professional reconstruction approach (retrieved September 26, 2026).
| Record | Strength for this purchase | What it supports | What it does not establish | Source basis |
|---|---|---|---|---|
| Exchange trade export and account deposit/withdrawal logs | Strongest where the export covers the acquisition date and the account matches | Execution date, quantity, consideration and fees on the platform's own ledger | Activity outside the export's date range, or a lot that arrived from another platform | Recovered primary history, first tier |
| Trade email or OTC confirmation | Strong where it names the same account and transaction reference | Quantity, price, counterparty and time as agreed | That the trade settled exactly as written, absent a matching payment or ledger entry | Secondary evidence, second tier |
| Bank or card record | Supporting; it dates and sizes a payment | Funds leaving your account to a named recipient on a stated date | The executed trade, the quantity acquired, or the split between price and fees | Secondary evidence, second tier |
| Verified-wallet on-chain record | Strong for custody and timing, limited for cost | Asset amount, movement, block timing, wallet control once verified | Off-chain purchase cost and the dollars you actually paid | Recovered primary history, first tier, with cost limits |
| Contemporaneous notes, spreadsheet, screenshot or documented estimate | Weakest alone, useful as corroboration for the rest | Your own record of events and the reasoning behind a figure | Cost by itself; it does not stand in for a payment or trade record | Corroboration, third tier |
Put two partial records together
When a payment and a confirmation survive but the platform history does not, those two records can carry one lot between them. The bank side dates and sizes money leaving your account. The confirmation side ties a quantity to a consideration and names the fee.
Neither one does the other's job, and the acquisition-cost definition in the Form 8949 instructions is what tells you the fee belongs inside the figure rather than beside it.
Annotated partial-record example (schematic, not market data)
- Record A, observed: a bank debit of amount D, posted on a statement date, payable to the exchange. It shows a payment and a recipient.
- Record B, observed: a saved trade confirmation showing quantity Q, acquisition consideration P, and a separately identified acquisition fee F, carrying the same account ID and transaction reference.
- Calculated: proposed basis for this lot = P + F.
- Reconciliation: treat D as support for P + F only when the records actually link them, by transaction reference, by date, or by an account ledger line. If D is larger than P + F, that difference is an open item, not a second fee.
- Still missing: any platform ledger entry confirming settlement of Q into this account, and the fee treatment if F is bundled rather than itemized.
- What a wallet receipt adds: it corroborates that Q later moved to a wallet you control. It cannot supply P.
The arithmetic here is instructional. It shows you how to express a proposed amount and where the trail stops, not what an examiner will accept.
Build one evidence file for each purchase lot
One lot, one file. That sounds fussy until the third time you re-derive the same figure because last month's version lived in a spreadsheet tab with no source names in it.
Evidence Checklist, per affected lot. Use the interactive Evidence Checklist on this page to capture the entries while you work, one pass per lot, saved under the lot reference before you start the next one. Every line names the relationship it establishes, so a line you leave blank is a stated open item rather than something you forgot.
- Identify the account and the lot: platform or wallet, account ID, acquisition date, quantity. This is what every later record has to match against.
- Collect surviving primary history: full or partial exports, deposit and withdrawal logs, API pulls. Keep the partial export exactly as downloaded; a truncated file still narrows the date range.
- Gather trade correspondence and payment evidence: confirmation emails, exchange support threads, OTC confirmations, the bank or card entry. Note which one supports the price and which supports only the payment.
- Match wallet movements: link on-chain transfers to the lot for custody and timing, and record that the cost still comes from elsewhere.
- Attach earlier filed schedules as corroboration where relevant: an old return can support what you reported and when. It is secondary corroboration, so keep looking for the underlying purchase evidence alongside it, and keep the number you once reported in a separate field from the proof of what you paid.
- Record the proposed figure and every assumption behind it, with the source filename or private reference for each input, plus record dates, quantity, acquisition amount and fee evidence.
- List unresolved links and the next record you are chasing, with who or where you asked.
When the original exchange or records are gone
Closed platform, dead login, support address bouncing. The standard of proof does not move; the menu of available sources does.
Search the archives you still control, in tier order: trade confirmation emails, any correspondence with the exchange, bank and card entries showing funds going out, OTC confirmations, exports you saved at the time, screenshots, your own dated notes, and transfers to wallets you can verify.
Each of those contributes something specific. Correspondence can pin a price and a time. A card entry sizes a payment.
A verified wallet movement shows the asset arriving under your control.
Nothing in that list recreates a platform ledger, and whether an institution can still retrieve an old statement or a closed-account record is an open input in your file until you have asked and written down the answer.
Holding coins across several platforms is where visibility breaks first, because no single export sees the whole chain of custody. Build the lot file per platform and connect the movements between them.
Check what the software used to fill the gap
"The software says missing, but I checked those transactions." Usually the flag is not about the transaction you checked. Open the proposed figure and look at what it references: the purchase record, the payment record, the fee, and the transfer in.
A flag clears when those references exist and agree, not when the transaction looks familiar.
Older wallets raise the same question in a different shape. Rather than asking whether every wallet you ever used belongs in the software, ask which original acquisition and which later movements support the lot you are currently pricing. Some archives matter for cost, others only for custody.
We found no universal rule limiting imports to the current year, so treat coverage as something you verify per account.
Keep a source record next to every manual correction. Picture a flag you clear by typing a figure you pulled from an email, then closing the email without noting the file name; six months later the number is in the return and the reason is gone. For choosing a product, evaluate crypto tax software against your documented record workflow rather than against a cleared-flag count.
Keep estimates and assumptions visible
An assumptions register is the part of Camuso CPA's method that survives handoff to another person. Five fields per entry: the source you used, what you observed in it, the inference you drew, the calculation you ran, and the gap still unresolved. A reader who disagrees with your inference can then argue with that one line instead of the whole figure.
As of 2026, the IRS material reviewed for this article sets out basis and recordkeeping duties without prescribing a crypto-specific missing-record hierarchy, an assumptions register, a historical-price estimate, or blanket acceptance of a "reasonable reconstruction."
The hierarchy and the register are the practitioner's method. Their weight on your return depends on that return and the evidence behind it.
So the honest answer to "does the IRS have to accept my best estimate" is that acceptance is not automatic in either direction. Neither a documented estimate nor a software result guarantees acceptance for a particular return. A documented estimate is still better than a blank, because it can be inspected.
If nothing survives for a lot, say so in the register and price the lot from the best evidence you do hold. A historical price chart tells you what the market did that day. It does not tell anyone what you paid for an off-chain purchase, and there is no approved formula that converts one into the other.
Check the file before choosing the next step
The file is done when three conditions hold for the lot: the proposed amount traces to named records, those records are retained where you can produce them, and the open issues are written out instead of remembered.
That last one is the test most files fail.
Cleaning up old records worries people who suspect an earlier year was wrong. Fixing your records is record work, and this article makes no prediction about what any year attracts.
If an earlier return omitted a disposition, check the next step for an earlier-return omission and keep that question separate from the evidence you are assembling now.
Bring in a CPA or an enrolled agent when there is a dispute, when custody changed hands in a complicated way, or when a gap is large enough to cost real money.
Never skip reporting a disposition because its basis is unresolved, and never fill the blank with a price you cannot source.
Once the lots are documented, match your documented purchases to a sale lot, and for the rest of this series, browse the 1099-DA guide index.
Build the checklist for one affected purchase first. Keep each proposed amount beside its source references and open questions, then repeat the same process for the next lot.
Sources
- IRS, Instructions for Form 8949 (2025), Cost or Other Basis: basis recordkeeping duty and digital-asset acquisition costs. Tax year 2025.
- Camuso CPA (professional analysis), "Crypto Cost Basis Missing Transaction History": evidence hierarchy, assumptions register, and the limits of on-chain records for off-chain cost.



