Both kinds of platform export ledgers — see why that matters. Each adds its own complication on top.
Futures: the price difference is not money
This is the one that produces confidently wrong numbers.
points = (exit − entry) × quantity
money = points × contract point value
An E-mini S&P contract moves $50 per point; a Micro E-mini, $5. Import a Tradovate ledger without the point value and every result is out by a factor of fifty — and, crucially, still looks plausible, because the sign and the relative sizes are all correct.
Our futures handling carries a contract specification table for this reason rather than treating the price difference as a result. If you check figures by hand, the multiplier is the first thing to apply.
Tradovate specifics
Export fills from the orders or fills view. Columns: B/S, Contract, Avg Fill Price (sometimes decimalFillAvg), Filled Qty, Fill Time, Status.
Filter on Status. The export includes cancelled and rejected orders, which never happened. Only filled rows are trades.
Commission is not in the standard fills export. Futures commissions are per contract per side and are billed separately, so a per-trade fee total from this file will be zero. Same honest caveat as elsewhere: zero means "not in this file", not "free".
Crypto: fees in a third asset
Crypto exchanges export each fill, and the fee column carries a complication that no forex statement has: the fee is often charged in a different asset than the one you are trading.
Trade ETH against USDT and the fee may be taken in BNB, KCS or the exchange's own token. That figure cannot be subtracted from a USDT result without a conversion rate at the time of the trade — a rate the export does not contain.
Where the fee is charged in the quote currency, it subtracts cleanly. Where it is not, any tool that subtracts it anyway is mixing units, and one that silently ignores it is understating your costs. It is worth checking which case your file is before trusting a cost total.
KuCoin and Coinbase specifics
KuCoin. Export filled orders or trade history. Columns vary by export type but resolve to Created At / Time, Symbol, Side, Price, Size and Fee. The same symbol appears with different separators between exports, which matters if you compare files by eye.
Coinbase. The advanced trade fill export carries the fill time, product, side, size, price and fee. The retail conversion history is a different file and is not a trade ledger — it will not import as trades, and should not.
What both share
Partial fills are the norm. A single order can arrive as a dozen rows at slightly different prices. FIFO matching handles this correctly, but it means your fill count and your trade count will differ by a lot more than on a forex account.
Times are usually UTC, unlike MetaTrader's broker-server time. If you compare a crypto history against a forex one by hour of day, that difference is doing more work than anything you are measuring.
No stops or targets. Neither export carries intended levels, so intent vs execution has nothing to compare and will say so rather than invent a comparison.
Checking the import
The count is the tell: it should match round trips, not fills. If the number looks like the number of rows in your file, the tool is counting fills — and every per-trade average built on top of it is understated by however many fills your average position took.