“Auto-import everything” needs one boundary: import every execution record that your verified route can supply and your journal can recognize. It does not mean every broker, product, field, open position, or private trading note is captured perfectly. The winning workflow removes repetitive transcription while keeping a short reconciliation step.
What “Stop Manually Logging Trades” Actually Means
Manual journaling mixes two different jobs. The first is copying execution facts: instrument, side, quantity, fill time, fill price, fees, and realized result. The second is adding information that did not exist in the execution record: the setup you intended, the rule you followed, the screenshot you reviewed, and the reason you exited. Automation is excellent at the first job when the source and field mapping are verified. It cannot honestly invent the second.
The practical goal is therefore not zero human involvement. It is one authoritative execution record, imported once, checked once, then enriched only where human context matters. That is a much stronger system than either retyping every fill or assuming a green “connected” badge proves the ledger is complete.
If you are still deciding what the journal must contain, start with the fields worth tracking in a trading journal. Import design becomes simpler once execution facts, derived metrics, and discretionary notes have separate owners.
Step 1: Choose the Authoritative Source Record
Before connecting anything, decide which statement or export settles a disagreement. For a broker account, that may be the broker’s activity statement. For an exchange account, it may be the official fills or executions history. For MetaTrader, it may be the account-history report from the exact terminal and account. Your journal is the analysis layer; it should be able to trace imported rows back to that source.
Record four things for each account:
- Source identity: broker, exchange, platform, account ID, and whether the account is live, demo, or funded.
- Time boundary: timezone, import start date, and whether timestamps represent order, fill, or close time.
- Money boundary: account currency and whether commission, swap, funding, rebates, and other cash movements are included.
- Position boundary: whether the source exports fills, orders, positions, closed trades, or some combination.
This small contract prevents the most expensive import mistake: comparing two reports that group the same executions differently and treating the difference as missing data.
Step 2: Choose the Best Verified Import Route
There is no universally best route. The best route is the most automatic method that is explicitly supported for your exact source and still exposes enough evidence to reconcile the result. Check the live supported-source directory before connecting; a platform name alone does not guarantee every broker, asset class, account type, or historical field.
Direct broker or exchange connection
A supported API or OAuth connection can reduce repeat exports and keep the ledger current. It is usually the lowest-friction route for a source that exposes the required history. But “API support” is not a single capability. Confirm the exact venue, market, account type, history window, pagination behavior, and fields before relying on it.
Use read-only or least-privilege credentials. Disable trading, transfers, and withdrawals wherever the provider offers those controls. Store the account label and last successful sync time, then test revocation so you know how to disconnect the journal deliberately.
MT4 and MT5 EA sync
MetaTrader Expert Advisor sync can remove recurring exports, but MT4 and MT5 are separate paths and neither implies universal support across every broker or symbol type. The terminal or approved runtime must be available, the EA must remain active, and the exact account must be selected. A successful installation is only the beginning; verify a closed execution, its costs, and its timestamps against the terminal history.
If continuous EA sync is not suitable, a MetaTrader report can be a controlled file-import route. Treat the report as a dated batch with an explicit range, not as proof that every possible MetaTrader field will map automatically.
Recognized file import
CSV, TSV, JSON, and HTML are useful because they create a reviewable artifact. They are not automatically universal: column names, decimal conventions, currencies, identifiers, and row meanings vary. A recognized import profile should preview the mapping and reject ambiguity rather than silently guessing.
File imports work especially well for historical backfill and periodic sources. Save the original file, note its inclusive date range, and avoid overlapping batches until duplicate behavior is understood. For a durable end-to-end setup, use the trading-journal build workflow to separate ingestion, normalization, analysis, and review.
TradingView capture and supported activity imports
Some workflows start from a charting or activity surface rather than a traditional broker export. These can be useful when the journal supports the exact capture route, but the same rule applies: inspect which record type arrived and what did not. A screenshot or alert is context; it is not a substitute for an authoritative fill record.
Manual entry as an exception path
Manual entry remains valuable for unsupported executions, corrections with documented provenance, and context that no broker knows. Keep it explicit. A manually created row should say why it exists and should not masquerade as an imported fill. This turns manual work from the default pipeline into a small, auditable exception queue.
Import Routes: What Each One Proves
| Route | Best use | What to verify | Typical failure signal |
|---|---|---|---|
| Supported API or OAuth | Ongoing account history | Exact venue, market, permissions, backfill, pagination, costs | Stale last-sync time or a source total that no longer matches |
| MT4 or MT5 EA | Ongoing MetaTrader account sync | Correct terminal, account, runtime, closed execution, commission and swap | EA inactive, terminal unavailable, or new closes absent |
| Recognized file | Historical backfill or controlled batches | Profile match, columns, timezone, currency, range, duplicates | Rejected rows, unexpected zeroes, or overlapping batches |
| Supported activity capture | Specific charting or platform workflow | Record type, account scope, and execution completeness | Context arrives without a reconcilable fill |
| Manual exception | Unsupported record or qualitative context | Reason, provenance, account, and non-duplication | Manual rows become the undocumented default |
Step 3: Reconcile Before You Trust the Dashboard
A polished equity curve can still be built from an incomplete ledger. Run a small validation window first: a date range you can inspect directly in the authoritative source. Compare the result at both the record level and the aggregate level.
- Count records consistently. Decide whether you are counting fills, orders, positions, or journal trades. Do not compare one unit with another.
- Match quantities and direction. Check partial fills, scale-ins, scale-outs, reversals, and position grouping.
- Match realized money. Compare gross result, commission, swap or funding, other costs, and net result in the correct currency.
- Match time. Confirm timezone and whether the journal uses entry, exit, or individual-fill timestamps.
- Check exclusions. Open positions, deposits, withdrawals, transfers, rebates, expired orders, and non-trade cash movements may follow different rules.
- Re-import deliberately. Repeat the same window and confirm that stable identifiers or duplicate controls prevent double counting.
Only expand the backfill after that window passes. This is faster than importing years of history and debugging a mystery difference after every chart has been built on top of it.
Step 4: Migrate Without Duplicating the Ledger
Pause the old manual workflow at a written cutoff. Export or connect one account, import one bounded window, reconcile it, and then extend backward or forward. If multiple platforms feed the same economic position, do not merge them merely because the symbols look similar. Keep source account and source record IDs intact.
A safe migration sequence is:
- Back up the existing journal and source exports.
- Choose the cutoff timestamp and account timezone.
- Test a small range that includes a partial fill, a fee, and at least one losing trade if available.
- Resolve mapping exceptions before increasing the range.
- Import the remaining history in non-overlapping batches.
- Freeze the old ledger or label it archival so it cannot be edited in parallel.
Newer journal users can follow the same sequence with less cleanup; the beginner journal guide shows how to start with a minimal schema before adding analysis.
Step 5: Add Only the Context Automation Cannot Know
An execution source knows what happened in the account. It usually does not know the trade thesis, invalidation rule, expected setup, emotional state, or whether the action followed the plan. Those are human claims and should remain visibly separate from imported facts.
Use a short, repeatable post-trade layer:
- select the setup and playbook version;
- mark the rule followed or violated;
- attach the chart or evidence needed for review;
- write one observation without turning it into a diagnosis;
- leave unknown fields unknown instead of filling them from memory.
This is not “manual logging” in the old sense. It is a decision record attached to already imported execution evidence. For sensitive data, use the controls in the trading-journal data security guide when deciding what should be stored, shared, exported, or deleted.
Step 6: Monitor Freshness and Completeness
Automation moves the failure from visible typing effort to less-visible synchronization risk. Give the pipeline a small control panel:
- last successful sync by source and account;
- latest imported execution timestamp;
- rejected or unmapped row count;
- duplicate or conflict count;
- credential or runtime status;
- the last reconciled date range.
Review those signals on a schedule suited to how often you trade. A stale connection should be obvious before a performance review, not discovered because a dashboard suddenly looks unusually good.
Where TSB Fits
TSB is our product. Its strongest role here is not a promise to support every imaginable source. It is a canonical import and normalization layer with 330 recognized import profiles, prop-rule tracking, evidence review, and a lifetime-access option rendered from product truth below. The system has processed 600K+ imported trades; that is operational scale, not proof that any individual trader will improve.
Use the exact supported-source directory and preview for your account, then reconcile a bounded sample before relying on analytics. If your route is unsupported or a field cannot be verified, the honest state is Not verified, followed by a file route or manual exception—not a fabricated mapping.
Practical test: import one representative window, match its records and net result to the source, then add only the setup and rule context the source could not know. Test your import route
Common Auto-Import Failures
A connection is treated as proof of completeness
A successful credential check proves access, not historical coverage or field completeness. Compare a bounded window before trusting the full dashboard.
Fills, orders, and trades are counted as the same thing
One position can contain several fills and several orders. Define the unit before comparing counts or calculating trade-level statistics.
Costs disappear during normalization
Gross profit can match while net profit does not. Commission, swap, funding, rebates, and currency conversion require their own checks.
Overlapping files create duplicates
Stable source identifiers are preferable. When they are absent, preserve filenames, ranges, and import batch IDs so overlap can be detected and rolled back.
Qualitative notes are presented as imported facts
A model may organize or summarize supplied notes, but it should not infer psychology, intent, or causality from executions alone. Missing evidence should remain missing.
How We Built This Guide
- Scope: separate authoritative execution evidence, import normalization, derived analytics, and human context.
- Product claims: TSB routes, coverage, plan, and verified date come from canonical server product/provider truth rather than literal article copy.
- Safety boundary: provider support is exact to a source, market, route, and status; platform-family names are not universal guarantees.
- Evidence boundary: connection success, row presence, completeness, and analytical usefulness are different tests.
Our editorial methodology and evidence rules explain how facts, observations, inferences, and unknowns are separated.
Bottom Line
Stop retyping execution data that a verified route can import. Keep the authoritative source, test the exact route on a representative window, reconcile counts and money, monitor freshness, and reserve manual input for context or documented exceptions. That replaces busywork without replacing evidence.
