fableが、私自身の取引レポートの設計上のロジックエラーを説明してくれました。かなり感心しました。

基本的に、EoM残高とPnLを突き合わせ（整合させ）ようとしています。
そのためには、実現PnL（簡単）＋未実現PnLが必要です。

最初の問題はかなり基本的で、すでに解決済みでした：
未実現PnLは、すでに過去の月で計上済みの残高から引き継がれる。

たとえば、残高が$1000あるとして、5月にポジションが+ $100動いたとします。
そのポジションが6月には未実現で$300になっているとしましょう。
5月末の残高は$1,100で、すべてが正しいなら6月は$1,300になるはず。

しかし、ポジションのオープン中の全体の損益（open PnL）をそのまま織り込むと、5月にすでに計上済みの$100が重複してしまうため、取引レポート上の残高は$1,400になるはず、と表示されます。
なので、過去期間の未実現PnLを差し引く必要があります。

少しややこしくなるのは、日次でリバランスをたくさんやっているので、今月のそのポジションの未実現PnLに対して、約定・タイミング・寄与を考慮すべき取引が何千件もあるからです。
ここまでは順調で、基本的なことです。

fableが見つけた問題は、当月の実現PnL（会計上の正しい値）をいつ計上するか、という点でした。
そのとき、過去の月の残高において未実現としてすでに計上されていたPnLの分を織り込まないと、効果を二重計上してしまいます。

先ほどの例で、6月にポジションをクローズすることで、$300の利益を全額ブックするとします。
これは会計士の観点では正しい値です。

ですが、残高トラッカーと一致させるには、未実現PnLから、過去の月で実現／追加された分を取り除く必要があります。
まるで過去月にブックされた値を差し引くような形です。

これは、内部トラッキングと会計目的の間で少し矛盾が生じるのですが、合っていないと自分の値が正しいか常に確信できません。
つまり、正しいのは分かっています。実現取引の交換所レポート（それが会計上いま重要なものだから）のおかげで。
ただ、私はそこも少し几帳面なんです。

これでPnLはEoM残高と完全に一致しました。
もっと早く分かっていればよかった。毎日どんどん頭が悪くなる。問題があるたびにAIを支え（つえ）として使っているからです。