Hi Peter
First, thanks for taking the time and effort to kick off this discussion
with your suggestion.
I personally found the current process quite confusing for a long long
time until one day it finally "clicked" and now I am used to using the
Lots functionality for tracking capital gains & losses.
It seems to me that your proposal, in essence, involves including the
capital gain as one of the splits of the sale transaction, whereas the
current Gnucash functionality requires you to "transfer" the gain out of
the stock account and into the income account as a separate transaction
to the sale itself. And the Lots functionality can do this for you,
either by you choosing the individual lots, or automatically on a first
in, first out basis.
Have you considered generalising your proposal to cover other stock
related capital gain scenarios, for example:
* The sale includes brokerage, taxes, or other charges
* The sale of several lots that were bought at different prices
* A share split or consolidation with partial return of capital
* Takeover
* Liquidation
The biggest drawback I see with your proposal is that the selling price
is no longer recorded in the price column, but is only held in the split
description? You seem to be recording the original buying price as the
price on the sell transaction, which is confusing at first glance and,
in a sale of multiple lots scenario, would require the entry of many
such splits?
That is just my 20 cents (I am not an accountant), let's see what others
think.
Regards
Geoff
=====
On 25/05/2021 12:02 pm, peterb wrote:
Hi. I've been thinking a lot over the past year about how
GnuCash's standard workflow accounts for capital gains and losses, and I'm
coming around to the idea that the journal entries GnuCash guides the user
to use for stock sales and the like are poor practice. I'd like to think
out loud in this thread, get feedback, and hopefully spark some discussion.
I made a tiny file to illustrate this, and you can grab it at this URL to
follow along (or spin your own scenarios):
http://tleaves.com/misc/cap-gain-test.gnucash. This email has images; if
they get stripped I'll post this on a web page somewhere
First, let's look at a simple transaction of a purchase and sale of a
stock, BIGCO. 100 shares of BIGCO are bought at $10/share and sold the next
day for $20/share (nice work if you can get it)
[image: Screen Shot 2021-05-24 at 9.37.56 PM.png]
Cap gains are then automatically created via "view lots" (the procedure
outlined in Section 9.7.2.4 of the User Guide)
[image: Screen Shot 2021-05-24 at 9.39.14 PM.png]
Worth noting here is that even though I created this via View Lots, a
similar transaction is recommended in the "manual" procedures outlined in
the user manual. There are several reasons this is problematic IMO.
First, we're creating money out of nowhere by introducing these "balancing"
entries that don't actually balance; arguably, I'd say it's leveraging a
behavior ("These 0 shares of something are worth $1,000!") that is arguably
a bug.
Second, if you've ever tried to enter these transactions MANUALLY, you know
that the UI goes out of its way to try to stop you from doing this weird
thing - GnuCash knows that the account is denominated in units of BIGCO,
not in USD, and until you master the art of forcing it to believe the
transaction involves zero shares, it will fight you every step of the way.
Thirdly, if you ever try to take your GnuCash book and export it to any
other bookkeeping system, these phantom transactions are going to
complicate your life immensely, because, at their heart, they really don't
make a lot of sense. (If you look at how the BIGCO entries appear in the
General Journal, it becomes even more clear how weird these entries are.)
Here's an alternative way of accounting for cap gain that doesn't do this.
Just like BIGCO, we buy SMALLCO for $10:
[image: Screen Shot 2021-05-24 at 9.45.40 PM.png]
We sell it a few days later. But instead of using the market price in the
price-per-share column, let's just use the price of the lot we sold. Then
we add an income split for cash received - return of capital, which would
be trivial to do automatically.
[image: Screen Shot 2021-05-24 at 9.46.54 PM.png]
This transaction fully captures the same information as the first one, but
doesn't pollute your ledger with adjustment transactions that borrow
phantom dollars from non-dollar-denominated accounts. It should be
representable in any double-entry bookkeeping system and would make perfect
sense. In one sentence, what I'm proposing as a strawman is *ignore the
price field for the sale of stock and mutual funds, use the purchase cost
of the lots being sold to calculate Tot Sell, and make the Orphaned
Gains/Losses split part of the transaction by default*.
I think we end up in the BIGCO situation specifically because we are
assigning a semantic value to the price of the stock that is unwarranted.
We want that price to be meaningful for things like calculating the
unrealized gains in our portfolio (I want that too!) but in the sale
transaction all using that price does is complicate our lives. What we
actually want is the cost of the lot we're selling, not its market price.
We don't need the market price at all for the sale, because the other side
of the transaction is the cash we're getting, which fully accounts for it.
I'm certainly not saying the SMALLCO process I described above is the Only
Way To Do Cap Gains. But I do think the current flow we recommend and guide
users toward is complicated (there's a question about it on gnucash-user at
least once a month), confusing, and will not play well with non-GnuCash
accounting tools. Maybe it is worth replacing this flow with something
better.
OK, that was a lot of typing.
Am I the only person who thinks this is a problem? And a problem worth
solving?
Thanks for your consideration,
Peter
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
