Handling Investment gain and loss

[Mitch Frazier]

Although you could probably do much of this via reports, the main question
I have is "why would you?"  Why not enter all the information when you
enter the transaction rather than waiting to see it in a report?  And doing
it via reports strikes me as a much more complex undertaking than adding a
couple fields to the transaction entry form.

>From an accounting point of view, "Sell" transactions are essentially
unbalanced transactions.  You get a "debit" to your brokerage account for
the money you received, but there's no corresponding "credit" entries for
the gain or for reducing the basis of the asset.

On Tue, May 24, 2016 at 6:12 PM, <jeffjl.kde at outlook.com> wrote:

> I'm thinking this could be more of a reports function than a new
> transaction field. If appropriate "activity" choices are added for
> transactions, e.g. reinvested long/short term capital gains, return of
> capital, depreciation if we include assets in general, etc. (there may be
> quite a few), then it is a matter of collecting the transactions for a
> given asset and calculating the cost basis (and gain/loss) in a report.
> Except for the report, those new activities could be treated the same as
> existing activities, couldn't they? Existing functions could treat
> a reinvested long term capital gain transaction just like a "buy", for
> example. No change required to existing code other than recognizing the
> equivalence.
>
> The report could offer selectable specifics like FIFO or average price.
> I'm not sure the best way to select the assets - maybe choose a date range
> and display any assets that had "sells" in that range? And the specific lot
> method probably still needs a new UI.
>
> A report could also give you an estimated gain/loss/cost basis on an asset
> you still owned (unrealized gain/loss).
>
> On the taxable / tax-deferred issue - it would be nice if this could be
> set at the account level.
>
> But a report does not provide a way to tag a specific sale with a cost
> basis method. If you are going to use KMM data to actually do your taxes,
> that could be important.
>
> > Date: Sun, 22 May 2016 18:00:45 -0400
> > From: ostroffjh at users.sourceforge.net
> > Subject: Re: Handling Investment gain and loss
> > To: kmymoney-devel at kde.org
>
> >
> > On 2016.05.22 15:04, Mitch Frazier wrote:
> > > While entering a number of investment transactions recently I
> > > realized that
> > > KMM doesn't actually have a way to record the gain/loss on the sale
> > > of an
> > > investment. I was thinking about implementing something to solve
> > > this but
> > > wanted to pass the idea past the list first.
> > >
> > > As a first step at a solution, I was going to add a couple more rows
> > > to the
> > > transaction detail in the investment register:
> > >
> > > - A cost basis field. This would be an amount field that is
> > > used to determine how much the cost of the investment is
> > > reduced by the sale. Initially this field could be pre-filled
> > > by the average cost (based on the number of shares being sold).
> > > If the entire investment is sold, this field would be fixed
> > > and not editable.
> > >
> > > - A gain/loss field. This would be an splitable account field
> > > for entering the category or categories for the gain/loss.
> > > Splits are useful for allowing both short-term and long-term
> > > gain/loss specifications on a transaction.
> > >
> > > The current implementation "hides" the gain/loss because the balance
> > > of an
> > > investment shows as zero when the share value is zero, regardless of
> > > the
> > > amount the investment is sold for. Whereas, since the gain/loss is
> > > not
> > > recorded anywhere, the balance ought to be negative if the investment
> > > was
> > > sold for a gain and positive if sold for a loss.
> > >
> > > Mitch
> > >
> >
> > Unfortunately, I think that may be a bit simplistic. Once you have
> > sold all off an equity, its value is zero, since you don't have any of
> > it any more. When you do sell, the amount of the basis is not income -
> > it just gets back what you paid to acquire it. It is the difference
> > between that basis and the sale price which becomes the short or long
> > term capital gain or loss. If you actually buy the shares, that
> > purchase price is the cost. The only reason you would need to be able
> > to manually adjust this is if you "add" shares you bought before
> > tracking with KMM, or if the shares are swapped for a different equity,
> > in which case you "remove" all the original shares and "add" however,
> > many shares you get of the new equity. (In that case, hopefully KMM
> > should be able to do the conversion, so you still shouldn't need to do
> > it manually.) The cost basis just transfers from the old to the new.
> > I don't see how you get a cost basis by averaging anything.
> >
> > I'm not certain about how to record the gain/loss, but I know I already
> > have category fields for short and long term gain and loss, and two
> > sets of each - one for taxable, one for tax deferred. So far, I only
> > use them where the broker designates a dividend (usually for a
> > reinvestment transaction) as a capital gain, but I don't see why it
> > won't also work for a sale, expect for needing a category to represent
> > the recapture of the original payment (cost basis). I suppose creating
> > a category of cost basis would make sense. When you buy, that's where
> > the purchase price goes. When you sell, the cost basis category is
> > reduced by the same, with the appropriate capital gains category
> > getting the difference from the actual sale price.
> >
> > One complication is that if you acquire an equity through multiple
> > purchases, at different share prices, then when you sell, you do need
> > to designate which of those lots you are selling. While it generally
> > is taken that the oldest gets sold first, you may be allowed to
> > designate which. That would mean that not only the total value of the
> > cost basis needs to be tracked, but number and price of shares for each
> > purchase.
> >
> > I do agree it would be great for KMM to be able to track this, as it
> > would allow tracking unrealized gain/loss instead of just current
> > value. I'm just not sure how much change would be needed in the core
> > data structures. However, it's certainly worth discussing, and I don't
> > think any developer will have time to address it until after the
> > conversion to KDE Frameworks is complete, and there is not yet any
> > definite timeline for that.
> >
> > Jack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20160525/11012377/attachment.html>