Original topic illustration: ChainView BTC866 original topic diagram · ChainView BTC866 Editorial · CC BY 4.0
Establish the concept
Preserve original CSV exports unchanged before making a cleaning copy. Record provider, account scope, export time, date range, time zone, and column definitions. A platform may default to spot activity, recent dates, or selected subaccounts; a complete-looking filename does not establish complete history. Save file hashes and export instructions so later reviewers can distinguish a revised source export from changes introduced by local processing.
Map exported columns to a standard model while retaining original fields in additional columns. Record every discarded or transformed value. A trade ID that looks unique can be scoped only to one provider or account, so include that scope in a deduplication key. The goal is a traceable conversion, not a new table that has forgotten how each row was produced.
Choose reliable evidence
Deduplicate with stable trade identifiers, transaction hashes, event types, and account references rather than only amount and timestamp. Partial fills can legitimately share a second and price, while fees can occupy separate rows. Aggressive merging can remove real events. For overlapping exports, preserve source line numbers and the deduplication rule. Conflicting rows belong in a review queue instead of being silently discarded because they do not fit an expected total.
Use boundary examples for midnight and daylight-saving conversions. Check that one trade is not assigned to two reporting days or omitted when a local clock repeats an hour. Keep original timestamp strings so parser errors can be investigated. An unknown time zone should remain unresolved rather than silently receiving the machine's local setting.
Check concrete fields
Convert to UTC while retaining the original timestamp text and its time zone. Trade time, settlement time, and export time are not interchangeable. Ambiguous daylight-saving hours or dates without a zone require source clarification. Locale-specific commas, decimal points, negative signs, and parentheses also affect numeric interpretation. Compare imported samples with the original account display so that one thousand is not mistaken for one point zero zero zero or a fee sign reversed.
Reconstruct partial fills and cancellations through the order-event chain, not by treating remaining quantity as a second purchase. Fees can be allocated across fills or posted separately. Follow the provider's description and retain links between a fee row and the underlying execution. A neat daily total produced by merging these rows may be less accurate than a visibly multi-line but auditable record.
Handle boundary cases
Deposits, withdrawals, internal transfers, trades, rewards, fees, and failed transactions follow different accounting paths. Treating every incoming movement as a purchase or every failed transaction as costless can distort results. A reverted business action can still incur network fees. Cross-platform transfers need linked outgoing and incoming records plus fees. Keep valuation currency and price sources separate, because quantity reconciliation should not depend on a market value that conceals a missing movement.
If opening balance comes from a screenshot rather than an export, label its evidence quality. An on-chain balance and a platform's customer liability can also be different layers. Never add an unexplained difference to an income category just to make the accounting equation balance. Preserve the discrepancy and investigate missing history, account scope, or a unit conversion instead.
Keep results and versions
For each asset, reconcile opening balance plus inflows minus outflows to closing balance, then review event classifications and fees. Classify differences as missing, duplicated, timing-related, unit-related, or unresolved, with evidence and a reviewer. Do not fabricate a balancing trade. A final report should include source-file inventory, method version, and unresolved items. Supply originals alongside summaries to an adviser. This process makes the same financial movements reproducible even after changing software, rather than requiring fresh trust in each new dashboard.
Keep processing-script version, text encoding, and decimal rules with the report. A future rerun should reproduce the result from the same source. When an anomaly appears, retain the original and processing log before changing a rule. Do not overwrite the historical output without versioning; otherwise nobody can explain which parser or classification created an earlier statement that was already shared.
