Exchange Trading Log Reconciliation

Exchange trading log reconciliation is the process of matching executed trade records from cryptocurrency exchanges against accounting entries in the crypto subledger to verify that every fill, fee, and settlement is accurately recorded before journal entries post to the general ledger. Each centralized exchange generates a trading log containing trade IDs, timestamps, trading pairs, prices, quantities, and fees - 8 fields per record that require normalization and systematic comparison across data sources. Organizations trading on 3 or more exchanges process 3 distinct trading log formats, each with different column names, timestamp precision, and fee structures.

What Is Exchange Trading Log Reconciliation?

Exchange trading log reconciliation is the systematic comparison of exchange-reported trade execution records against crypto subledger accounting entries to verify completeness, accuracy, and proper fee allocation for every executed trade. The trading log is the authoritative record of execution price, quantity, and fees - the raw data that determines cost basis for every acquired asset.

Trading log reconciliation differs from other reconciliation types in 3 ways listed below.

1. Deterministic matching key - Each exchange assigns a unique trade ID to every executed fill, providing a deterministic matching key that eliminates the need for probabilistic timestamp-amount matching
2. One-to-many matching - A single order (parent) produces multiple fills (children) at different prices, creating 1-to-many matching scenarios that aggregate-level reconciliation misses
3. Fee currency complexity - Exchanges deduct trading fees in the traded asset, the quote currency, or a platform token (BNB on Binance, FTT on FTX historically), requiring fee currency conversion at execution-time fair market value

The trade ID serves as the primary matching key. Each exchange assigns a globally unique identifier to every fill - not every order, but every individual execution. Reconciliation must operate at the fill level, not the order level, to capture accurate per-unit cost basis.

What Fields Does an Exchange Trading Log Contain?

Exchange trading logs contain 8 required fields and 4 optional fields per fill record. The 8 required fields are described in the table below.

Field	Description	Reconciliation Role
Trade ID	Exchange-assigned unique fill identifier	Primary matching key
Timestamp	UTC execution time (millisecond precision on most exchanges)	Temporal alignment and FMV lookup
Trading Pair	Base/quote notation (BTC/USDT, ETH/EUR)	Asset identification and currency mapping
Side	Buy or Sell	Determines debit/credit direction in journal entry
Quantity	Amount of base asset executed in this fill	Amount matching and lot assignment
Price	Execution price per unit of base asset	Cost basis calculation
Fee Amount	Trading fee charged for this fill	Fee expense recording
Fee Currency	Asset in which the fee was deducted	Fee currency FMV conversion

Four optional fields improve reconciliation accuracy when available: order ID (groups partial fills under a parent order), settlement timestamp (confirms when assets moved to available balance), maker/taker flag (determines the applicable fee tier), and rebate amount (for exchanges that rebate maker fees).

The fee currency field is the most common source of reconciliation exceptions. Exchanges like Binance deduct fees in BNB by default unless the user disables this setting. The fee amount in BNB requires a separate fair market value lookup at the exact execution timestamp to convert the fee to the reporting currency.

How Does the Trading Log Matching Process Work?

Trading log reconciliation follows a 5-step sequential workflow from data extraction through exception resolution. Each step transforms raw exchange data into reconciled accounting records.

Step 1 - Extract Trade Data

Trade data extraction uses 2 methods: REST API endpoints and CSV file downloads. The REST API method calls the exchange’s trade history endpoint (Coinbase /fills, Binance /api/v3/myTrades, Kraken /0/private/TradesHistory) with date range parameters. The CSV method downloads the trading history file from the exchange’s account settings or report generation page.

API extraction preserves all 8 required fields at full precision. CSV exports on some exchanges truncate timestamps to second precision and omit the maker/taker flag. Crypto exchanges vary in API rate limits, pagination methods, and historical data retention periods.

Step 2 - Normalize to Canonical Format

Each exchange uses different field naming conventions, timestamp formats, and pair notation. Normalization maps all exchange-specific formats to a single canonical schema.

Three normalization operations are listed below.

1. Field mapping - Exchange-specific column names mapped to canonical names (tradeId / trade_id / id all map to fill_id)
2. Type conversion - String timestamps converted to UTC datetime, string amounts converted to decimal with 18-digit precision, pair strings parsed into base and quote symbols
3. Pair standardization - Exchange-specific notation (BTCUSDT, BTC-USDT, XBT/USD) mapped to canonical BASE/QUOTE format with standardized token symbols (XBT normalized to BTC)

Step 3 - Match by Trade ID

The normalized fill records are matched against crypto subledger entries using the trade ID as the primary key. Trade ID matching is deterministic - the exchange-assigned identifier is identical in both the exchange data source and the subledger record. A successful match confirms the fill was ingested and recorded.

Unmatched fill records - present in the exchange data but absent from the subledger - indicate ingestion failures. Unmatched subledger entries - present in the subledger but absent from the exchange data - indicate duplicate imports or manual entry errors.

Step 4 - Verify Amounts and Fees

Matched records undergo field-level verification: quantity, price, and fee amount from the exchange data are compared against the corresponding subledger fields. Tolerance thresholds account for rounding differences - ±$0.01 absolute or ±0.001% relative for amounts, ±1 second for timestamps.

Fee verification requires special handling when the exchange deducts fees in a currency different from the traded pair. A BTC/USDT trade with a BNB fee requires 3 verification checks: BTC quantity matches, USDT settlement amount matches, and BNB fee amount converts correctly at execution-time FMV.

Step 5 - Resolve Exceptions

Unmatched and mismatched records route to the exception queue with classification labels. The automated reconciliation engine handles recurring exception patterns; novel exceptions require manual review.

What Causes Trading Log Reconciliation Exceptions?

Five exception types account for the majority of trading log discrepancies. Each type has a different root cause and resolution path.

Partial Fill Aggregation Differences

A single limit order to buy 10 BTC at $65,000 may execute as 47 separate fills across the order book - each with a unique trade ID, execution price between $64,990 and $65,000, and proportional fee. The exchange reports 47 individual fill records. The crypto subledger must record all 47 fills individually for accurate cost basis, or aggregate them into a single entry with a weighted average price.

Reconciliation exceptions arise when the subledger aggregates fills that the exchange reports individually, or vice versa. The fill count from the exchange data must match the record count in the subledger for the same order ID.

Fee Currency Mismatches

Binance deducts fees in BNB by default. Coinbase deducts fees in the quote currency. Kraken deducts fees in the quote currency. Bybit offers fee payment in the traded asset or USDT. The subledger must record the fee in the correct currency and apply the execution-time fair market value for fee currencies that differ from the reporting currency.

Fee currency exceptions arise when the subledger assumes a fee currency that differs from the exchange’s actual deduction. The BNB fee rate, BNB/USD price at execution time, and BNB amount must all reconcile against the exchange record.

Timestamp Precision Differences

Exchange APIs report timestamps at millisecond precision (1712678400123). CSV exports truncate to second precision (1712678400). Blockchain block timestamps use second precision. The subledger records the timestamp at the precision of the ingestion source.

Timestamp exceptions arise when the same trade is ingested via API and CSV at different precisions, creating duplicate records that differ only in sub-second timestamp digits.

API Pagination Gaps

Exchange REST APIs return trade history in paginated responses - 100, 500, or 1,000 records per page. High-volume accounts with tens of thousands of daily fills require hundreds of paginated requests to retrieve a complete monthly trading log. Interruptions during paginated retrieval (rate limiting, network timeouts, API maintenance windows) create gaps in the extracted dataset.

Pagination gap detection compares the expected fill count (from the exchange account summary or the order count multiplied by average fills per order) against the actual extracted fill count. A shortfall triggers re-extraction of the missing date range.

Dust Conversion Omissions

Exchanges periodically convert small residual balances (“dust”) into platform tokens or stablecoins. These dust conversions appear in the account balance history but are often omitted from the standard trading log export. The subledger records a balance change with no corresponding trade record - creating a phantom discrepancy.

Dust conversion detection identifies balance changes below a configurable threshold ($1-10) that lack a matching trade record, and classifies them as dust conversions requiring separate journal entry treatment.

What Is the Difference Between CSV and API-Based Reconciliation?

CSV and API-based reconciliation differ across 6 dimensions that affect accuracy, timeliness, and automation potential. The comparison is described in the table below.

Dimension	CSV Export	API Integration
Data freshness	Point-in-time snapshot, stale immediately	Continuous, scheduled polling (1-60 minute intervals)
Automation	Manual download, manual import, manual trigger	Programmatic extraction, automatic ingestion
Field completeness	Truncated timestamps, missing maker/taker flag	Full precision, all fields preserved
Historical depth	Exchange-determined retention (90 days to unlimited)	Paginated retrieval of full history
Trade ID preservation	Preserved on most exchanges, stripped on some	Always preserved
Timestamp precision	Second precision (truncated from milliseconds)	Millisecond precision

API-based reconciliation is required for organizations trading on 3 or more exchanges or processing more than 1,000 trades per month. CSV reconciliation remains appropriate for monthly reconciliation of low-volume accounts on a single exchange where the administrative overhead of API configuration exceeds the reconciliation benefit.

The crypto transaction reconciliation hub describes how exchange trading log data feeds into the broader multi-source reconciliation workflow alongside blockchain and custodian data.

How Does Trading Log Reconciliation Affect Cost Basis?

Each fill in the trading log establishes a tax lot with a specific per-unit cost basis. Incorrect fill data produces incorrect cost basis, which cascades into incorrect realized gain/loss calculations on every subsequent disposal.

Three cost basis dependencies on trading log accuracy are listed below.

1. Per-fill price - The execution price of each fill determines the cost basis of the acquired lot. Aggregated or averaged prices lose lot-level precision.
2. Fee allocation - Trading fees either increase the cost basis of the acquired asset (capitalized) or are recorded as a separate expense (expensed). The allocation method and the fee amount must both reconcile.
3. Timestamp accuracy - The execution timestamp determines the fair market value lookup for the acquired asset and the fee currency. A timestamp error of 5 minutes on a volatile trading day can shift the recorded FMV by 1-5%.

Recording the 3 fills as separate lots preserves the $10 per-unit cost basis difference between the first and third fill. Under FIFO disposal, selling 1 ETH at $4,000 produces a $600 gain (using the $3,400 lot). Recording the same 3 fills as a single averaged lot at $3,405 produces a $595 gain - a $5 discrepancy per disposal that compounds across hundreds of trades.

The exchange fee reconciliation process covers fee allocation methods in detail, including maker/taker fee tier verification and fee rebate accounting.

What Multi-Exchange Normalization Patterns Apply?

Organizations trading on multiple exchanges encounter 4 normalization challenges that must be resolved before cross-exchange reconciliation is possible.

1. Field naming - Coinbase uses trade_id, Binance uses id, Kraken uses txid, Bybit uses execId. Normalization maps each exchange-specific field name to a canonical schema field.
2. Pair notation - Coinbase uses BTC-USD, Binance uses BTCUSDT, Kraken uses XXBTZUSD. Normalization parses pair strings into separate base and quote symbols using exchange-specific delimiters and symbol maps.
3. Token symbols - Kraken uses XBT for Bitcoin and XXBT in some API responses. Normalization maps non-standard symbols to canonical identifiers (XBT to BTC, XXBT to BTC).
4. Fee structures - Binance uses BNB-denominated fees by default, Coinbase uses percentage-based fees in the quote currency, Kraken uses volume-tiered percentage fees. Normalization converts all fee representations to absolute amounts in the fee currency.

Multi-exchange normalization is a prerequisite for high-volume reconciliation - without canonical schemas, cross-exchange aggregate reporting produces inconsistent totals.