Unrealized gains: conclusions?

[Paul Schwartz]

----- Original Message ----
> From: Mike or Penny Novack <stepbystepfarm at mtdata.com>
> To: Charles Day <cedayiv at gmail.com>
> Cc: "List, GNUCash-User" <gnucash-user at gnucash.org>
> Sent: Sunday, July 6, 2008 4:11:37 PM
> Subject: Re: Unrealized gains: conclusions?
> 
> Charles Day wrote:
> 
> >Now that we have all had a chance to chew on the recent unrealized gains
> >discussions, I wonder if we might be able to come to some conclusions. Here
> >is my list for your comments and/or additions.
> >
> >  
> >
> I have kept out of it so far because folks seem to be considering 
> "unrealized gains" only in the context of "cash basis" and "trading". My 
> opinion is that it is asking far too much to expect ANY automated 
> bookkeeping system to decide how "gains" that do not involve external 
> transactions are properly accounted. Among other things that depends 
> upon ........
> 
> a) cash or accrual basis
> b) type of business and laws pertaining thereto.
> 
> Just one example
> 
> It doesn't just depend on the sort of transaction. Because I am NOT in 
> the "timber business", if every now and then I sell some "stumpage" 
> that's an incidental capital gain reported when it happens and I do not 
> have to report the increase of value of inventory. No unrealized gains 
> form the annual growth of trees. But if I were in the "timber business" 
> the sale of "stumpage" (or logs if I handled the felling operation too) 
> would not be a "capital gain" and I would have to report the unrealized 
> gain that growth represented (and get to charge "depletion" against it 
> too). Required keep books using the "accrual" method.
> 
> Michael

I agree very much with this view. Gnucash should be a package that does the bookkeeping that allows you to report your accounting status accurately.  Making assumptions about the way accounting should be done for everyone will seriously limit the utility of the package. Unrealized gains should be handled manually according to each individuals needs. Gnucash needs to focus on accuracy; allowing splits in the transactions gives everyone the flexibility needed; changing your accounting books to keep up with changing security prices imposes a rigidity on users that is not desirable for an accounting package. Providing a price db for users to mess with as an option is okay, but automagic changes are not desirable.

Just MNSHO

Paul