Three checkpoints in this guide
Follow the full walkthrough in order, or jump directly to one of its main sections.
Quick answer: one journal can hold many trading accounts without treating them as one account. Preserve the exact source account and lifecycle on every trade, reconcile each import, and make the active scope visible before reading any metric. Use an All accounts view for an operational overview; return to one account or a controlled comparison for decisions about execution, strategy, or prop rules.
The difficult part is not adding another account name. It is preventing currencies, simulated balances, copied orders, challenge restarts, costs, and strategy versions from becoming one misleading sample. A good multi-account journal keeps those differences available while still letting you review them from one workspace.
The governing rule: unify storage, not meaning. Every combined number needs a common definition, a declared currency treatment, and enough account-level detail to reconstruct it.
The Multi-Account Problem
A trader may have personal live accounts, demo or paper accounts, prop evaluations, funded or simulated-funded accounts, and strategy-test environments. Those records can share instruments and setups while differing in fees, leverage, drawdown rules, allowed products, execution route, currency, or economic ownership.
Separate spreadsheets preserve some boundaries but make reconciliation and repeatable review harder. Blind aggregation creates the opposite problem: it makes the workspace convenient while hiding which account, rule set, or conversion produced the result. The useful design is one evidence store with stable account identity and explicit views over it.
Storage scope is not analysis scope
Storage scope answers where the records live. Analysis scope answers which eligible records belong in this calculation. A unified journal can store everything while a report uses one account, a controlled pair, or a clearly labeled multi-account population. Changing the scope can change the conclusion; the interface should expose that change rather than carry a previous answer into a new population.
The journal-building guide covers the underlying trade record. Multi-account work adds identity, lifecycle, currency, and comparability controls on top.
Create One Record per Account and Lifecycle
An account label should identify a real source boundary, not merely a folder. A new evaluation attempt, a transition into another program phase, a broker migration, a base-currency change, or a material strategy-version reset may need a new lifecycle record even when the brand and nominal account size look similar.
| Identity field | Why it matters | Do not substitute |
|---|---|---|
| Account ID and display name | Keeps every trade tied to one owned source account | A reusable label such as “Main” across several accounts |
| Account type and stage | Separates personal, demo, evaluation, funded, and other states | A firm name without the exact program phase |
| Native currency | Defines how monetary outcomes and costs were recorded | The dashboard display currency |
| Lifecycle dates | Prevents a restart or closed account from blending into the next attempt | The most recent import date |
| Strategy and rule version | Lets comparisons distinguish system change from account difference | A generic “same strategy” note |
| Source and reconciliation state | Shows whether counts, times, quantities, fees, and P&L match the provider record | A successful upload message |
A naming convention that survives restarts
Use a readable name such as [venue or program] · [account identifier] · [stage] · [currency] · [opened date]. Keep the immutable account ID underneath the label. If an evaluation restarts, close the previous lifecycle and create the next one; renaming an old record erases the boundary needed for an attempt-to-attempt review.
Never consolidate several real accounts into one record simply because they use the same program. Separate accounts can have different rule states, payouts, orders, technical failures, and copied exposure. Archive inactive records from the active selector instead of merging their trades.
How Account Scope Works
Account scope is a population selector. It should travel with the Journal, Dashboard, Reports, playbook, backtests, and evidence-based coaching so every surface refers to the same account boundary. A URL, report header, export, or saved finding should state whether it represents All accounts or one exact account.
| Scope | Use it for | Main risk |
|---|---|---|
| One account | Rule compliance, reconciliation, execution review, account-specific costs | Mistaking a small or unusual account sample for the whole strategy |
| Controlled account pair | Comparing the same strategy version, period, instruments, and normalized outcomes | Attributing every difference to account type |
| All accounts | Inventory, activity, reconciled display-currency P&L, coverage gaps, total exposure review | Combining incompatible money, duplicated trades, or unlike rules |
Persistence helps only when it is visible
Remembering the last selected account saves repetitive filtering, but a persistent scope can also surprise the next review. Check the scope label before interpreting an empty state, total, chart, Coach answer, or backtest. Saved findings should retain their original account and date population; reopening them in another scope should show a mismatch instead of silently reusing the conclusion.
What “All Accounts” Can—and Cannot—Mean
An All accounts view is not permission to add every visible number. It is a request to build a broader population under explicit aggregation rules.
Mixed currencies need a display-currency evidence layer
Native P&L in different currencies cannot be summed directly. Convert each eligible monetary row to one declared display currency using a dated conversion source, retain the native amount and currency, and expose missing or stale conversion coverage. If one material row cannot be converted, the combined monetary result is incomplete; do not substitute zero.
A display-currency total is useful for review, but it still is not automatically cash income. Deposits, withdrawals, tax, payout eligibility, platform balances, unrealized positions, and simulated prop-account values have different meanings. Reconcile actual cashflows separately when the question is income or net worth.
Copied trades are exposure, not independent confirmation
If the same decision is copied across several accounts, the resulting rows are separate operational executions but not independent strategy observations. An All accounts trade count can therefore overstate sample size. Preserve a decision or copy-group reference where possible; at minimum, cluster rows by instrument, direction, entry time, setup, and overlapping life before describing diversification or evidence strength.
Nominal balance is not a common risk denominator
Personal equity, demo balance, evaluation size, and simulated-funded buying power do not represent the same economic capital. Compare risk through declared initial risk, realized R where the denominator is valid, distance to the account’s own loss boundary, exposure, and cashflow—not by adding headline balances.
| Combined field | Safe when | Stop condition |
|---|---|---|
| Trade inventory | Identity and duplicate/copy semantics are preserved | Rows may be duplicate imports |
| Display-currency P&L | Every included row has a complete, dated conversion | Conversion is missing, stale, or uses an undeclared basis |
| Win rate | Outcome and trade-unit definitions match | One source counts fills while another counts positions |
| Expectancy | Eligibility, costs, currency, and observation unit are consistent | The combined sample mixes strategy or rule versions |
| Drawdown | Computed per valid equity series or under a declared portfolio series | Independent account peaks and rule floors are simply added |
Can I review a broker and crypto exchange together?
Yes. Keep the broker and exchange as separate source accounts, then choose an explicit review scope. A deposit or transfer between them changes where your capital sits; it is not a winning trade. A perp funding payment is a cost or credit to reconcile with that position, not a second trade. IBKR statements separate trades, fees and deposits; Bybit explains that its realized P&L can already include trading and funding fees. Check the source definition before adding or subtracting a cost.
| Record | Trading result | Review rule |
|---|---|---|
| Broker closed trades | +$120 after recorded commission | Keep this in its broker account. |
| Exchange closed perp trades | +$80 before $12 funding and $8 trading fees = +$60 net | Subtract these costs only if the +$80 source figure excludes them. |
| $500 moved between accounts | $0 trading profit | Reconcile both sides as a transfer, not another win. |
Those closed-trading results would total +$180 only if both account histories cover the same dates and the money is converted on a declared basis. If one source is missing costs or its amount is in a different currency, show two scoped results and mark the combined total not verified. TSB’s AI Coach can review a selected account or All accounts; it does not offer an arbitrary two-account Coach selector. Compare two scoped answers unless All accounts contains exactly the intended pair, and check the evidence range before drawing a conclusion.
Compare Accounts Without Inventing a Cause
Cross-account comparison is useful when it is designed like a controlled review. Freeze the date window, strategy version, instrument set, session definitions, cost treatment, trade unit, and currency basis. Then show both the numerator and denominator for every metric.
The personal-versus-funded comparison is one possible slice, but a difference does not prove fear, carelessness, or pressure. It may reflect different rules, market periods, instruments, fills, spreads, size, data quality, or selection. Treat the result as an observed contrast and inspect the matching trades before assigning a cause.
Use three layers
- Data comparability: confirm coverage, timestamps, trade grouping, currency conversion, costs, account ownership, and lifecycle boundaries.
- Observed contrast: report counts, net outcomes, payoff distribution, exposure, drawdown path, rule adherence, and missing fields for each account.
- Decision: keep, reduce, pause, or investigate one process under a predeclared rule. Do not rewrite the comparison after seeing the preferred result.
No universal sample threshold
A fixed number of trades cannot make every comparison reliable. Evidence depends on dispersion, dependence, number of repeated groups, strategy stability, field coverage, and the size of the observed difference. Show confidence or uncertainty appropriate to the data, retain thin groups, and collect a later comparable sample. The performance-analysis guide explains why a metric without its population and limitations is incomplete.
Managing Multiple Accounts in TSB
Ownership disclosure: Trader's Second Brain is our product. The current system resolves an owned account scope on the server, carries that scope across core review surfaces, and distinguishes All accounts from one exact account. TSB has recorded 600K+ imported trades, and its canonical registry recognizes 332 broker, exchange, platform, and prop-export profiles. Those figures describe product-scale import history and recognized routes, not guaranteed field completeness for every account.
A defensible setup sequence
- Create or resolve the account record. Give it a stable identity, native currency, account type, and lifecycle state before importing.
- Test one representative source. Use the supported-source directory, then reconcile account, trade count, tickets, timestamps, quantities, gross result, fees, funding or swap, and net result.
- Confirm the post-import scope. A successful import can remain hidden when the global or Journal filter points at another account. Widen the scope or switch to the imported account deliberately.
- Review one account first. Verify the Journal and Reports population before trusting All accounts. For prop activity, attach the exact program and phase before a rule replay.
- Use All accounts with a declared display currency. Inspect conversion coverage and duplicate exposure before reading combined P&L, win rate, or expectancy.
- Save the scope with the conclusion. Coach answers, backtests, playbook findings, and review actions should retain account, period, currency, and evidence membership.
Review across accounts without flattening them
TSB Full Access includes individual account scopes, multi-account review surfaces, imports, reports, Coach, backtesting, and prop challenge replay. Current monthly and lifetime values render from server product truth.
Review current TSB optionsFive Multi-Account Mistakes
- Reusing one record after a lifecycle reset. A new attempt or phase inherits trades and rules that no longer belong to it.
- Applying one risk percentage everywhere. Account loss controls, volatility, liquidity, open exposure, and strategy evidence may require different limits. Consistency means following the declared rule for each scope, not forcing every account into one percentage.
- Calling copied rows independent trades. Several executions of one decision increase exposure; they do not multiply strategy evidence.
- Summing incomplete currency data. Missing conversion is an evidence gap, not a zero-value trade.
- Diagnosing psychology from a performance gap. First inspect data quality, constraints, strategy version, instruments, costs, and execution conditions.
The multi-prop tracking guide extends these controls to several rule-bound accounts and copied exposure.
Who Should Skip Multi-Account Tracking for Now?
A trader with one active account needs a clean single-account journal, not an elaborate portfolio layer. Add another account record only when a real source, lifecycle, currency, rule set, or ownership boundary exists. A thin comparison should remain a thin comparison; creating more scopes does not create more evidence.
Multi-Account Setup Checklist
- List every active source account and close or archive inactive lifecycles.
- Assign stable IDs, readable names, native currencies, types, stages, and strategy versions.
- Import a representative file or connection for each route and reconcile it before bulk history.
- Verify one-account Journal and Reports populations.
- Set a display currency and inspect missing or stale conversions.
- Mark duplicated or copied decisions before interpreting total trade count.
- Save account, date, currency, and eligibility definitions with every comparison.
- Return to the underlying trades before changing a strategy or risk rule.
Methodology Note
This September 9, 2026 correction was checked against the local account-scope resolver, Journal scope and account-management paths, Dashboard and Reports scope contracts, observed analytics currency normalization, Coach evidence scope, backtester population labels, and prop replay rule resolver. Focused account-scope, journal-account, observed-analytics, and replay tests passed in the reviewed code.
Product behavior described here is current implementation evidence, not a promise that every third-party route supplies complete account, currency, fee, or lifecycle fields. See our editorial methodology.
Final Verdict: One Journal, Many Account Boundaries
A unified journal is strongest when it lets you move between operational overview and exact attribution without losing either. Preserve each account and lifecycle, reconcile the source, declare the scope, normalize money only when conversion is complete, and treat copied exposure and prop rules explicitly.
The result is not “one number for the trading business.” It is a traceable system that can show which accounts belong in a question, which rows support the answer, which conversions or fields are missing, and where the next review should begin.
