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

peterb peterb at gmail.com
Tue May 25 09:15:30 EDT 2021

On Tue, May 25, 2021 at 4:38 AM Geoff <cleanoutmyshed at gmail.com> wrote:

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

Hi, Geoff! I'm in the same boat. I'm used to it as well, but I spend a lot
of time looking at how other systems model these transactions and that's
what has me concerned; this is first and foremost a correctness issue, but
it's also a data portability issue.

I do want to distinguish between "using the lots feature to calculate
capital gain" and "how the calculated gains are journaled." I'm focused
entirely on how the capital gains are reflected in the journal entries - we
should be able to keep the exact same view lots UI even if we change how
the lots UI journals things.

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.

This is a fair description, although I think of the transfer as coming out
of the income account, not into. The existing functionality works because
stock accounts are not dollar-denominated, so the dollars (or whatever
currency) you debit into it in your 0-share transaction evaporate upon
contact. This brings up a related point that I didn't touch, which is that
it's arguably better (though certainly not required) for the gain
calculation to be part of the sale transaction - if you've ever made a sale
which touches 10 lots, the current method creates 10 consecutive "Realized
Gain/Loss" transactions which have no obvious ordering or connection to the
lots sold - if you need to go back for any reason, you have to do detective
work to figure out which is which.

> 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
These two should be treated just as they are now (GnuCash probably can't
take a strong stance on them because of differing local tax laws.)

> * A share split or consolidation with partial return of capital
> * Takeover
> * Liquidation
I haven't thought deeply about these scenarios yet, but they should be
conceptually similar.

> 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?

I want to be clear that what I was trying to get at in my proposal is a
*simulation* of what we might want, and as such you can imagine UI changes
that accomplish the same thing in a better way; I'm using the 'price' field
here so I can show how I think it should be modeled, not because I'm
literally saying we should actually use the price field like this.

The crux of the issue to me is that the "price" field in the stock ledger
is doing two things, and *those two things are actually unrelated*:

(1) It is used as part of the calculation of the debit or credit of the
account on buy or sell transaction (and GnuCash is so ambivalent about its
role here that we need to throw a sheet to ask the user for their intent
almost any time it changes - the "Do you want to recalculate value, price,
or number of shares?" question)
(2) It is used to populate the Price Database for the security for that
date, which is in turn used to calculate unrealized gains/losses.

I've got no problem with using the market price for (2), and if we wanted
to keep it in the register for that purpose but also have a cost column I
think that would be fine (although probably confusing in a different way).
It's (1) that is the real problem here. In practice, the "price" for this
transaction is always going to be a constructed or inferred value (even if
the user types it in!) in the face of the two objective facts that drive
the transaction: the change in the number of shares owned, and the amount
of currency spent or received for those shares. Without getting too bogged
down in what the UI should look like, I'm saying how this is journaled
should be driven by a third objective fact: the cost basis of the shares
being sold.

I definitely think other UI choices are possible that could get you to the
same correct outcome. I think the desire driving the current way of doing
things is that we want to have our cake (treat stock sales as just another
journal entry just like every other register) and eat it too (have this
'price' field on the register that actually interacts with the rest of the
app in super-complicated ways.) If you've ever accidentally entered a stock
transaction in the General Ledger, you've seen the Exchange Rate sheet
appear and know that this is closely related to the stock price. You also
know that the user is almost never going to make the correct decision when
confronted with that sheet. I think inferring the exchange rate from facts
that the user WILL know (how many shares, what were the gross proceeds) is
going to be better for almost all of them.

Regarding the multi-transaction issue, I think one is not required to have
one gain split per lot sold; as long as you have a cost basis for whatever
is being sold, you can use that cost basis in the stock account credit
split and then have a single split for the capital gain.

That is just my 20 cents (I am not an accountant), let's see what others
> think.

I'm not an accountant either but my belief is that the complexity of this
issue is one reason double-entry accounting systems often aren't the first
choice for tracking investments.

More information about the gnucash-user mailing list