Getting trades out of a broker and into a journal
“How do I get my trades from my broker into a journal without wrecking the data?”
Brokers export fills; a journal stores trades. Turning one into the other is where imports go wrong, and the three failures that matter are duplicated rows, timestamps in an unstated timezone, and costs that were never in the file.
In short
Import rather than retype — a complete record is the whole point — but check the three things a file can be silently wrong about: whether rows are already in the book, what clock the times are on, and whether commissions came with them.
Fills are not trades
A broker file has one row per execution. A position opened in two lots and closed in three is five rows and one trade, and reconstructing that requires walking the fills per symbol in time order, tracking the running position and closing a trade when it returns to flat.
This is why entry and exit prices in a journal are usually volume-weighted averages rather than numbers found in the file, and why a partially closed position is a trade that is still open with a realised component.
| Fill | Side | Qty | Price | Position |
|---|---|---|---|---|
| 1 | Buy | 100 | 50.00 | 100 |
| 2 | Buy | 100 | 50.40 | 200 |
| 3 | Sell | 80 | 51.10 | 120 |
| 4 | Sell | 70 | 51.30 | 50 |
| 5 | Sell | 50 | 50.90 | flat |
One trade
Long 200 · entry 50.20 avg · exit 51.12 avg · +$184 before fees
Duplicates, and why a stable identity matters
Re-importing an overlapping export is normal — most people export a wider date range than they need. What prevents it doubling the book is a per-execution identity derived from the row itself, so the same fill is recognised as the same fill on a second import.
That identity has to be stable against things that legitimately change between exports, such as the display timezone or the column order. If it is derived from a formatted timestamp, exporting the same trades under a different setting produces a new identity for every row and the book doubles.
Timezones: the failure that leaves no error
Many broker exports carry no timezone at all — a bare "2026-07-07 21:00". Read on the wrong clock, that stamp lands on the wrong side of a day boundary, and every calendar view, session grouping and daily-loss calculation built on it is off by a day for those trades.
Nothing errors, because a valid timestamp was read; it is simply a different instant from the one the file meant. The only defence is stating what zone the file is in at import time rather than assuming one.
Costs that are not in the file
Some platforms ship commissions in a separate document from the trade history, so a straight import of the trade file produces a book with no costs in it. Every profitability figure computed from that book is flattering, and by a consistent amount rather than a random one.
The honest handling is for the import to say where fee data came from — the file, an account-level rate, or nowhere — rather than defaulting a missing value to zero, which is indistinguishable from genuinely commission-free trading.
Automatic sync, and what it changes
A direct connection removes the export step and the duplicate problem along with it, since the same execution identity is seen on every poll. What it does not remove is the timezone and cost questions, and it adds one of its own: a trade deleted in the journal must stay deleted rather than being re-created by the next sync.
Questions
- Why do my imported trades show different prices than my broker?
- Usually because the position was filled in pieces and the journal stores the volume-weighted average across those fills, while the broker screen shows a single execution. The two agree on the total; they differ on what a single row means.
- Can I import the same file twice?
- It should be safe, and that is precisely what per-execution identity exists for. It is worth confirming on a small file before importing years of history, because the failure is silent and doubles the book rather than raising an error.
- What if my broker is not supported?
- A generic CSV import with column mapping covers files no bespoke parser knows, as long as the file contains a symbol, a side, a quantity, a price and a timestamp per row. What a bespoke parser adds is knowing that particular broker's quirks without being told.
Calculate it
In the app
Keep reading
Ledger of Alpha is the record these measurements are computed from. See the full product
Keep the record it all comes from
These measurements need a complete book of trades behind them. A free account gives you somewhere to keep one.