It's not mark-to-market that's the issue. There are three issues right now:
1. Multipliers are needed to make data entry represent what's really going on.
2. A booking method that can cross from net short to net long and vice-versa isn't present.
3. Average cost booking is required.
1. Multipliers
When you trade options, I currently handle the multiplier by scaling up the size, e.g. for 3 contracts short (300 shares):
2021-02-23 * "(TRD) SELL TRADE" #opening ^order-T1234567890 ^td-1234567890
Assets:US:Ameritrade:Main:CovCalls -300 SPX_041621C4045 {23.8000 USD, 2021-02-23}
Expenses:Financial:Commissions 1.50 USD
Expenses:Financial:Fees 1.98 USD
Expenses:Financial:Fees 0.04 USD
Assets:US:Ameritrade:Main:Cash 7136.48 USD
Ideally Beancount should have a notion of multiplier that knows that for [A-Z]+_\d+[CP][\d.]+ the multiplier is 100, so you could just enter what you actually do:
2021-02-23 * "(TRD) SELL TRADE" #opening ^order-T1234567890 ^td-1234567890
Assets:US:Ameritrade:Main:CovCalls -3 SPX_041621C4045 {23.8000 USD, 2021-02-23}
Expenses:Financial:Commissions 1.50 USD
Expenses:Financial:Fees 1.98 USD
Expenses:Financial:Fees 0.04 USD
Assets:US:Ameritrade:Main:Cash 7136.48 USD
But that's not too bad, because options are pretty universally 100 in size, so when you see it in your file, you just know what it stands for.
has a $20 x NASDAQ index value.
So I enter them like this:
2021-02-19 * "BOT +5 /NQH21:XCME @13597.75"
Assets:US:Ameritrade:Futures:Contracts 5 NQH21 {271955.00 USD}
Assets:US:Ameritrade:Futures:Margin -1359775.00 USD
Expenses:Financial:Commissions 11.25 USD
Expenses:Financial:Fees 6.25 USD
Assets:US:Ameritrade:Futures:Cash -17.50 USD
with the multiplier in the cost. The actual price of the index at the time was 13597.75.
I'd much rather do this:
2021-02-19 * "BOT +5 /NQH21:XCME @13597.75"
Assets:US:Ameritrade:Futures:Contracts 5 NQH21 {13597.75 USD USD}
Assets:US:Ameritrade:Futures:Margin -1359775.00 USD
Expenses:Financial:Commissions 11.25 USD
Expenses:Financial:Fees 6.25 USD
Assets:US:Ameritrade:Futures:Cash -17.50 USD
and have Beancount do the multiplication itself.
I mean I could have done 100 NQH21 = 20 x 5 but that feels so wrong.
2. I think in general the way that the profits are booked from your margin to your cash account is via average cost.
If you want to be able to use the numbers pulled in from e.g. Ameritrade's futures reporting in your importer, they're average cost.
When you enter a position, there's zero cash account effect. When you close one, the average basis is used to add/remove to/from your futures account cash balance.
(I'm not sure if this is customizable by broker. I suspect that it might be subject to reg)
At the day it doesn't matter too much if you don't hold contracts overnight.
3. Imagine this sequence of trades starting from a flat position, e.g. you buy one, then sell 2:
2021-02-19 * "BOT +1 /NQH21:XCME @13593.00"
Assets:US:Ameritrade:Futures:Contracts 1 NQH21 {271860.00 USD}
Assets:US:Ameritrade:Futures:Margin -271860.00 USD
Expenses:Financial:Commissions 2.25 USD
Expenses:Financial:Fees 1.25 USD
Assets:US:Ameritrade:Futures:Cash -3.50 USD
2021-02-19 * "SOLD -2 /NQH21:XCME @13590.75"
Assets:US:Ameritrade:Futures:Contracts -2 NQH21 {271815.00 USD}
Assets:US:Ameritrade:Futures:Margin 543630.00 USD
Income:US:Ameritrade:Futures:PnL 45.00 USD
Expenses:Financial:Commissions 4.50 USD
Expenses:Financial:Fees 2.50 USD
Assets:US:Ameritrade:Futures:Cash -52.00 USD
This is a pretty common occurrence when scalping.
Futures are really one for their "one click action" like that.
The problem is that the second trade really should have been recorded as:
2021-02-19 * "SOLD -2 /NQH21:XCME @13590.75"
Assets:US:Ameritrade:Futures:Contracts -1 NQH21 {} @ 271815.00 USD
Assets:US:Ameritrade:Futures:Contracts -1 NQH21 {271815.00 USD}
Assets:US:Ameritrade:Futures:Margin 543630.00 USD
Income:US:Ameritrade:Futures:PnL 45.00 USD
Expenses:Financial:Commissions 4.50 USD
Expenses:Financial:Fees 2.50 USD
Assets:US:Ameritrade:Futures:Cash -52.00 USD
This has to be resolved somehow. In v3 we should try to build something to handle that gracefully and automatically.
I mean this does raise an important question: Should there really be a different syntax for augmentations and reductions?
Right now, what you input has to be cognizant of the current position in the account it's applied to.
Could this be handled more gracefully with a redesign of the input specification, where you'd only have one way to enter it and the resulting effect be a function of the inventory before?