Crypto Exchange Statement Reconciliation: API, CSV, and the Trade-Fee Trap

This spoke covers the one reconciliation in the pillar set that has no blockchain in it: the centralized exchange account. Teams reconcile a CEX like a bank and get burned, because there is no canonical statement, the API and CSV exports often disagree, and every trade carries a fee that quietly moves cost basis. The focus here is the source-of-record and fee discipline a CEX needs, which is distinct from both on-chain and bank reconciliation. Because the treatment of differences is a controls and auditor question, this stays deliberately hedged.

In short

• This is not bank reconciliation. A CEX has no single canonical statement, its API and CSV exports diverge in fields, granularity, and sometimes figures, and the exchange is itself the counterparty.
• Neither API nor CSV is universally authoritative. The source of record is a documented entity policy, applied consistently.
• Trade fees are the trap: every trade carries a fee (netted, shown separately, or charged in a different asset), and inconsistent handling drifts quantity and cost basis even when the headline balance ties.
• It is complementary to on-chain reconciliation: wallet-to-exchange transfers must reconcile across both sources without being double-counted or treated as disposals.
• Defensibility comes from a source-of-record policy, consistent fee treatment, complete account capture, a defined cadence, break resolution, and an audit trail.
• These are the entity's controls; the sufficiency and accounting effect are the auditor's. This is not accounting advice.

Why it is not bank reconciliation

Bank reconciliation has a canonical statement from the bank as the authoritative external record. A CEX typically does not provide one the same way: the API export and CSV export differ in fields, granularity, and sometimes figures, there is no universal format, and the exchange is itself the counterparty whose record you reconcile to. So it needs a defined source-of-record policy and a tolerance for source divergence (compare the reconciliation pillar).

API or CSV?

Neither is universally authoritative. It is an entity policy decision which source is the record and how API-versus-CSV discrepancies are resolved, documented and consistently applied. Silently switching sources, or assuming they agree, produces unexplained breaks. The chosen source of record and resolution method are part of the control environment.

The trade-fee trap

Every trade typically carries a fee that reduces proceeds or increases cost, and fee handling differs by exchange and export: netted, shown separately, or charged in a different asset. Inconsistent fee reconciliation makes quantity and cost basis drift even when the headline balance appears to tie (this feeds auditing cost basis and gains). Fee treatment must be explicit, and its accounting effect is framework-specific and auditor-confirmed.

Relation to on-chain reconciliation

The two are complementary. On-chain reconciliation ties wallet activity to the chain; exchange reconciliation ties exchange-account activity to the exchange's records; and wallet-to-exchange transfers must reconcile across both without double-counting or being booked as disposals (see internal transfer vs disposal). Treating either alone as the whole reconciliation leaves a gap.

Practical guidance

1. Do not treat a CEX like a bank; there is no canonical statement.
2. Document a source-of-record policy (API or CSV) and apply it consistently.
3. Make fee treatment explicit, because inconsistent fees drift cost basis.
4. Reconcile wallet-to-exchange transfers across both sources with no double-count or disposal.
5. Capture every exchange account, reconcile at a defined cadence, and resolve breaks.
6. The controls are the entity's; sufficiency and accounting effect are the auditor's. Not accounting advice.

Step-by-step exchange reconciliation for a Coinbase Pro / Advanced Trade account

The following sequence illustrates the reconciliation discipline for a single exchange account. The same logic applies to other centralized exchanges; field names and API endpoints vary.

Step 1 — Define the source of record

Before pulling any data, document which source is authoritative for this account: the API trade history endpoint or the CSV download. For Coinbase Advanced Trade, the API provides more granularity (including fee asset details for trades where fees were paid in a different token) but requires ongoing API key management; the CSV is simpler but may net fees differently. The choice is documented and applied consistently every period — switching between periods without documentation produces unexplained variance.

Step 2 — Pull and parse the full account history for the period

From the chosen source, extract all activity for the reconciliation period:

• Spot trades (buy/sell): trade ID, pair, base quantity, quote quantity, fee amount, fee asset, timestamp;
• Deposits: inbound asset, quantity, source address (if shown), timestamp;
• Withdrawals: outbound asset, quantity, destination address, timestamp.

Deposits and withdrawals to/from on-chain wallets become the wallet↔exchange transfer entries that must reconcile across the exchange and on-chain ledgers without double-counting.

Step 3 — Reconcile the opening balance

The reconciliation starts from the prior period's closing balance in the subledger, not from the exchange's displayed balance. The exchange's displayed balance is the target; the subledger's prior-period close is the start. Any discrepancy between the two at the start of the period is an unresolved prior-period break and must be cleared before the current-period reconciliation is reliable.

Step 4 — Process trades with explicit fee treatment

For each trade, the reconciliation books:

• Buy: debit asset purchased at cost (base quantity × rate + acquisition fee); credit USDC/fiat at proceeds
• Sell: debit USDC/fiat at proceeds (net of disposal fee); credit asset at cost basis; debit/credit realized gain or loss

If the fee was charged in the traded asset (e.g., fee deducted from BTC received), the quantity reconciliation must account for the fee reduction — the subledger records quantity net of fee while cost basis reflects the fee as an acquisition cost increment. Ignoring this produces a quantity mismatch between the subledger and the exchange's balance even when the USD figures agree.

Step 5 — Reconcile transfers against the on-chain record

Every withdrawal from the exchange to an on-chain wallet should appear as:

1. A debit in the on-chain wallet's inbound transaction record, and
2. A withdrawal in the exchange's export.

Match these by: asset, quantity, and timestamp (allowing for exchange processing time vs on-chain confirmation time, which may differ by minutes to hours). Unmatched items are the most common source of reconciliation breaks: an exchange withdrawal that the on-chain wallet has not yet received (pending), a deposit the exchange recorded but the subledger's wallet ingestion missed, or a withdrawal to an unmapped wallet.

Step 6 — Resolve breaks and document

Each break has a defined investigation path:

• Quantity mismatch on a trade: check fee asset and fee netting logic in the source export;
• Timing gap on a deposit/withdrawal: check block confirmation time vs exchange crediting time; allow a tolerance window;
• Unknown transaction: investigate the exchange's activity log for conversions, earn rewards, or referral credits not captured in the standard trade history export.

Document each break's cause, resolution, and resolution date. Breaks not resolved before period close carry forward as open items and are disclosed in the reconciliation package.

Configuring a tool for exchange reconciliation

Tools such as Cryptio and Bitwave ingest exchange API and CSV data and reconcile it, handling fees and wallet-to-exchange transfers. The tool reconciles; the policy choice and accounting effect remain entity and auditor judgements. Before relying on one, confirm it:

• lets you set and record a source-of-record policy (which of API or CSV is authoritative) and applies it consistently rather than silently switching;
• lets you make fee treatment explicit, including fees charged in a different asset, so quantity and cost basis do not drift;
• reconciles wallet-to-exchange transfers against the on-chain record without double-counting them or booking them as disposals.

The headline balance tying is not enough; the fee and transfer behaviour is where exchange reconciliations quietly go wrong.

Where Wag3s fits

Wag3s Ledger ingests exchange API and CSV with a configurable source-of-record policy and explicit fee treatment, reconciles wallet-to-exchange transfers without double-counting, at a defined cadence with break tracking and an audit trail. The policy choice and the accounting effect stay entity- and auditor-confirmed; Ledger supports those controls rather than substituting for them. See the Ledger product page.

Further reading

• Crypto Bank Reconciliation
• Multi-Chain Reconciliation
• Internal Transfer vs Disposal (Crypto)
• Auditing Crypto Cost Basis & Gains
• Gas Fee Reconciliation
• Reconciliation Break Investigation (Crypto)

Notes on sources

Exchange reconciliation is an operational controls exercise rather than something governed by an external standard, so it has no canonical authority to cite. The points here follow from how centralized exchanges actually report: no single canonical statement like a bank's, API and CSV exports that diverge in fields, granularity, and sometimes figures, the exchange itself as counterparty, and trade fees that move quantity and cost basis if handled inconsistently. Whether the resulting controls are sufficient for audit, and the accounting effect of fee treatment, are framework-specific judgements for the entity's accountant and auditor. This is not accounting advice.