Stock trades and realized gains/losses

[Ross Boylan]

I have a few comments on the discussion.

1.  Might it be useful to look at the problem as being one of getting
the correct model of a stock?  Specifically, shares of stock and other
commodities in the current system have only a price and quantity.
This is not really sufficient: one needs the purchase date and basis.
Basis include price and sometimes transaction costs.

At least in the US, basis is the relevant thing for taxes, and the
purchase date affects holding period and thus the tax rate.

If I understand lots, they permit getting this information, but they
do not directly add it to the data model for stocks.  If the
information were directly available, it seems to me a lot of the
problems would get much simpler to solve.

Managing Your Money and, I assume, Quicken record holdings with the
original price and purchase date as far as I can tell from the user
interface. 

2. From the user's point of view, every sale may not be associated
with a particular purchase.  This is so if they use average cost
accounting.  I believe there are two permitted variants in the US
depending on whether you average everything or just within long and
short term holdings.

Of course, other users may wish to associate every sale with a
specific purchase.  Ideally, the program could cater to both groups.
I mention the first because they may find the model underlying lots
unnatural. 

By the way, the one function I have missed in Managing Your Money is
"sell so as to maximize or minimize capital gains."

3.  If you sell shares and buy them back it is a "wash sale" and does
not count for tax purposes in the US.  As I recall, there is a 30 day
window on either side of the sale in which purchases can wash (i.e., a
sale can not count because of a previous purchase).  (I just wanted to
correct some earlier misinformation--it's not directly relevant to
program design unless we want to think about tracking this as well!)

By the way, forcing people to perform phantom sales for purposes of
the program is not friendly (I'm not sure that was proposed, but some
comments seemed to hint at it).

4. My mutual funds indicate a dollar value of a transaction, a price
and a quantity.  But sometimes value <> price * quantity because of a
small rounding error.  It is definitely the number of shares, not
their value, that is "real" as far as the mutual fund is concerned
(though, of course, the money they take for the purchase is quite real
too!).  I bring this up first because it may have some relevance to
the debate over whether accounts should be in currency value or share
quantities (it's an argument for quantities) and second to alert you
to an unpleasant possibility the program should be able to handle.

5. There might be hiding in here some more general question of
tracking things.  For example, retirement accounts may have a mix of
pre and post tax contributions; Roth retirement accounts have
different aging buckets; (see also points 2 and 3) .....  It seems
unlikely that the program could or should incorporate all such
possibilities, but it would be nice if it had an architecture that
made adding them possible.