Reading Exchange Statements Without Inventing Facts

Every export carries a clock. Some use UTC, some use the user's local time at export, some use UNIX epoch, and a few use whichever the engineer reached for first. Combining them without normalisation produces a timeline that looks neat and is wrong, often by a full calendar day on either side of a withdrawal. The first job is to convert everything to a single reference, usually ISO 8601 UTC, and to record what the original value was before the conversion.

Where a block timestamp can be matched against a withdrawal entry, that match is documented as a verified finding. Where the venue's clock and the chain disagree by more than the network's confirmation window, the variance is recorded as such — not adjusted, not smoothed, not blamed on the user. A statement is allowed to be slightly wrong about time; it is not allowed to be silently corrected.

Trading fees behave differently across venues. Some deduct from the asset received, some from a separate balance, some from a held token denominated in the platform's own coin, and some show a gross amount that includes the fee while others show the same trade net. Adding rows from two such venues without identifying the convention will inflate one balance and deflate another, and the spreadsheet will look internally consistent the entire time.

Each fee deduction is recorded with the asset it was charged in, the time it was charged, and whether the line reflects gross or net of fee. Where the export is ambiguous, the line is classified as ambiguous rather than resolved — a small admission that prevents a larger correction later.

Token tickers are not universal identifiers. The same three letters can refer to two different contracts on two different networks, and migrations and rebrands routinely leave a venue's history showing one symbol for what is now a different asset. Equally common: an export uses a wrapped representation while the chain shows the underlying, or vice versa.

Symbols are mapped to the specific contract or asset reference the venue actually credited at the time. Inverted pairs are recalculated to the directional flow that occurred. Where the venue's symbol cannot be tied to a specific underlying, the entry is held in a separate column rather than guessed.

Many statements record movements between sub-accounts of the same venue using the same row format as on-chain withdrawals. Read literally, the file shows assets leaving the platform when in fact they never did. The clue is usually the absence of a transaction hash, but the export will not always announce that helpfully — it will simply leave the field blank.

Lines without a verifiable on-chain identifier are classified as internal movements until a hash is produced. Tracing them externally before that point produces false alarms and wasted reviewer time, both of which are easier to avoid than to apologise for.

A withdrawal row in a statement records that the platform accepted a request, not that the network settled it. Settlement requires a hash, a destination address, a block confirmation and a matching credit on the receiving side. Where any of those is missing, the withdrawal is described as initiated rather than completed, with a short note explaining which piece is absent.

Where all four match, the transfer is documented as record-backed end to end. The point is not pedantry; it is that the difference between requested and settled occasionally matters, and the file should not have to be re-read later to find out which one it claimed.