Skip to content
PineForge

Why TradingView shows one more trade than your backtester

5 min read

The extra trade is the last one: a position still open when the data ran out, which TradingView books as a closed trade at the final bar’s close. What that row is, why it moves your statistics, and how PineForge books it.

Your strategy shows one more trade on TradingView than in your backtester. The extra trade is the last one in the list. Its exit signal reads Open, or is empty, and its exit price is simply where the final bar closed.

Neither tool is broken. That row is how TradingView reports a position still open when the data runs out, and a backtester that leaves it out disagrees with TradingView on the trade count, the net profit and every statistic built on them.

What TradingView books

A backtest stops at its last bar, and nothing makes the strategy flat there. TradingView's report does not drop the open position. It books it as a closed trade whose exit is the range's last bar at that bar's close, and counts it like any other trade. PineForge emulates that rule; the engine's header describes it.

Here is one from the public corpus. stats-eventrades-zero-pnl-count-01 buys one unit on the midnight UTC bar, filled at the next bar's open, and sells it with a limit at that entry price. Its last long never got back to that price. TradingView's trade list (times in the Asia/Taipei zone, so 08:00 is midnight UTC):

Trade number,Type,Date and time,Signal,Price USDT,...,Net PnL USDT,...
140,Exit long,2026-05-01 08:00,,2261.44,...,-2525.12,...
140,Entry long,2025-08-25 08:15,even-trade entry,4786.56,...,-2525.12,...

Look at the exit row: no signal, and a price that is just the last bar's close. The strategy never sold. The −2,525.12 is a paper loss on a position held for eight months, yet it sits in the trade list and in the net profit as if it had been realized.

The row has two spellings. TradingView's own CSV export of the trade list writes Open in the Signal column (this strategy's earlier export did). TradingView's deep-backtest report leaves it empty, and so do most corpus files today, as above (grader).

Why one row matters

On a slow strategy or a short range, the open position can be most of the result. On daily charts it is often the only trade in the window: before PineForge booked this row, it reported no trades at all on such strategies, while TradingView reported one. Every figure computed from the trade list moves with it: the count, the win rate, the net profit, the average trade.

What PineForge books

The engine used to export closed trades only. It now books the row TradingView books: one per lot still open after the last bar, dated on that bar, priced at its close rounded to the tick, with commission but no slippage, because the row "is a mark, not an order" (engine guide). Its trade list marks the row in a last column:

Trade #,Type,Date and time,Price,Qty,Net PnL,...,Engine range-end
140,Exit long,2026-05-01 00:00,2261.440000,1,-2525.120000,...,open

Same bar, same price and the same loss as TradingView, with open saying it is a mark. The script itself never sees the row: inside the run the position is still open, so Pine's strategy.closedtrades does not count it, and the engine's docs say to filter the row out when you want to match that variable (Pine-to-native map).

Where the data stops sets the price

The mark is booked on the backtester's last bar, so that bar has to be TradingView's last bar. TradingView's range ends with the last bar that opens at or before midnight UTC of the end date (harness). The corpus's price file runs on past that, to 4 May. Fed the whole file, the engine would book trade 140 on that day's last bar, at 2,365.09: about 4.6 % above TradingView's 2,261.44 (same file), so the harness cuts the data at TradingView's last bar before the run.

The engine's grader then pairs the two rows like any other trade, and grades their exit price and P&L like any other trade's. Only when TradingView spells the row Open does it treat the pair as a mark against a mark: matched and counted, the entry checked, the exit and P&L left out of the grade, and the P&L agreement reported to the cent (grader).

29 strategies, one more trade

When we regenerated the corpus's trade lists with the current engine, 29 of its 312 strategies changed their trade count. In 26 of them, one of the new trades is this row. The other three gained a closed trade because TradingView's own lists had been updated to run through the end of the day.

The old list for stats-eventrades-zero-pnl-count-01 had still received the grader's top grade. The grader trims trades at either edge of the window both lists cover, so that one extra trade at the start or the end cannot fail a strategy. Here the trimming hid a missing one: the old report graded 139 trades a side while TradingView listed 140; the new one grades 140 against 140.

PineForge's trade lists for 131 of the 312 corpus strategies end with a position still open, more than four in ten (corpus README).

What this means for you

  • If TradingView shows one trade more than your backtester and the extra one is the last, look for a position still open at the end. That is TradingView's normal behaviour.
  • TradingView's net profit and win rate include that position at the last close. For realized results only, drop the last trade if its exit signal is Open or empty; in PineForge's list it is the one marked open.
  • Before comparing two backtests, make both stop at the same bar: the last one that opens by midnight UTC of TradingView's end date.

Measured on 2026-10-02 with PineForge engine and codegen 1.0.1, the releases of that day.

Where to go from here