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.