You finish a strategy, run it through the Strategy Tester, and see a number that makes you smile. Net profit: 35%. Sharpe ratio: 1.8. Maximum drawdown: 12%. You are ready to go live. Then you deploy, trade for a month, and the results are nowhere close to the backtest. The strategy did not break. The backtest was never real.
This is not an uncommon experience. The gap between backtest and live performance rarely comes from the strategy logic itself. It comes from two costs that the Strategy Tester models poorly by default: slippage and commission. Understanding exactly how these work, why they matter more than you think, and how to account for them in Pine Script is the difference between backtest optimism and live viability.
What commission actually costs
Commission is the explicit fee you pay on every trade. It goes to the broker, the exchange, and sometimes a clearinghouse. On futures contracts, it is a fixed dollar amount per contract. On forex and equities, it is usually a percentage of the notional value or a flat per-share fee. What matters is not the dollar amount itself but how it compounds against your trade frequency.
A strategy that executes 500 trades per year with $2 commission per round turn pays $1,000 in fees before any profit or loss. On a $10,000 account, that is 10% of capital gone before you even start. The Strategy Tester shows this number if you configure it, but many traders leave the default commission at zero or a symbolic value, and the backtest inflates accordingly.
The fix in Pine Script is straightforward. The strategy declaration accepts commission_type and commission_value parameters. Setting these correctly means using the actual commission your broker charges. For futures traders on TradingView, this is typically visible in the contract specifications for each instrument. For forex and equities, it is the fee structure in your broker account. The Strategy Tester metrics guide covers how commission affects the net profit line and why ignoring it is the single most common backtest inflation error.
What slippage actually is
Slippage is the difference between the price you expected to get and the price you actually got. In a backtest, when your code calls strategy.entry() or strategy.order(), TradingView fills it at the exact price your logic specifies. In live trading, that order sits in a queue, the market moves, and the fill arrives at a different price.
Slippage favors you when the market gaps in your direction and works against you when it gaps against you. Over a large number of trades, the asymmetric nature of slippage becomes a systematic cost. Market orders that cross the spread always experience negative slippage on entry. Stop orders that trigger after a gap fill at a worse price than expected are another common source. The average trader pays more in slippage than they realize because it is invisible in the backtest and only shows up in real-time P&L.
A common rule of thumb is to assume 1 tick of slippage per side for futures and a few pips for forex. This is a starting point, but it underestimates the real cost in volatile markets or thinly traded instruments. The more accurate approach is to measure your actual fills over a period of live trading and compare the execution price to the signal price, then use that average as your slippage assumption for future backtests.
How slippage compounds in high-frequency strategies
Slippage is not a fixed cost like commission. It scales with the number of trades and with market volatility. A strategy that generates 10 signals per day experiences slippage 10 times more than a strategy that generates 1 signal per week, all else equal. This makes slippage a structural enemy of high-frequency approaches.
Consider a mean reversion strategy that enters on a 2% pullback and exits on a 1% gain. In the backtest, each trade captures 1% minus commission. In live trading, if the average slippage is 0.3% per trade, the entry costs 0.3% and the exit costs 0.3%, reducing the net capture from 1% to 0.4%. The win rate stays the same, the average win stays the same, but the net profit drops by 60%. This is why strategies that look exceptional in the Tester often fail in live trading. The backtest assumes every entry and exit happens at the signal price. Reality does not.
The parameter that controls this in Pine Script is not a single setting but a design decision. Using market orders produces more slippage than using limit orders, which only fill at your price or better. Usingstrategy.entry() with immediate_or_queue mode behaves differently than strategy.order() with market execution. Choosing the right order type for your strategy is the slippage mitigation tool that works before backtesting even begins.
Setting these parameters in Pine Script
The Pine Script strategy declaration supports several parameters that control how the backtest models transaction costs. The most important ones are commission_type, commission_value, slippage, and the margin-related settings that affect position sizing.
Commission_type accepts three values: commission_type.cash_per_order, commission_type.cash_per_contract, and commission_type.percent. For futures, commission_type.cash_per_contract with the per-contract fee is the correct choice. For equities and crypto, commission_type.percent with the percentage fee works. The commission_value is the number that goes with it.
Slippage is set through the slippage parameter in strategy.entry and related functions, specifying the maximum slippage in ticks or points. However, the more practical approach is to model the expected slippage by adjusting your entry and exit prices in the code itself, especially when testing conservative assumptions. This gives you full control over the slippage model rather than relying on the default behavior.
The critical discipline is to set these before you run your first serious backtest. An empty commission field produces a backtest that is fundamentally different from live trading, regardless of how sound your entry and exit logic is. The position sizing guide covers how commission and slippage affect the sizing calculation and why a strategy that looks well-sized in the Tester may be over-leveraged in live trading.
The realistic backtest workflow
Start with your strategy logic and run it with zero commission and zero slippage. This establishes the theoretical upper bound of what the logic can produce. Then add commission at the exact rate your broker charges. Then add slippage using a conservative estimate. The difference between the zero-cost and the real-cost results tells you whether the strategy survives transaction costs.
If the real-cost backtest shows a positive expectancy, you have a candidate. If it does not, the strategy may still work in live trading if your actual slippage is lower than the assumption, but it is safer to design the strategy to be profitable at the assumed cost rather than relying on optimistic slippage estimates. This is the practice that separates traders who lose money live from traders who see their backtest results confirmed in real time.
Setting these correctly in your Pine Script strategy() declaration is the single change that most reliably narrows the backtest-to-live gap. It takes 30 seconds to add the right commission values. It takes much longer to recover from months of trading a strategy that was only profitable in an idealized backtest environment.
Once your strategy has realistic transaction costs configured, the next step is converting your indicator logic into a strategy that the Strategy Tester can evaluate. The indicator to strategy guide walks through exactly how to do that, and PineScripter generates the strategy code with all the correct parameters from a plain English description of your rules, including the commission and slippage settings you specify.
Disclaimer: PineScripter is a coding tool for Pine Script development. It does not provide financial advice and does not guarantee trading profits. Always backtest strategies thoroughly and understand the risks before live trading.