[GNC] Proposed: "Realized Gain/Loss" transactions considered harmful

[peterb]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2021-05-24 at 9.37.56 PM.png
Type: image/png
Size: 544531 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20210524/7988ba07/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2021-05-24 at 9.39.14 PM.png
Type: image/png
Size: 220583 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20210524/7988ba07/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2021-05-24 at 9.45.40 PM.png
Type: image/png
Size: 210201 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20210524/7988ba07/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2021-05-24 at 9.46.54 PM.png
Type: image/png
Size: 325698 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20210524/7988ba07/attachment-0007.png>