Interactive Brokers Trading Journal: Flex Query Setup + Multi-Asset Import

IBKR's Flex Queries can produce the cleanest trade data in the industry. Exact fills, exact fees, exact commissions, full Open/Close indicators, Order IDs that enable accurate multi-leg grouping, currency-tagged P&L for international equities. When configured right, an IBKR Flex Query is journaling gold.

The catch: Flex Query configuration is presented as a flat list of ~80 possible fields with no guidance on which combinations actually work. Pick wrong and:

• No Order ID → multi-leg options can't be grouped, your iron condors show as 4 unrelated trades.
• No Open/Close Indicator → scale-in / scale-out fills can't be reconstructed correctly.
• No Asset Class field → futures and forex get misclassified as equity, R-multiple math breaks.
• No Foreign Currency fields on international trades → P&L gets lost in currency conversion.
• No Settlement Date or Trade Date → some journals can't even map the trades to a chronological timeline.

Set up a Trades Flex Query with these fields. Save it once and re-run it weekly or monthly going forward.

Required fields (without these, the data is unusable)

• Symbol — the trading symbol (or root for futures/options)
• Trade Date / Time — when the fill executed
• Asset Class — Equity, Option, Futures, Cash (forex), etc.
• Quantity — number of contracts/shares/units
• Trade Price — fill price
• Open/Close Indicator — whether this fill opened or closed a position
• Buy/Sell — direction
• Currency — for non-USD denominated trades
• IB Commission — per-fill commission/fee

Strongly recommended fields (multi-leg + scale-in/out support)

• Order ID — needed for multi-leg options grouping
• Trade ID — unique per fill, useful for deduplication on re-imports
• Underlying Symbol — for options, the underlying ticker
• Strike — for options
• Expiry — for options and futures
• Right (Put/Call) — for options
• Multiplier — contract multiplier for options/futures (TradersForge has built-in lookups but explicit is safer)

Optional but useful

• Foreign Currency / Currency Conversion fields — for international equities
• Notes / Order Reference — if you tag orders in TWS, the tags come through

1. Log into IBKR Account Management (the management portal, not TWS).
2. Navigate to Reports → Flex Queries.
3. Click Create New Flex Query → Trades Query.
4. Name it something memorable: "TradersForge Journal Export" works.
5. In the Sections list, expand Trades and select the fields listed above.
6. In Format, choose CSV (more reliable than XML for downstream parsers).
7. Set Time Period to "Last N Calendar Days" — start with 365 for backfill, then change to 7 or 14 for ongoing weekly exports.
8. Save the query.
9. Run the query: Reports → Flex Queries → Run for your saved query → download CSV.
10. Drop the CSV into TradersForge's Import & Connect page.

Re-running for ongoing journaling

After the first backfill, change the Time Period on your saved Flex Query to a shorter window (e.g., last 14 days). Run it weekly or monthly. TradersForge dedupes by Trade ID — only new trades since your last import get added. You can also configure IBKR to email the Flex Query results on a schedule, but the manual run is fine for most users.

IBKR's real strength is multi-asset support. One Flex Query can include stocks, options, futures, forex (Idealpro), and international equities — all in one CSV.

Stocks

Asset Class = "Equity." R-multiple uses dollar-share math. Per-symbol expectancy works the same as for any other broker.

Options

Asset Class = "Option." Multi-leg grouping uses Order ID. Strike, Expiry, and Right come through. R-multiple uses ×100 multiplier per contract.

Futures

Asset Class = "Futures." TradersForge's built-in contract multiplier lookup applies (ES, NQ, MES, MNQ, RTY, CL, GC, etc.). For exotic futures not in the lookup, you can override the multiplier per trade.

Forex (Idealpro)

Asset Class = "Cash." Pair information comes through Symbol + Currency fields. R-multiple uses pip-based math (~$10/pip per standard lot for major USD-quoted pairs).

International equities

LSE, TSE, ASX, etc. — all flow through. Currency Conversion fields let TradersForge convert P&L to USD if you include them; otherwise P&L is shown in trade currency.

TWS doesn't do this — only Account Management

A common confusion: Trader Workstation (the desktop trading platform) is for execution and analysis. The export workflow lives in IBKR Account Management (the web portal). Reports → Flex Queries is in the portal, not TWS.

IBKR uses Trade Date AND Settlement Date

For most journaling, Trade Date is what you want — the date the fill executed. Settlement Date is the post-fill clearing date (usually T+1 or T+2). Make sure your Flex Query includes Trade Date specifically; importing settlement-only data shifts everything by 1-2 days.

Commission can show as separate line items

IBKR sometimes splits exchange fees + clearing fees + commission across multiple line items. The "IB Commission" field typically captures the total; the fragment fields capture pieces. TradersForge sums them to net commission per fill, but if you only include partial fields, you'll show under-stated fees.

International trades and currency conversion

A LSE trade might be denominated in GBP. Your TradersForge journal can show this in GBP (no conversion) or in USD (using the FX rate at trade time, if you include the Currency Conversion fields in the Flex Query). Pick one approach and stay consistent.

Flex Query has a daily run limit

IBKR limits Flex Query runs (typically a few per hour, dozens per day). Running the same query repeatedly for testing can rate-limit you. Save the query once, run it on a real schedule, and don't re-run for casual checking.

This trips up almost everyone who goes looking for it. You open the Flex Query editor, expand the Trades section, scan the field list for something called "Wash Sale" or "Loss Disallowed" — and there is nothing there. The usual conclusion is that you picked the wrong query type. You did not. The Trades section is a record of executions, and a wash sale is not a property of an execution; it is an adjustment applied afterwards, when a closing lot is matched against a repurchase inside the 61-day window.

Where the data actually lives

Wash-sale adjustments surface in the lot-level realized sections, not the raw trade list. In an Activity Statement or an Activity Flex Query, look at the realized/closed-lot detail rather than Trades:

• Code — a per-lot code column. Lots adjusted for a disallowed loss carry the code LD. This is the field people are hunting for when they search the Trades section and come up empty.
• Realized P/L — for a wash sale this is already the NET realized amount, with the disallowed loss included. It is not the raw economic loss, which is exactly why a journal that reads this column and a journal that recomputes from fills can disagree.
• Closed Lots — replaces the Open designation once a lot is closed, and is the row granularity the adjustment is applied at.

Why this matters for a journal, not just for taxes

A trader who imports realized P/L straight from a wash-sale-adjusted report gets a distorted picture of their own edge. The disallowed loss is a tax timing effect — it is deferred into the basis of the replacement lot, not erased — so the strategy that produced the loss looks better than it was, and the later trade that inherits the basis looks worse. For judging setups you want the raw economics; for filing you want the adjusted figures. They are different numbers and both are correct for their own purpose.

TradersForge keeps them separate. Trades import from the Trades Flex Query at raw economics, and wash sales are detected independently from fills and timestamps under Section 1091 rules, so your per-setup expectancy is never quietly adjusted by a tax rule. Deferred losses show year-to-date by ticker on the analytics page.

For high-volume IBKR users who don't want manual Flex Query runs, the Flex Web Service exposes the same data via a REST API. This is on the TradersForge roadmap for native integration. For now, the manual workflow is supported and works well — most users find weekly Flex Query runs are enough for active journaling.

TWS API is a separate, more complex integration option (live order/position events) but it's overkill for journaling and adds operational complexity (a TWS instance has to stay running). Flex Query CSV is the recommended path.