Getting trades out of a broker and into a journal

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.

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.