Crypto trade recordkeeping is the practice of exporting exchange activity (fills, orders, positions, transfers) into a structured post-trade log so you can measure PnL, fees, and funding accurately, catch missing data through reconciliation, and fix recurring execution mistakes before they compound.
What Crypto Trade Recordkeeping Actually Requires
Crypto trade recordkeeping means systematically exporting, normalizing, and reconciling four layers of exchange data (orders, fills, positions, and transfers) into a unified log with standardized fields, so that every closed trade can be reconstructed from raw source files and every balance discrepancy can be traced to a specific missing record.
Most traders treat recordkeeping as an end-of-year chore, exporting one bulk CSV and hoping the numbers line up. That approach fails because exchanges limit export windows (often 90 days or 1,000 rows), column labels differ between platforms, and critical data like funding payments often lives in separate tabs. A working system exports regularly, normalizes immediately, and reconciles weekly. The payoff is accurate analytics, faster post-trade reviews, and no data gaps when you need historical records.
Three principles define effective recordkeeping:
Immutability of raw exports. Never edit original CSV files. They are your audit trail. Clean records also make it straightforward to identify tax-loss harvesting opportunities at year-end.
Normalization into a single schema. Different exchanges use different column names, symbol formats, and timestamp conventions. One master format makes cross-platform comparison possible.
Regular reconciliation. Your account balance change must equal Trading PnL minus Fees plus Funding Net plus/minus Deposits and Withdrawals. If it does not, something is missing.
The Four Data Layers: Orders, Fills, Positions, Transfers
Understanding these four layers prevents the most common analytics corruption: conflating intent with execution.
Across our platform, users who download their trade history monthly and store it in a consistent format avoid the most common recordkeeping failure: discovering at tax time that exchange export formats changed mid-year or that data older than a certain period requires a support request.
Orders represent intent. An order has an ID, timestamp, symbol, side, quantity, and price. It can be filled, partially filled, or cancelled entirely. Your order book interaction creates the order, but the order alone tells you nothing about what actually executed.
Fills (executions) record what happened. A single order can generate multiple fills at different prices. Each fill carries a trade ID, fill quantity, fill price, liquidity type (maker or taker), and fee amount in the fee asset. Fills are the authoritative source for cost basis and realized PnL.
Positions exist primarily for perpetual futures. They track open exposure: entry price, leverage, margin mode (cross or isolated), unrealized PnL, realized PnL on close, liquidation price, and cumulative funding rates paid or received.
Transfers cover deposits, withdrawals, and internal sub-account moves. They include TxID, network fees, and direction. Transfers explain balance changes unrelated to trading and are essential for reconciliation.
The mental model: Intent (plan) then Order (submitted) then Fills (executed) then Position/PnL updates then Transfers (net flow). Treating orders as fills misses partial executions. Ignoring transfers makes your balance irreconcilable.
Orders vs Fills: The Confusion That Breaks Analytics
One order can produce multiple fills. If you place a limit order for 1 BTC and it executes in three chunks at slightly different prices, your order history shows one "filled" order. Your trade history shows three separate fills with three timestamps, three prices, and three fee calculations.
Your average fill price comes from weighting each fill by quantity. Your fee structure depends on whether each fill was maker (0.02% on major exchanges) or taker (0.05-0.10%). Across hundreds of trades, this difference compounds into real money.
If you base your log on orders alone, you lose the exact execution timestamp per fill, the precise price at which each unit was acquired, and the fee type and amount per fill. The result: wrong cost basis, wrong PnL, wrong trade journal entries. A trader running 200 fills per week who logs only orders will accumulate basis errors of $50-$200 monthly on moderate volume.
I spent my first three months logging orders instead of fills and could not figure out why my spreadsheet PnL consistently diverged from my exchange balance by 2-4%. The answer was partial fills at different prices that the order view aggregated away.
Export Checklist: What to Download and How Often
For complete analytics, you need four export categories at regular intervals. Exchanges label these differently ("Trade History," "Fills," "Execution," "Income"), so verify exact column names in your exchange UI.
Spot exports: Trade/fill history (timestamp, pair, side, quantity, price, fee, fee asset, trade ID), order history (order ID, status, original quantity vs filled quantity), and deposit/withdrawal history (TxID, network, amount, asset, timestamp, status).
Perpetuals exports: Everything above plus funding history (timestamp, symbol, funding rate, payment amount, position size at time of payment), position history (entry price, exit price, leverage, margin mode, realized PnL), and any liquidation or ADL events.
Export frequency by trading volume:
High volume (50+ trades/week): export every 2-3 days
Intermediate (10-50 trades/week): export weekly
Low volume (under 10 trades/week): export monthly, never skip after a volatile week
Immediate export triggers: liquidation or near-liquidation (mark price within 2% of liquidation), large slippage (execution deviated more than 0.5% from expected), exchange outages or security events, ADL events, and before any account restructuring (closing sub-accounts, changing margin modes).
The Non-Negotiable Fields Your Log Must Contain
A standardized trade log lets you compare performance across exchanges, time periods, and strategies. Seven fields are non-negotiable for every fill:
1. Timestamp (UTC, ISO 8601 format)
2. Symbol (normalized: BTC-USDT, not BTCUSDT or BTC/USDT)
3. Side/Direction (buy, sell, long open, long close, short open, short close)
4. Quantity (base asset units)
5. Price (fill price, not order price)
6. Fee amount + fee asset (kept in original form; convert to quote currency only in a derived column)
7. Trade/Order ID (stable identifier for deduplication)
For perpetuals, add: leverage, margin mode, liquidation price, funding paid/received per interval, and realized PnL on close.
Optional fields that become powerful with scale: strategy tag, setup tag (breakout, support bounce, trend analysis continuation), mistake tag, R-multiple, time in trade, and slippage from expected entry.
Normalization: Making Different Exchange Exports Comparable
Raw exports from different exchanges use different conventions. Normalization creates a single dataset for unified analytics.
Symbol normalization: BTCUSDT becomes BTC-USDT. BTC/USDT becomes BTC-USDT. BTC-USDT-PERP becomes BTC-USDT with an account_type column set to "perps."
Timestamp normalization: Convert all timestamps to UTC ISO 8601. Store the original timestamp in a separate column. Document your conversion rule per exchange.
Fee field mapping: Keep fee amount and fee asset as separate columns. Convert to quote currency only in a derived column using historical fair market value from a price API (source: CoinGecko). Never overwrite raw fee data.
Common normalization traps:
Duplicates (same fill appearing twice): match on Trade ID before importing. If Trade IDs are missing, match on Timestamp + Symbol + Side + Quantity + Price.
Reversed sign conventions: standardize so longs that profit = positive, longs that lose = negative.
Funding in separate tables: perps funding often exports from an "Income" or "Funding" tab, not "Trade History." Merge using Timestamp and Symbol as keys.
Date-range limits: exchanges often cap at 90 days or 1,000 rows. Overlap exports by one day to catch boundary trades. Verify row counts against expected volume.
Reconciliation: Catching Missing Data Before It Corrupts Analytics
Reconciliation verifies that your records account for every dollar that moved. Without it, you cannot trust any performance metric downstream.
Core formula: Net Account Change = Trading PnL - Fees + Funding Net +/- Deposits/Withdrawals
If your account balance change does not match this formula within 0.1% tolerance, something is missing.
Troubleshooting sequence:
1. Check for missing fees (compare total fees to Fee% x Gross Volume)
2. Check for unrecorded funding (compare net funding export to sum in your log)
3. Check for missed transfers (match deposit/withdrawal records to balance changes)
4. Check for sub-account internal moves logged as external
5. Compare your fill count to the exchange's "total trades" statistic
In practice, on a derivatives exchange, the most common reconciliation gap comes from funding payments that live in a separate export tab from trade history, and traders who merge both sources early avoid the largest class of balance mismatches.
Sub-account verification: If you use separate sub-accounts for spot, perps, and different strategies, each needs its own exports. Internal transfers between sub-accounts must be logged as "internal transfer," not trading activity.
Organization System: Folder Structure and File Naming
A consistent system makes records searchable at any scale. This structure handles 10 trades or 10,000.
/TradingRecords/
/Exports/{Exchange}/{Spot|Perps}/{Year}/{Year-Month}/
/Normalized/master_trades_{year}.csv, master_funding_{year}.csv
/Reviews/Weekly/{Year-WXX}/
File naming pattern: {exchange}{account}{exporttype}_{YYYY-MM-DD_to_YYYY-MM-DD}_v01.csv
Examples: binance_perp_fills_2025-03-01_to_2025-03-07_v01.csv, blofin_spot_orders_2025-03-01_to_2025-03-07_v01.csv
Versioning: If you re-export the same date range, increment to _v02.csv. Document why in a changelog.
Immutability rule: Raw exports in /Exports/ are never edited. The /Normalized/ master sheet incorporates corrections and derived columns. Weekly review folders contain point-in-time snapshots so historical analysis remains valid.
Weekly Review Dashboard: Turning Records Into Behavior Change
Records only improve your trading if you review them systematically. A weekly review converts raw data into pattern recognition.
Core metrics to calculate weekly:
Win rate (fills that closed profitable vs total closed)
Average winner vs average loser (the ratio matters more than win rate)
Total fees paid as percentage of gross PnL
Largest single loss (did it exceed your position sizing rules?)
Number of mistake-tagged trades
Perps-specific metrics:
Funding drag per position (which positions bleed the most?)
Average time in position (longer = more funding exposure)
Liquidation distance at entry (how much buffer did you have?)
Mistake tags (fixed taxonomy, 8-12 tags): FOMO entry, oversized position, moved stop, no stop placed, revenge trade, ignored signal, early exit, late exit, wrong pair, news reaction. Consistency enables filtering and trend analysis across weeks.
Automation Options: CSV vs API vs Portfolio Trackers
Three approaches exist for maintaining records. Each has tradeoffs in setup effort, security, and completeness.
Manual CSV exports: Download directly from your exchange. Full control, no API key risk, complete audit trail. Best for low-to-moderate volume traders who value data ownership.
Read-only API: Libraries like CCXT (source: Ccxt) pull fills programmatically. Always use read-only keys with zero trading or withdrawal permissions. Store keys encrypted, never in plaintext. Best for high-volume traders where manual export becomes impractical.
Portfolio trackers: Services like CoinTracking import CSVs or connect via API and generate reports. However, user-reported accuracy issues include 10-15% error rates on perps funding calculations and inconsistent sub-account handling. Always maintain raw exports as backup regardless of tracker usage.
Security baseline: Read-only API keys only. Separate email per exchange. Encrypt CSV exports containing transaction details. Never share raw exports publicly. Rotate API keys quarterly.
Frequently Asked Questions
Do I need both order history and trade/fill history?
Yes. Orders show intent and cancellations, revealing your fill rate (typically 70-90% on limit orders). Fills show actual executions with exact timestamps, prices, and fees. Basing your log on orders alone misses partial fills entirely. If an order fills in three chunks at different prices, the order view shows one entry; the fill view shows three distinct records with three cost bases. Use fills as the authoritative source for all PnL and analytics calculations.
Why does my spreadsheet PnL differ from the exchange PnL widget?
Exchange PnL widgets routinely exclude fees, funding payments, or transfers. Some use mark price instead of your actual close price. Others aggregate funding into trading PnL without distinguishing the components. Your manual calculation from fills plus funding plus fees minus transfers will always be more accurate for performance analysis because you control the methodology and can verify every input against raw exports.
What is the minimum export set for spot-only traders?
Three exports cover spot trading completely: trade/fill history (timestamps, prices, quantities, fees per fill), order history (for fill-rate analysis and cancelled order tracking), and deposit/withdrawal history (for reconciliation). Optional but recommended: periodic balance snapshots to cross-check your reconciliation formula. If your ending balance minus calculated net PnL differs from net deposits minus net withdrawals by more than 0.1%, you have a data gap that needs investigation before it compounds.
How do I handle fees paid in exchange tokens like BNB or OKB?
Record the fee asset and fee amount in their original form in your raw log. Create a separate derived column that converts to your quote currency (USDT or USD) using the historical price at the fill timestamp. Never overwrite the raw fee data, because the original preserves full fidelity for audit purposes. The conversion itself may constitute a taxable disposal depending on jurisdiction, making the raw record essential for tax reporting.
What happens if I miss an export window and lose data?
Most exchanges retain 90-180 days of downloadable history, and API access sometimes extends further. If data is permanently lost, contact exchange support for account statements. For prevention, set calendar reminders aligned to your export frequency and overlap each export by one day to catch boundary trades. The cost of one missed week is hours of manual reconstruction and permanent gaps that make pattern recognition unreliable.
Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include BloFin exchange documentation (export formats, sub-account structures, funding history endpoints); CoinGecko historical price API for fair market value normalization CoinGecko; CCXT unified exchange library documentation Ccxt; Investopedia guide to crypto recordkeeping best practices (Investopedia, https://www.investopedia.com/cryptocurrency-record-keeping-5221187). All facts independently verified against cited documentation current as of April 2026.
This article is for informational purposes only and does not constitute financial advice. Cryptocurrency trading involves substantial risk of loss. Past performance does not guarantee future results. Always conduct your own research and consider your financial situation before trading. BloFin does not guarantee the accuracy of third-party data referenced herein.