One tricky case is when a withdrawal from a closing exchange and a deposit on another platform look like two separate transactions, even though they’re just two sides of the same transfer.
Say a client withdraws 2.4 ETH from BitMEX, pays a 0.003 ETH network fee, and receives 2.397 ETH in their own wallet before depositing it into another exchange. If the export from the first platform is missing, the receiving exchange might show an unexplained deposit with no original cost basis. Treating the withdrawal as a disposal and the deposit as a new acquisition could create a completely fictional gain.
I’d keep a transfer-matching ledger that links both sides using transaction hashes, timestamps, asset quantities, and destination addresses, while tracking fees separately. If the source record is missing, the match should remain provisional rather than silently inventing a cost basis.
The interesting question is what happens when the original exchange disappears before the match can be verified. Would you preserve that uncertainty explicitly in the accountant’s report, rather than forcing the reconciliation to balance?
Yes, I'd surface it. Forcing it to balance hides exactly what the accountant needs to know, which is that a piece of the history can't be checked anymore.
I'd split it in two. The transfer itself usually survives the exchange, because the withdrawal is on-chain. With the hash, the amount and the destination address you can still show that 2.397 ETH arrived in the client's wallet. What dies with the exchange is the other half, what the client paid for that ETH in the first place. So the match can be confirmed while the cost basis is still unknown, and I'd want the report to say those two things separately - transfer matched, cost basis missing because the source closed.
That's also why the checklist in the post asks where every withdrawal went.
The tricky part is that an on-chain match doesn't necessarily prove who owned the assets on either side. Take a client who withdraws 18.6 ETH from a failed exchange, pays a 0.012 ETH network fee, and sends the rest through a self-custody wallet before depositing it into an exchange that batches customer deposits. You might be able to trace the transaction hashes and reconcile the amounts, but the deposit address alone won't establish that the wallet belongs to the client or recover the original acquisition lots.
I'd keep transfer verification, wallet ownership evidence, and cost-basis provenance as separate fields. That way, even if the movement is fully traceable, the report can show exactly which part is supported by on-chain data and which part still depends on historical exchange records. Otherwise, a technically correct transfer match can still feed an unsupported cost basis into the gain calculation.
The question I'd be interested in is how you'd handle partial recovery of the old records, where some acquisition lots can be verified but the rest of the balance can't.
One tricky case is when a withdrawal from a closing exchange and a deposit on another platform look like two separate transactions, even though they’re just two sides of the same transfer.
Say a client withdraws 2.4 ETH from BitMEX, pays a 0.003 ETH network fee, and receives 2.397 ETH in their own wallet before depositing it into another exchange. If the export from the first platform is missing, the receiving exchange might show an unexplained deposit with no original cost basis. Treating the withdrawal as a disposal and the deposit as a new acquisition could create a completely fictional gain.
I’d keep a transfer-matching ledger that links both sides using transaction hashes, timestamps, asset quantities, and destination addresses, while tracking fees separately. If the source record is missing, the match should remain provisional rather than silently inventing a cost basis.
The interesting question is what happens when the original exchange disappears before the match can be verified. Would you preserve that uncertainty explicitly in the accountant’s report, rather than forcing the reconciliation to balance?