Backtesting Spreadsheet: Trade Log and Execution Worksheet

Quick answer: A backtesting spreadsheet should preserve two layers of evidence: the settings for each test run and the row-by-row record of every eligible signal or trade. The goal is not to create a prettier profit summary. It is to make the historical test reproducible, expose skipped signals and execution assumptions, and give the later results review a clean source dataset.

Download the free backtesting execution log CSV. It opens in Excel, Google Sheets, Numbers, LibreOffice, or any tool that supports CSV files.

This page owns the during-the-test execution record. Use the backtesting test plan before the run, the complete backtesting guide for the broader workflow, the backtesting results guide after the report exists, and the validation checklist to challenge whether the result can be trusted.

What This Spreadsheet Is—and Is Not

A backtesting spreadsheet is an audit trail for a historical strategy test. Each row should connect a strategy rule to a specific signal, modeled order, exit, cost assumption, and result.

It is not the same as:

Record	Main purpose	When it is used
Backtesting test plan	Fix the hypothesis, rules, data, costs, benchmark, and decision criteria	Before the test
Backtesting execution log	Record what the test actually did, signal by signal and trade by trade	During the test
Backtesting results report	Summarize return, drawdown, trade distribution, and other metrics	After the test
Validation checklist	Check data, fills, overfitting, stability, and out-of-sample evidence	After the report
Trading journal	Review live or simulated decisions, habits, emotions, and process quality	During trading practice or live trading

The distinction matters because aggregated metrics cannot explain every anomaly. A profitable curve may contain skipped losing signals, impossible fills, duplicated orders, missing data, or parameter changes that are invisible in the summary.

TradingView's Strategy Report separates aggregate metrics from a List of Trades, while MetaTrader's tester provides detailed results, a testing journal, trade history, data-quality information, and execution settings. Those platform structures illustrate the same principle: a final scorecard should be traceable to lower-level evidence.

The Two-Layer Structure

A useful worksheet contains run-level fields and row-level fields.

Layer 1: Run-level metadata

These values describe the test as a whole and may repeat on every CSV row or live in a separate worksheet tab.

Field	What to record	Why it matters
`run_id`	Unique name for the run	Prevents results from different tests being mixed
`strategy_version`	Frozen rule version	Connects the output to the exact strategy definition
`parameter_set`	Parameter values used	Makes optimization and sensitivity comparisons traceable
`sample_label`	Development, holdout, walk-forward, or another label	Separates research data from validation data
`data_source`	Vendor, broker, exchange, or exported dataset	Documents where the prices came from
`test_start_date` / `test_end_date`	Requested test dates	Defines the intended sample
`symbol` or universe rule	Instrument or selection rule	Prevents silent universe changes
`timeframe`	Bar interval	Affects signals, sequencing, and fill assumptions
`timezone`	Chart and event clock	Prevents session and timestamp mismatches

Record the effective dates too when the platform changes them. MetaTrader documents that a tester may download preceding history for indicator calculations and can shift the effective start when insufficient history is available. A requested date range and the data actually used are not always identical.

Layer 2: Signal- and trade-level rows

These values describe one eligible decision or one executed trade.

Field group	Suggested columns
Identity	`row_id`, `signal_time`, `setup_id`
Eligibility	`eligible_signal`, `side`, `rule_compliance`
Planned order	`planned_entry`, `planned_stop`, `planned_target`
Modeled order	`modeled_entry`, `quantity`, `modeled_exit`, `exit_reason`
Friction	`commission`, `spread_cost`, `slippage_cost`
Result	`gross_pnl`, `net_pnl`, `r_multiple`
Path	`mfe`, `mae`, `market_regime`
Exceptions	`exception_code`, `notes`

The downloadable CSV contains these fields in a single header row so it can be imported into a spreadsheet, database, notebook, or analysis script.

How to Use the Backtesting Execution Log

1. Create a new run ID

Do not overwrite a prior test when the strategy rules, parameters, data, or execution assumptions change.

A practical naming format is:

strategy-name_version_sample_run-date

For example:

breakout-pullback_v1.0_holdout_2026-07-27

The name is not a performance claim. It is a reference that connects the spreadsheet, test plan, code or chart settings, and exported report.

2. Copy the frozen settings from the test plan

Before recording trades, copy the relevant settings from the pre-test specification:

strategy version;
parameter set;
instrument universe;
timeframe and session;
data source and adjustment policy;
entry and exit logic;
position-sizing rule;
order and fill model;
spread, commission, and slippage assumptions;
development or holdout label.

If any setting changes after the run begins, stop and create a new version or document an explicit exception. Do not silently blend two strategies into one dataset.

3. Record every eligible signal

A common manual-backtesting error is to record only trades the reviewer likes. That turns the sample into a selection exercise rather than a test of the written rule.

For every signal that meets the eligibility conditions:

assign a row_id;
record the historical signal_time;
identify the setup_id;
mark eligible_signal as yes;
record whether a trade was executed or skipped;
explain any skip in exception_code or notes.

A skipped row is still evidence. It can reveal that the rules were ambiguous, the data was incomplete, an order could not be modeled, or discretion was applied inconsistently.

4. Separate requested prices from modeled fills

Do not use one price field for both the strategy instruction and the simulated execution.

planned_entry records the price or rule requested by the strategy.
modeled_entry records the fill produced by the test method.
planned_stop and planned_target preserve the original risk logic.
modeled_exit records the simulated exit.

This distinction becomes important when:

a market order fills on the next bar rather than the signal close;
a stop or limit order is touched inside a bar;
bid and ask prices differ from the chart's displayed price;
spread or slippage changes the fill;
a gap crosses the requested price;
a platform's broker emulator applies a specific intrabar path.

TradingView describes its Broker Emulator as the module that controls fill timing, costs, and the price model. MetaTrader likewise offers different tick and OHLC modeling modes, delay settings, commissions, and instrument specifications. The selected model belongs in the run record.

5. Record costs as separate fields

Do not hide all friction inside one adjusted P&L number.

Keep separate columns for:

commission;
spread cost;
slippage cost;
other fees when relevant;
gross P&L;
net P&L.

Separate fields make sensitivity testing possible. You can later ask whether the result survives a wider spread or less favorable fill assumption without reconstructing the original test.

6. Capture MFE, MAE, and the path—not only the exit

The final result does not show what happened while the position was open.

MFE, maximum favorable excursion, records the largest favorable move during the position.
MAE, maximum adverse excursion, records the largest unfavorable move during the position.

MetaTrader's testing report includes MFE- and MAE-related analysis because the path can reveal different information from the closing result. Two trades with the same net outcome may have experienced very different adverse movement, opportunity, and exit efficiency.

Use consistent units: price, points, percentage, or risk units. Do not mix units inside one column.

7. Tag market regime without rewriting history

A simple market_regime field can help segment results, but the classification rule must be consistent.

Possible labels include:

directional up;
directional down;
range;
high volatility;
low volatility;
event window;
unknown.

Avoid labeling the regime only after seeing whether the trade won. Ideally, define the classification rule in the test plan or use an external series that was available at the time.

8. Preserve exceptions and data problems

Use an exception_code instead of burying every issue in free-form notes.

Example codes:

Code	Meaning
`DATA_GAP`	Required historical data is missing
`TIMEZONE_UNCLEAR`	Bar or event alignment cannot be verified
`AMBIGUOUS_RULE`	The written rule does not produce one clear decision
`INTRABAR_UNKNOWN`	Bar data cannot determine which order level occurred first
`NO_FILL_MODEL`	The test method cannot model the requested order
`SKIPPED_SIGNAL`	An eligible signal was not executed
`PARAMETER_CHANGE`	A setting changed during the run
`DUPLICATE_SIGNAL`	The same event was logged more than once

Exception counts are useful later. A backtest with many unresolved INTRABAR_UNKNOWN rows may require more granular data rather than stronger conclusions.

Copyable Minimum Worksheet

For a lightweight manual test, begin with this smaller table:

Run ID	Row ID	Signal Time	Setup	Eligible?	Side	Planned Entry	Modeled Entry	Stop	Exit	Net Result	R	Regime	Rules Followed?	Exception

Use the downloadable CSV when you need separate cost, MFE, MAE, version, data, and sample fields.

Manual Replay vs Automated Export

The same evidence model works for both methods, but the source differs.

Manual historical replay	Automated backtest
The reviewer records each eligible setup	The engine exports orders, fills, and trades
Rule compliance must be checked manually	Rule execution should be checked against code and logs
Future candles must remain hidden	Look-ahead and repainting must be prevented
Ambiguous chart situations need exception codes	Modeling and data exceptions should be captured from the tester journal
Screenshots can support disputed rows	Configuration files, code versions, and logs support disputed rows

TradingView exposes a metrics section and a List of Trades. MetaTrader provides a Results tab, testing journal, visual mode, order and deal history, and data-quality details. Exported platform data is useful, but preserve the configuration and strategy version that produced it. A trade list without its run settings is incomplete evidence.

Where ChartMini Fits

ChartMini is a lightweight historical chart replay tool for manual price-action and decision practice. It can help you:

keep future candles hidden;
apply a visual setup definition one candle at a time;
record eligible signals in the worksheet;
compare planned and simulated decisions;
review rule consistency across sessions.

ChartMini is not an automated strategy engine. It does not execute coded strategies, optimize parameters, reproduce broker order books, or guarantee realistic spreads, slippage, latency, and fills. For a manual ChartMini session, record intended stops, targets, invalidation, and cost assumptions in the worksheet rather than treating them as broker orders.

For a practice-focused journal that tracks behavior and replay decisions, use the simulated trade log guide. This page is narrower: it records the research evidence for a backtest run.

Common Backtesting Spreadsheet Errors

Recording only executed winners and losers

The missing rows may be the most important evidence. Log eligible signals that were skipped, rejected, or impossible to model.

Changing columns halfway through the sample

A new definition can change what a row means. Version the worksheet schema or create a new run when the recording method changes materially.

Mixing strategy versions

If an entry filter, stop rule, timeframe, or parameter changes, assign a new strategy_version or parameter_set.

Using one P&L field for everything

Keep gross result, commission, spread, slippage, and net result separate.

Treating the displayed chart price as an executable fill

Record the fill convention. A chart value, bid, ask, last trade, bar open, and next-bar execution are not interchangeable.

Deleting exceptions after the report looks good

Retain data gaps, ambiguous cases, and rejected signals. Removing them makes the result harder to reproduce and easier to overstate.

Turning the worksheet into a performance promise

A detailed spreadsheet improves documentation. It does not eliminate selection bias, overfitting, data errors, changing market conditions, execution differences, or live-trading risk.

How This Page Fits the Backtesting Cluster

Use the pages in this order:

Before the test: write the Backtesting Test Plan.
Learn the full method: use How to Backtest a Trading Strategy.
During the run: use this spreadsheet and execution log.
After the run: interpret what backtesting results can and cannot tell you.
Challenge the result: apply the Backtesting Validation Checklist.
Choose another practice method when appropriate: compare Market Replay, Backtesting, and Paper Trading.

Frequently Asked Questions

What should a backtesting spreadsheet record?

A backtesting spreadsheet should record the test run, strategy version, parameter set, data scope, every eligible signal, planned and modeled fills, costs, exits, result, market regime, rule compliance, and any exception that affected the test.

Is a backtesting trade log the same as a trading journal?

No. A backtesting trade log is a research record used to reproduce a historical test. A trading journal usually focuses on a trader's live or simulated decisions, execution habits, emotions, and review notes.

Should skipped signals be included in a backtesting worksheet?

Yes. If a signal met the written eligibility rules, record it even when no trade was taken. Mark the row as skipped and state the reason so discretionary filtering does not disappear from the research record.

Why separate planned entry from modeled entry?

The planned entry records what the strategy requested, while the modeled entry records the price produced by the backtesting or fill assumption. Keeping both fields exposes gaps caused by spread, slippage, bar sequencing, or order logic.

Can I use this CSV for manual and automated backtesting?

Yes. Manual testers can fill the rows during candle-by-candle review, while automated testers can map exported orders and trades into the same columns. Fields that do not apply can be left blank, but the run settings and exceptions should still be preserved.

Does a complete backtesting log prove a strategy will work live?

No. A complete log improves reproducibility and exposes errors, but it cannot reproduce every live fill, cost, liquidity condition, operational failure, or behavioral response. Historical and hypothetical results are not guarantees of future performance.

Official Sources

The downloadable CSV is an educational recordkeeping template. It does not provide trading signals, evaluate a strategy automatically, or guarantee live-market results.