There's a quiet data-quality bug hiding in most TradingView Strategy Tester exports, and it isn't a bug in TradingView — it's a formatting decision that becomes a trap the moment you analyze the file downstream. If your strategy had a position open when you exported, TradingView writes that open position into the "List of trades" sheet as if it were a completed trade: a normal-looking exit row, priced at the current market and timestamped at the moment you clicked export. Nothing in the row says "this trade hasn't actually closed."
Feed that list into any analysis — a pivot table, a script, a win-rate formula — and every closed-trade statistic silently absorbs one trade that never happened. This guide covers how to recognize the fake row, why it distorts more than you'd expect, and the concrete checks that detect it reliably.
What TradingView actually writes
The Strategy Tester export (the mechanics are covered in How to Export TradingView Strategy Tester Results to Excel) contains several sheets — Performance, Trades analysis, List of trades, Properties. The List of trades records every entry and exit. For a position still open at export time, TradingView has a formatting problem: the list format requires an exit row, so it synthesizes one. The synthesized row uses the last available price as the "exit price" and the export moment as the "exit time," and reports the position's unrealized P&L as if it were realized.
The result is a row that is structurally indistinguishable from a real trade — same columns, plausible values — but that describes a snapshot of an open position, not an outcome.
The symptoms
Three things give the fake row away, and they're worth checking on every export:
- The last trade's exit time is suspiciously close to when you exported. If you exported at 14:32 and the final exit datetime in the list is 14:30 or 14:32 on the same day, that's almost certainly the open position, not a real exit that happened to coincide with your click.
- The last trade's P&L drifts between exports. Export the same strategy twice an hour apart without any trade closing, and every row is identical except the last one, whose "exit price" and P&L have moved with the market. Real closed trades don't change retroactively; unrealized snapshots do.
- Trade counts don't match across sheets. The "Trades analysis" sheet reports counts of closed trades. If the List of trades contains one more trade than Trades analysis accounts for, the extra one is the open position.
Why one row does so much damage
It's tempting to shrug — one trade among hundreds. But the contamination isn't proportional to one row:
- Recency-weighted analysis is hit hardest. The fake row is always the most recent trade. Any rolling-window, last-quarter, or "how has the strategy done lately" view gives it maximal weight — and its value is literally whatever the market happened to be doing at export time.
- It can be an outlier. A long-running open position can carry unrealized P&L far larger than a typical closed trade, moving aggregate net profit, average trade, and profit factor by several percent on its own.
- It corrupts reconciliation. Sum the P&L column and compare against the Performance sheet's net profit, and the numbers won't tie out — the Performance sheet separates realized net profit from "Open P&L," while your summed list mixes them. Hours have been lost to this "discrepancy."
- It poisons derived metrics. Win rate, Sharpe, Sortino, per-hour breakdowns — every statistic built on the trade list inherits one observation that isn't an observation. For ratios built from the return series (see Sharpe vs Sortino Ratio for Trading Strategies), a large unrealized swing sitting at the end of the series is exactly the kind of outlier that moves the result.
A two-minute reproduction you can try
If you want to see the mechanism directly rather than take it on faith: pick any strategy that currently shows an open position in the Strategy Tester, export the report, wait ten minutes while the market moves, and export it again without letting any trade close. Compare the two List of trades sheets row by row. Every row will match exactly — except the final one, whose exit price, exit time, and P&L will all have changed between files. That final row is not a record of anything; it's a live quote wearing a trade's clothes. Once you've seen the same "trade" report two different outcomes ten minutes apart, the need to separate it from the real rows stops being abstract.
How to detect it reliably
No single check is bulletproof, so use them together — this combination is also how DataViz Studio's parser detects open positions automatically:
- Check the Performance sheet for an "Open P&L" field. If it's present and non-zero, the export contains an open position and the List of trades includes its synthetic exit row. This is the most direct signal.
- Compare trade counts. Count trades in the List of trades and compare against the total in the Trades analysis sheet. A mismatch of one (per open position) confirms which rows are synthetic.
- Reconcile summed P&L against net profit. Sum the trade list's P&L and compare with the Performance sheet's net profit. If they differ by approximately the Open P&L amount, the difference is the open position.
- Sanity-check the last exit timestamp. An exit datetime within minutes of the export moment, on a strategy that doesn't normally exit at that time, is the behavioral tell.
How to handle it once found
The fix is separation, not deletion. The open position is real information — you just can't treat it as a closed outcome:
- Exclude the synthetic row from all closed-trade metrics. Win rate, profit factor, average trade, drawdown, hourly breakdowns, and risk ratios should be computed on closed trades only.
- Report Open P&L as its own line. "Closed P&L: $8,400 · Open position: long, +$310 unrealized" is accurate; "Net P&L: $8,710" is a number that will be different tomorrow.
- Re-run the check on every fresh export. Whether an open row exists depends on the moment you exported. The same strategy can produce a clean file today and a contaminated one tomorrow.
DataViz Studio applies this handling automatically: uploads are scanned using the detection methods above, open positions are flagged and stored separately from closed trades, and the dashboard shows Closed P&L and Open P&L as distinct figures so no closed-trade statistic ever includes an unrealized snapshot. If you just want a quick sanity check on a single file, the free instant report parses your export in memory — no signup, nothing stored — and computes its statistics on the closed trades.
The broader lesson
The open-position trap is a specific instance of a general rule: an export is a snapshot serialized into a format designed for something else. The List of trades format assumes every position has an ending; reality at export time doesn't always cooperate, so the format papers over the gap with a synthetic row. Similar format-versus-reality gaps exist elsewhere in the export — timestamps carry no timezone metadata, and summary sheets round differently than the trade list. Before trusting any downstream statistic, it's worth understanding what each number in the file actually represents; that's the subject of TradingView Backtest Metrics Explained.
The two-line takeaway: if your strategy can hold positions overnight, assume every export contains a fake final trade until proven otherwise. Check Open P&L, reconcile the counts, and keep unrealized P&L out of your closed-trade statistics — the five minutes of verification is cheaper than analyzing a dataset with a moving target embedded in it.