The answer: combine Position History with Cash History
In our private FTMO Futures test, Tradovate Position History carried closed-trade results while Cash History carried commissions and fees. Importing the position report alone would have overstated net performance. We joined the two evidence streams, preserved row identity and reconciled gross result minus identified costs to the FTMO dashboard before the trades entered the journal.
This is a hands-on workflow for the observed route, not a promise that every future file variant will map without review.
What the private account actually proved
The tested account activated through the FTMO Futures dashboard and used Tradovate as the core trading environment. The dashboard exposed objectives and account state. Tradovate reporting exposed the execution history needed for reconciliation. We did not request a payout, test every supported front end, or treat the small account sample as a population study.
Export the two evidence streams before editing anything
Save the original Position History and Cash History files as immutable source artifacts. Record the account identifier, export time, requested date range, platform timezone and file hashes. Do not clean column names or delete rows in the originals. Build a separate normalized copy so every transformed value can be traced back.
Position History should preserve source row identity, instrument, side, quantity, open and close timestamps, and gross result. Cash History should preserve fee row identity, timestamp, amount, type and any execution or position reference available in the export.
Normalize identity before joining fees
The safest join uses stable source identifiers. If the reports expose a shared execution, order or position ID, retain it exactly and use it before a time-and-symbol heuristic. When no stable key exists, a probabilistic match needs explicit confidence and a review queue; it must not silently attach a fee to the nearest trade.
Normalize timestamps to one documented zone without discarding the original. Preserve symbols as reported, then map aliases in a separate field. Do not merge partial fills merely to make the trade count look cleaner—the journal can derive round trips while keeping the source executions auditable.
Reconciliation comes before analytics
For the observed files, the controlling identity was gross closed result minus identified commissions and fees equals net result. Sum the source reports over the same date and account scope, compare the computed net with the dashboard, and record the residual. A non-zero residual is a blocker for rule replay when it can change a daily threshold or drawdown event.
The commission guide explains why a small gross edge can disappear after costs. This workflow applies the same principle before any prop-rule conclusion.
Rebuild program days only after net rows balance
Once trade-level evidence reconciles, group it by the official program session boundary. A local midnight split can change daily loss, best-day consistency, qualifying days and the EOD floor. Store both execution timestamps and derived program date. Rebuilding days before fee matching can put costs on the wrong session.
The EOD drawdown guide uses those ordered daily states. The consistency guide uses the same day boundaries for numerator and denominator.
Import validation has three separate counts
Keep source rows, normalized executions and derived round trips as different denominators. A position file can contain several fills for one closed trade, and a cash file can contain several cost rows. Saying “nine trades” without naming the layer can make later totals look as if hundreds of thousands of TSB imports disappeared.
TSB has processed 600K+ cumulative imported trades across 330 recognized source profiles. That product-scale counter is not the denominator of this private sample. The bundle must report its own eligible account count, source-row count, normalized execution count and derived round-trip count.
Unknown rows stay visible instead of disappearing
A cash-history row can be real even when it cannot be tied safely to one closed position. Keep it in an unresolved-cost bucket with its source ID, amount and timestamp. The account-level reconciliation may still prove that the total cost belongs to the export window, while the trade-level allocation remains unknown. Do not spread the residual evenly across trades merely to make every row look complete.
The same rule applies to cancelled orders, rejected fills, adjustments and corrections. Preserve the source event and classify what is known. Analytics that require a trade-level net result should exclude or visibly flag affected rows; account-level net P&L can remain usable when its denominator and residual treatment are explicit.
Re-import must be idempotent
Downloading an overlapping date range should not double the journal. Build a stable import identity from the source account, source type and immutable row identifier. When Tradovate does not expose one reliable ID across exports, derive a versioned fingerprint from the smallest stable field set and route collisions to review. Never use the row number in the downloaded file as the only identity; sorting or a wider date range can change it.
A dry-run should classify every normalized row as new, exact duplicate, changed source record, ambiguous collision or rejected. Changed rows need before/after evidence and a reason. The importer should write only the approved new or corrected rows, then record the batch ID and hashes needed to reverse that batch without touching later imports.
The workflow does not need platform credentials
The observed route used downloaded reports. TSB did not need to retain Tradovate login credentials or FTMO platform credentials for the reconciliation. That is a security advantage only when the exported files are handled safely: restrict access, avoid public web roots, remove unnecessary personal identifiers from review bundles, and never paste private account tokens into article HTML or screenshots.
A CSV can still be sensitive. It may expose account identifiers, instrument history, timestamps and financial results. Keep the original in the restricted evidence store; use a redacted derivative for editorial screenshots. The public article should demonstrate the method without shipping the reader's raw file.
Platform support and import support are different claims
The reviewed launch catalog lists Tradovate, TradingView and NinjaTrader as platform routes. Our hands-on export evidence covers the observed Tradovate workflow. It does not prove that a TradingView front end produces a distinct downloadable file or that every NinjaTrader connection maps to the same report schema. Platform availability belongs to the program card; import coverage belongs to an exact source profile and version.
If a reader trades through another front end but the official account still settles through Tradovate, verify which backend report is authoritative before selecting an importer. If the source cannot be identified, show Not verified and request a sample rather than picking the closest logo. The broader hands-on FTMO Futures review keeps platform experience separate from universal compatibility.
What the final reconciliation record should contain
Store the two source hashes, export window, account and source-profile identifiers, parser version, original and normalized row counts, unmatched rows, duplicate decisions, gross total, identified costs, computed net, dashboard net, residual, reviewer and timestamp. The record should make it possible to reproduce the same result after the article, parser or catalog has changed.
Then attach derived daily states and round trips to that immutable reconciliation ID. If a later source correction changes a cash row, create a new version and show which rule outcomes changed. Silent mutation destroys the evidence chain that makes a prop-rule replay defensible.
A safe import checklist
- Save untouched source files and hashes.
- Confirm account identity, date range and timezone.
- Normalize rows without deleting source IDs.
- Join cost rows by stable identifiers or flag uncertain matches.
- Reconcile gross, fees and net to the source dashboard.
- Build program-day and round-trip views as derived layers.
- Dry-run the import, compare counts and totals, then commit only the approved rows.
See the general CSV import guide for format validation and rollback discipline. The FTMO Futures review remains the broader product context.
Import a representative history and test the exact rule path in TSBBottom line
Do not import the observed FTMO Futures Tradovate Position History as if it already contains net trades. Preserve Position and Cash histories, reconcile costs to the dashboard, name every denominator, and only then derive journal trades and rule days. The workflow is strong because it is auditable—not because one small private sample proves every future export.
