Handling Investment gain and loss

Thu May 26 15:56:14 UTC 2016

>> Unrealized gain/loss is different than what I'm talking about

I know. I took the opportunity to expand the discussion to cover both realized and unrealized :-)

Date: Thu, 26 May 2016 08:27:02 -0700
Subject: Re: Handling Investment gain and loss
From: mitch at comwestcr.com
To: kmymoney-devel at kde.org

Unrealized gain/loss is different than what I'm talking about, I'm talking about "realized" gain/loss.  Unrealized gain/loss wouldn't be entered into a ledger.
I never import transactions, so we definitely are thinking about it from different perspectives.  Even if you import transaction, it seems like the time to enter the information for "realized" transactions is then, not when you run a report.  Although, the exact procedure for doing it at import time is less clear to me.
On Wed, May 25, 2016 at 6:37 PM,  <jeffjl.kde at outlook.com> wrote:

Why would I? To have the software do the work instead of the user. And to get the unrealized gain/loss - useful at the end of the year for tax planning, e.g. do I want to take that loss to offset a gain I've already taken.

Also, I generally don't enter transactions. I download / import them. That may be another reason I'm looking at it differently.

It is definitely more implementation work for the programmer. 

Date: Wed, 25 May 2016 07:28:57 -0700
Subject: Re: Handling Investment gain and loss
From: mitch at comwestcr.com
To: kmymoney-devel at kde.org

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/20160526/d7e1980c/attachment.html>