--- title: "Calculating P&L When a Trade Spans Multiple Sessions" url: https://daily.dev/posts/calculating-p-l-when-a-trade-spans-multiple-sessions-gxmidzabs source_url: https://seriousalchemy.com/pnl-sessions type: article source: "ElixirStatus" published: 2026-08-06T15:29:21.020Z updated: 2026-08-06T15:29:53.183Z tags: ["elixir"] reading_time: 8 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Calculating P&L When a Trade Spans Multiple Sessions **[ElixirStatus](https://daily.dev/sources/elixirstatus)** · 8 min read · 0 upvotes · 0 comments ## Summary A futures trading system built in Elixir uses strategy-based sessions (not calendar days) that can rotate during an open position. When a stop-loss order placed in session A fills after a reoptimization starts session B, the system files it as a new order under session B — leaving the original order stuck as 'working' in session A. This creates a duplicate: one unfilled record in the old session and one filled record in the new session. The FIFO trade matcher, scoped to a single session, sees only the orphaned sell in session B, interprets it as the opening leg of a short, and when a genuine new buy arrives, pairs it against that phantom short. The result is a fabricated gain on a trade that never happened, a real loss that goes unrecorded, and a genuine new entry consumed as the closing leg of a fiction. The naive fix of looking back one session is insufficient because orders can outlive multiple reoptimizations. The correct approach is to find the last point the account was genuinely flat and match all filled orders forward from that boundary across however many session rotations occurred. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What happens to a resting stop-loss order in a trading system when a session rotation occurs while the order is still working? The stop-loss retains its association with the original session permanently — nothing migrates it. When the fill arrives after the session swap, the system files it as a new order under the new session. The old session's stop record remains stuck as 'working'. This creates two records of one order across two sessions, with only one copy ever filled, corrupting both position tracking and trade accounting. _Developers building trading or reconciliation systems track edge cases like this on daily.dev._ ### Why is 'look back one session' an insufficient fix for cross-session trade matching in a FIFO matcher? A resting order can outlive more than one session rotation if the market is quiet and the strategy keeps re-triggering. 'One session back' is an arbitrary bound that fails silently under the same conditions as the original bug. The correct fix is to find the last point the account was genuinely flat, then match all filled orders forward from that boundary across however many session rotations occurred. _Engineers solving ledger correctness problems in event-driven systems find related postmortems on daily.dev._ ## Similar posts on daily.dev - [Designing Data Flow in an Elixir Trading System](https://daily.dev/posts/designing-data-flow-in-an-elixir-trading-system-osvsj2vrv) · ElixirStatus · 0 upvotes · 0 comments - [Medium](https://daily.dev/posts/medium-r13olihte) · Medium · 0 upvotes · 0 comments --- Tags: [#elixir](https://daily.dev/tags/elixir) [View this post on daily.dev](https://daily.dev/posts/calculating-p-l-when-a-trade-spans-multiple-sessions-gxmidzabs)