Unrealized gains

[Charles Day]

On Mon, Jun 30, 2008 at 3:56 PM, Charles Day <cedayiv at gmail.com> wrote:

> On Mon, Jun 30, 2008 at 11:34 AM, Charles Day <cedayiv at gmail.com> wrote:
>
>> On Mon, Jun 30, 2008 at 9:16 AM, Derek Atkins <warlord at mit.edu> wrote:
>>
>>> Quoting Charles Day <cedayiv at gmail.com>:
>>>
>>>  Recording only the realized gains will put the books out of balance.
>>>>> When
>>>>> you sell, you have a realized gain on the quantity sold and an
>>>>> unrealized
>>>>> gain on the quantity remaining. You have to record them both.
>>>>>
>>>>> Try removing the unrealized gain splits from either of the examples I
>>>>> attached previously and look how it throws off the trial balance.
>>>>>
>>>>>
>>>> Just to (hopefully) clarify, unrealized gains that occur PRIOR to a sale
>>>> don't have to be recorded until a sale actually occurs. I think that
>>>> might
>>>> be what's throwing you off.
>>>>
>>>
>>> I still don't think I'm being thrown off here.  Honestly, I think the
>>> Trial Balance report is broken in that it's not properly using the
>>> PriceDB
>>> entries to compute the UNREALIZED gains.  The only time you should need
>>> to add splits are for actual realized gains (or losses, of course).
>>>
>>
>> Ah, so you're saying that the Trial Balance report ought to be figuring
>> out ALL unrealized gains, as opposed to just those that have occurred since
>> the last exchange (which is what it appears to be doing). So then I wouldn't
>> be forced to do any revaluation by hand.
>>
>> That would certainly make the bookkeeper's job easier, but I'm wondering
>> how the report would actually be able to compute unrealized gains correctly.
>> The report would have to know the basis of each unit of non-home-currency
>> and each unit of non-currency held. Since GnuCash doesn't keep track of
>> *which* units are sold when a sale occurs, how would it know the basis of
>> the unsold units? (Perhaps there is a way, but it's not coming to me at the
>> moment.)
>>
>
> I did some reading of the Trial Balance report code... the first thing I
> noticed is that when it figures out the basis it always does so using an
> average weighted exchange rate that is computed from buys AND sells, rather
> than just buys. The net effect is that unrealized gains that occurred prior
> to the most recent sale are not included. If the algorithm was changed to
> exclude sells, the report might include all unrealized gains correctly - but
> only if we assume that the user always uses the average cost method when
> calculating realized gains. Not a valid assumption.
>
> It seems to me that one way to get the Trial Balance to correctly compute
> all unrealized gains, without changing any code, is to record sales
> differently from what is recommended in the Concepts Guide. For example, the
> sale occurring at t2 in your example (sell 10 shares @ $3) can be recorded
> like:
>
> Memo               Account                Qty Price  Buy   Sell
> ================== ====================== === ===== ====== ======
> Basis              Assets:Broker:XYZ Corp -10     1         10.00
> Realized Gain      Income:Realized Gains                    20.00
> Deposit proceeds   Assets:Broker                     30.00
>
> When recorded this way, the computation method for realized gains doesn't
> matter any more and the trial balance actually balances. But of course, now
> execution price isn't recorded.
>

I take this statement back... if you record as I suggest then the trial
balance report does work, but only briefly. Enter a new buy and it goes out
of balance again.


> Thoughts?
>
> -Charles
>
> With trading accounts, all unrealized gains are tracked directly in the
>> books in a way that makes entering revaluation splits unnecessary. The
>> report system wouldn't need to calculate the unrealized gains.
>>
>> -Charles
>>
>> Let me try to prove my point, and I'll try to do this by using an
>>> example.  Assume we start out by buying 100 shares of X at date T0
>>> for price P0.  Then on date T1 we see the price changed to P1.  On
>>> date T2 we sell 10 shares for price P2.  On T3 we see the price
>>> is now P3.  Then on T4 we sell another 10 shares for P4.  Just to
>>> make numbers easy, let's say P[i] = $i+1 (e.g. P0 = $1, P1 = $2, etc).
>>>
>>> So we have the following data points:
>>>
>>> Date     Action     Txn Shares  Txn Price   Txn Value   Gain/Loss
>>> -----    ------     ----------  ---------   ---------   ---------
>>> T0        Buy         100           $1        $100         N/A
>>> T1        None         0            $2                     N/A
>>> T2        Sell        -10           $3         $30         $20
>>> T3        None         0            $4                     N/A
>>> T4        Sell        -10           $5         $50         $40
>>>
>>> Note that there are NO GAINS at times T1 and T3 because it's JUST
>>> a pricedb entry.
>>>
>>> Similarly, you don't need to RECORD the unrealized gain of the
>>> 90 shares at time T2 or the 80 shares at time T4 because you can
>>> compute that FROM the pricedb entry.  The only gain you need to
>>> record is the actual realized change from the actual exchange.
>>>
>>>  -Charles
>>>>
>>>
>>> -derek
>>>
>>> --
>>>      Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>>>      Member, MIT Student Information Processing Board  (SIPB)
>>>      URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>>>      warlord at MIT.EDU                        PGP key available
>>>
>>>
>>
>