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

Geoff cleanoutmyshed at gmail.com
Tue May 25 04:38:29 EDT 2021


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 at 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.
> 


More information about the gnucash-user mailing list