On Tue, Feb 3, 2015 at 10:28 PM, Red Street <[email protected]> wrote:
> If I read this right, you're essentially doing the same thing as what I >> suggest except >> 1. holding your options with no cost basis. >> 2. holding unvested options in an asset account. >> >> About (1), I forget the rules for taxation of options, but surely when >> they are granted to you they have a cost associated with them. This could >> be the cost basis you use instead of no cost basis. >> > > ISOs actually don't have any sort of a cost associated with them. If you > don't use them, you lose nothing. In fact, this was one of the questions I > was going to ask - if Ledger or Beancount would be okay with this, but I > found that they are. > Interesting. Beancount doesn't currently allow a zero cost basis but that's mainly a constraint in input. I wonder if anything would break if we allowed it. I think it might make sense. About (2): It's unfortunate that these options will appear on your balance >> sheet. >> > > I'd actually prefer that they do (this is basically future promised > income), but your pointing this out made me realize that I should probably > use a different commodity for vested and unvested options, and set the > price of unvested options to zero. > > > >> - as the OP pointed out above, there is no easy way to calculate the >>> price of vested-but-unexercised, and unvested options >>> >> >> Why couldn't you have a script that parses your ledger, extracts the >> options instruments, parses your commodity conversion to get the strike >> prices and then spit out price entries from estimated vol/underlying values >> gathered from the market? >> Just plug in estimated numbers into this, you should get a coarse >> estimate: >> http://en.wikipedia.org/wiki/Black%E2%80%93Scholes_model# >> Black-Scholes_formula >> > > Will look into this. I was thinking of a simpler (current_price - > strike_price) to value them, which is what I currently use. > You mean min(0, current_price - strike_price). You could also use a simple binomial approximation. > - ORNG was purchased at $1.20 at exercise time. This is suboptimal because >>> ledger, for example, would assume $1.20 was the market price of ORNG on >>> that date, which is untrue. Is there a way to model things better using >>> generic bookkeeping methods? >>> >> >> 1.20 is the cost basis, not the market price. Why do you say it assumes >> 1.20 is the market price? >> > > Perhaps my understanding is not correct, but I was under the impression > Ledger would assume that to be the market price of that commodity on that > day without other overriding data. Also, what would happen to systems that > extract the market price based on this cost basis - for example, to compute > net worth on a particular day, or investment returns, or unrealized > profits/losses? > I don't know how Ledger's price database works. > -- > > --- > You received this message because you are subscribed to the Google Groups > "Ledger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
