Three checkpoints in this guide
Follow the full walkthrough in order, or jump directly to one of its main sections.
Use the file that records the event you need
Binance does not have one universal “all trades” CSV. The visible Order History answers which orders were placed and whether they filled, while Trade History records executions and their fees. Futures have separate USDⓈ-M and COIN-M surfaces. Account statements, funding payments, Convert history, deposits, and staking activity are different ledgers.
Binance spot: Order History is not Trade History
On the Binance website, open the spot order area and switch between Order History and Trade History. Both expose a download control, but the rows have different jobs:
| Screen | What it contains | Journal use |
|---|---|---|
| Order History | Filled, partially filled, cancelled, expired, and unfilled orders | Audit order intent and status; do not count every row as a trade |
| Trade History | Executed matches, quantities, prices, direction, and transaction fee | Primary spot execution evidence |
| Transaction/account statement | Wallet movements across products | Reconcile balances and missing legs; only paired trade groups can create trades |
Binance says the normal spot history view covers the most recent six months. For older activity, use the downloadable transaction-history statement route. Split a long period into stable files and keep the original UTC timestamps. Do not merge columns in a spreadsheet before import.
Exact spot export sequence
- Use Binance on the web and open the spot orders area for the account whose activity you are reconciling.
- Open Trade History, not only Order History. Set the pair only if you deliberately want a single-market file; otherwise preserve the complete period.
- Choose Download, set the UTC window, and request the export. For active accounts, use monthly files so the first and last day can be checked independently.
- Download the generated file without opening and resaving it in Excel. Record the account, dataset, and UTC dates in the filename outside the CSV contents.
- Export Order History for the same window only when you need to explain cancelled, expired, or partially filled orders. Keep it as supporting evidence rather than adding its row count to the trade count.
Before import, inspect the header—not individual profits. A usable execution file must retain time, symbol/pair, side, executed quantity, executed price, and fee information. If the file only reports requested order quantity or final status, it cannot prove every fill.
Binance futures: select the contract family first
From the Futures trading interface, open Orders, choose USDⓈ-M Futures Order or COIN-M Futures Order, open Order History, and use Export. Binance provides a Beyond 3 months – Custom option for older order history. Make the contract family and requested window part of the file name before upload.
A futures order export can still be incomplete for performance analysis. You may also need closed-position history for realized P&L and a funding ledger for payments received or paid while the position was open. TSB has reviewed support for Binance futures closed-position exports, but a COIN-M funding-only file is intentionally treated as reconciliation evidence rather than a trade file.
Build a futures evidence pack, not one oversized spreadsheet
| Evidence | Why you need it | Can it create trades? |
|---|---|---|
| Order History | Explains order status, requested size, cancellations, and product family | Only when the exact reviewed schema proves executions; status rows alone are insufficient |
| Trade/fill or closed-position history | Proves executed quantity, price, direction, close, and realized result | Yes, for a reviewed populated schema |
| Funding history | Explains periodic cash transfers while a perpetual was open | No standalone trade; attach only when the settlement-to-position link is proved |
| Account statement | Controls ending balances across wallets and exposes transfers | No; it is a reconciliation layer |
Keep USDⓈ-M and COIN-M in separate batches. The settlement asset, contract economics, and funding rows differ. Combining them before import removes the product boundary that the parser and the reviewer need to verify.
What TSB currently recognizes
The reviewed import corpus includes Binance account statements with safely paired spot movements, compact spot trade history, Spanish locale variants, futures closed positions, Convert history, coin-swap history, and Binance.US transaction history. It also contains fail-closed profiles for funding-only COIN-M files, fiat deposits, Auto-Invest acquisitions, BETH conversions with an incomplete received leg, non-trade statements, and third-party simplified futures files.
That boundary matters: a green Binance logo is not proof that every row can be converted into a completed trade. TSB must be able to prove the instrument, side, quantity, price, time, and lifecycle without inventing a missing leg.
What the import preview must prove
Do not confirm the batch because the source name says Binance. Compare the preview against the export before any journal enrichment:
- the detected profile describes the dataset you downloaded, not merely the exchange;
- the first and last execution timestamps fall inside the requested UTC window;
- the symbol and contract family are unchanged;
- executed size—not requested order size—drives the candidate count;
- fees retain both amount and asset where the source provides them;
- partial fills group into a position without deleting their execution identity;
- funding, deposits, transfers, Convert, and Earn rows do not silently become completed trades.
If the preview reports a guardrail, preserve the raw file and the message. A guardrail is a statement that the current evidence cannot prove a safe lifecycle; editing the CSV to resemble another template destroys that evidence rather than fixing it.
Create a source manifest before the first upload
| Manifest field | Example | Why it matters |
|---|---|---|
| Account boundary | Main account / subaccount name | Prevents the same transfer from appearing as profit in one batch and loss in another |
| Product family | Spot, USDⓈ-M, or COIN-M | Preserves settlement currency and contract economics |
| Dataset | Trade History, Order History, Closed Positions, Funding | Defines what each row is allowed to prove |
| UTC window | 2026-08-01 00:00 through 2026-09-01 00:00 | Exposes gaps and overlapping boundary rows |
| Raw-file checksum or immutable filename | Stored beside the import batch | Shows which source was reviewed if the file is later replaced |
For adjacent monthly exports, choose a half-open boundary: the first file ends where the next begins. If Binance exports both endpoints inclusively, deduplicate only by a stable execution identity after preserving both raw files—not by deleting rows before import.
Binance failure modes to check
- Order rows without fills: cancelled and unfilled orders inflate counts if treated as executions.
- Funding separated from trades: gross closed P&L can reconcile while net account movement does not.
- Partially filled orders: one order can produce multiple executions; compare quantities, not only order IDs.
- Wallet transfers and Earn rows: these change balances but are not trading P&L.
- Wrong contract family: USDⓈ-M and COIN-M exports use different economics and must not be blended blindly.
- Edited CSV: locale conversion, date formatting, or deleted columns can destroy source detection.
The exact export → import → reconcile → review workflow
- Export: download Spot Trade History for spot executions. For futures, export the correct USDⓈ-M or COIN-M history plus closed positions and funding when those records are needed.
- Import: open TSB Journal → Import trades, upload one untouched file, and confirm the detected source and preview.
- Reconcile: compare date window, execution count, base/quote totals, fees by asset, realized P&L, funding, and deposits/withdrawals. Keep non-trade ledgers beside the batch even when they create zero trades.
- Review: open the imported batch, inspect warnings and partial closes, assign account/setup context, and mark records reviewed only after totals match.
Worked reconciliation: one position, three different totals
Assume the closed-position export shows $240 of realized price P&L. The fill ledger shows $18 of trading fees, and funding history shows two payments totaling $7. The journal’s net result should be $215, provided the exchange’s $240 field is gross of those costs. If the wallet also received a $500 transfer, the wallet change can be $715 while trading performance remains $215.
Now compare counts. One order that filled in three parts may appear as one order, three executions, one closed position, and one journal trade. These counts are not supposed to match each other. Reconcile order count to Order History, execution count to Trade History, and closed lifecycle count to the normalized journal.
Final acceptance checklist
- Raw files are untouched and labelled with account, dataset, product family, and UTC window.
- Every requested day is covered without overlap or an unexplained gap.
- Spot, USDⓈ-M, and COIN-M are separate import batches.
- Execution quantities and fees reconcile; order-status rows are not double-counted.
- Funding and external wallet flows explain the bridge from gross P&L to balance change.
- The batch is marked reviewed only after warnings and unmatched rows have an explicit disposition.
