Discussion: Accounting treatment of options trades

[antamy]

As I have been using the application more extensively and loading it up with my trades this year, I have been struggling to make sense of the Monthly page. The data appears to be all over the place and inconsistent between the various panes, charts and tables, and I have not been able to reconcile to my parallel tracking spreadsheet.

I have worked with Claude to do some analysis and, whilst I don't have an overall solution yet to tighten up the numbers, one aspect of the business logic troubles me. In my mind, gains from selling options in a month come from the cash received for the sale of options minus cash spent to buy back options minus commissions. I don't count a gain as being when I close a position, so if it is opened one month, that's a gain, if I close it the following month that is an expense against gains that month (if I have to buy it back).

According to Claude, the code attributes the entire NET profit (premium minus exit price minus commissions) to the month the option was OPENED.

My method:
Month 1 (opened): Cash received = +premium (minus opening commission)
Month 2 (closed): Cash spent = -exitPrice (minus closing commission)

Current code's method:
Month 1 (opened): Net profit = +(premium - exitPrice - total commission)
Month 2 (closed): Nothing recorded

Example:
March: Sell put for $100 premium (commission $0.65)
April: Buy back for $25 (commission $0.65)

My expected accounting:
March: +$99.35 (cash in from sale minus commission)
April: -$25.65 (cash out to close minus commission)

Current code:
March: +$73.05 (net: $100 - $25 - $1.30 total commission)
April: $0

This is a fundamental difference in accounting method! The current code uses accrual-based "net profit when opened" vs my cash-based "cash flow by transaction month" approach.

When a trade spans multiple months, having the entire profit/loss attributed to the opening month makes it very confusing to track what actually happened each month. The core problem:

• If you opened a put in March for $100 premium
• Then closed it in April for $25
• The current system shows March with +$73.05 profit (the net)
• But April shows $0
• So if you look at April wondering "what happened this month?", you won't see the -$25.65 cash outflow

This makes month-to-month analysis very difficult because:

• Closed trades don't show up in the month they were closed
• The net profit changes retroactively - if you close a March trade in April, March's numbers change
• You can't see actual cash movements per month

Now, I haven't completely confirmed the analysis, but it does appear to be correct. I don't know whether this was a conscious design decision or maybe I just think about this differently to others. Would love to hear additional input on this.

[MarkT1065]

I don't know the "correct" way to account for trades, to be honest. You're correct in how you've described, where I keep it "open" as max profit until closed when it becomes an "actual".

The trade with my broker is open until buy-to-close or assigned on expiration. I did the same with trades in my spreadsheets and now in Wheeler. It's probably incorrect to show it as profit showing up on totals everywhere even while open, only to have the total go down when the trade is closed.

This is all true, but I also don't know how I'd do it otherwise:

This makes month-to-month analysis very difficult because:

Closed trades don't show up in the month they were closed
The net profit changes retroactively - if you close a March trade in April, March's numbers change
You can't see actual cash movements per month

I don't know the best and/or correct way to do it. I don't know how it would work across years, either (i.e, you receive $1k in premium in Dec 2025 but close it all for -$3k in Jan 2026 for a -$2k loss. where does that go?)

[antamy]

It's probably incorrect to show it as profit showing up on totals everywhere even while open, only to have the total go down when the trade is closed.

If you think about it on a monthly income basis, which is what the wheel strategy targets, then it works. You derive income from sales you make in a month, less any buys. From a profitability of a trade perspective, then that would need some work.

I've always had the view that options trading is inherently cash-flow based:

• You receive cash when you sell to open
• You pay cash when you buy to close
• Each transaction is a discrete cash event

The current implementation conflicts with this and makes the presentation of the data awkward:

• Retroactive changes - March's numbers change when you close a trade in April
• Invisible transactions - April shows nothing when you buy back a position opened in March, even though that was cash out of the door in April
• Difficult to reconcile to broker statements, which show cash flows by transaction date, not unrealized and realized gains like holding a stock

I don't know how it would work across years, either (i.e, you receive $1k in premium in Dec 2025 but close it all for -$3k in Jan 2026 for a -$2k loss. where does that go?)

From a cash perspective, that is straightforward. I'm not sure how that works from a tax perspective.

I will noodle some more on the cash flow / income view vs. the trade profitability view. Since the application is intended to support option wheels, it seems that an enhancement for the future would be to explicitly define a wheel and be able to view the monthly income, profitability and ROI of that campaign.

[MarkT1065]

If you're correct (and I think I can be persuaded), then I think, too, a single transactional model would be ideal, which I started but reverted some time ago (c663c89).

You'd have a single cash pile and individual transactions affect that pile (sell to open, buy to close, across all asset types). Some transactions result in gains, while some are cash contributions. It's easy to sum the transactions for totals. Individual tables for specific asset classes still make sense for managing a single trade, where both opening and closing it create transactions that affect the cash pile.

[MarkT1065]

1. User clicks the New Database button - Cash balance: $0
2. User funds account
   2.1. Transaction 1, Type:Cash, Balance: $1000
3. User buys Treasury
   3.1. Transaction 2, Action: Buy To Open, Type:Treasury, Price, Date, Treasury details ... etc.
   3.2. Balance: $2, 1 Long Treasury ($998)
4. User sells Put
   4.1.Transaction 3, Action: Sell to Open, Type: Put, Price, Date, Option details ... etc
   4.2. Balance: $68 ($2 from above and $66 from new option), 1 Long Treasury, 1 Short Put

If the transaction table had a FK to account, then issue #3 is easy if baked in from the start.

[MarkT1065]

This would also allow accounting for commissions by each transaction. Some transactions have no commissions (like cash contributions or an option assignment or stock purchase (for many brokers)) while other transactions will incur commission (opening and closing options contracts). This flows well with your recent foray into improving commissions. Maybe that PR is a symptom of this larger problem?

[antamy]

You'd have a single cash pile and individual transactions affect that pile (sell to open, buy to close, across all asset types). Some transactions result in gains, while some are cash contributions. It's easy to sum the transactions for totals. Individual tables for specific asset classes still make sense for managing a single trade, where both opening and closing it create transactions that affect the cash pile.

I hadn't delved into the treasuries / cash aspects, since that then takes you down a margin rabbit hole too. For me, I I just assume the cash to back CSPs is available, although it is very useful now to have visibility to that in the software. It probably also gets you into issues with what different brokerages offer. For example, Schwab requires you to have cash in your account, Fidelity allows for cash to be in a money market fund, and I'm sure there are more varieties.

Could this be modeled as:

Account
contains Instruments (stocks, treasuries, cash / money market funds, options)
tracks
Trades (typically two transactions buy and sell)
Campaigns - a Wheel which is a set of Trades against a single option Instrument

My days of database design are long over, so maybe this is too difficult to retrofit? Plus I know your intent wasn't to produce accounting software!

[antamy]

This would also allow accounting for commissions by each transaction. Some transactions have no commissions (like cash contributions or an option assignment or stock purchase (for many brokers)) while other transactions will incur commission (opening and closing options contracts). This flows well with your recent foray into improving commissions. Maybe that PR is a symptom of this larger problem?

Possibly. I think modeling a Trade as being 2 transactions would likely help a lot. Then you can keep profitability, ROI etc at the Trade level, and cash flow at the transaction level. I confess to not knowing how it is currently modeled, I've just been relying on Claude!

[antamy]

I was bored this evening and worked with Claude to incorporate all of this into a Wheeler v2 spec. I'm cautious of not wanting to take over your application, however I find it very useful and the whole AI generation aspect is a lot of fun. Let me know if you'd like to take a look at what "we" came up with.

[MarkT1065]

I'm interested in wheeler v2 spec. It's been a learning exercise in the first place, first to get out of spreadsheets and to learn to use Claude. I'm happy to have an interested collaborator.