Why your journal should record fills, not trades
Nearly every trading spreadsheet starts the same way: one row per trade. Symbol, entry price, exit price, quantity, profit. It works beautifully right up until the first time you add to a winner.
Then you need a second entry price. So you add Entry 2. Then you take partial profits twice, so you add Exit 1, Exit 2, Exit 3. Now your average entry is a formula referencing six cells, your P&L is a formula referencing twelve, and one of them has a typo you won't find for four months.
The problem isn't the spreadsheet. It's the shape of the data.
A trade is an idea. A fill is an event.
When you decide to buy RELIANCE because it's holding the 10 EMA after a flag, that decision is one trade. It has one setup, one thesis, one initial stop, one risk plan.
But the execution of that idea might be six separate events: buy 100, add 50 the next day, add another 50 on strength, sell a third into the spike, sell another third at the target, and stop out of the rest.
These are two different kinds of thing, and squashing them into one row is what causes all the pain. So Trader Blueprint stores them as two tables:
- Trades — the idea. Symbol, direction, setup, entry tactic, initial stop, planned risk, confidence, your reasoning. Notably: no prices and no P&L.
- Executions — every individual fill. Side (buy or sell), quantity, price, timestamp, and the itemised charges for that fill.
Every execution points back at its parent trade. A trade can have as many as it needs — three fills or thirty.
Everything else is derived
Once the fills are recorded honestly, the numbers you actually care about are arithmetic. Take a real multi-leg trade:
| Sequence | Side | Qty | Price | Value |
|---|---|---|---|---|
| 1 | Buy | 100 | ₹200.00 | ₹20,000 |
| 2 | Buy | 50 | ₹210.00 | ₹10,500 |
| 3 | Sell | 80 | ₹230.00 | ₹18,400 |
| 4 | Sell | 70 | ₹195.00 | ₹13,650 |
From those four rows and nothing else:
- Average buy = ₹30,500 ÷ 150 = ₹203.33
- Average sell = ₹32,050 ÷ 150 = ₹213.67
- Matched quantity = 150 (the position is fully closed)
- Realized P&L = 150 × (213.67 − 203.33) = ₹1,550
One formula covers every case:
RealizedPnL = MatchedQty × (AvgSellPrice − AvgBuyPrice) − TotalChargesIt works for longs. It works for shorts, because selling high and buying low produces the same sign. It works when you scale in and out in any order, because weighted-average cost basis doesn't care about sequence. And it works when the position is only half closed — matched quantity is simply the smaller of the two sides.
There is no field for P&L. Not hidden, not optional — it doesn't exist. A number you can type is a number you can get wrong, and a wrong P&L quietly poisons every statistic downstream of it.
Why weighted average, specifically
There are other cost-basis methods — FIFO, LIFO, specific-lot. They matter enormously for tax accounting and barely at all for judging whether your trading works.
Weighted average was chosen for two reasons. First, it's the only method that stays stable when scale-ins and scale-outs interleave — FIFO produces jumpy, counter-intuitive per-trade results when you're adding and trimming around a core position. Second, it's what most traders already compute by hand, so the numbers match the mental model you already have.
What this buys you
Unlimited pyramiding. Add to a position as many times as your strategy calls for. There's no Entry 4 column to run out of.
Honest partial exits. Sell a third, then another third, then let the rest run for three more weeks. The trade stays open with a correct average and a correct remaining quantity throughout.
R-multiples that can't drift. Planned risk is captured once, at entry, and frozen. If you later trail your stop, your R denominator doesn't move — so a 3R winner is still a 3R winner next year.
Broker imports that can't double up. Each execution can carry the broker's own order ID, with a uniqueness guard on it. Re-import the same statement twice and the duplicates are rejected rather than silently doubling your position.
Auditability. Every derived number can be traced back to the fills that produced it. When a figure looks wrong, you can find out why instead of guessing.
The cost
Honesty requires admitting the trade-off: this model asks for slightly more input. You record four fills instead of filling one row.
In practice the entry form is entry/exit shaped anyway — you type an entry price, quantity and date, then an exit when you have one, and the app translates that into executions underneath. The full execution detail is there when you scale in, and invisible when you don't.
What you get back is a journal whose numbers you never have to double-check.