accounting for managed investment accounts

[John Ralls]

On May 5, 2014, at 5:08 PM, gnucash.133518b at telus.net wrote:

> On 2014-04-30 8:07 PM, John Ralls wrote:
>> I think that the easiest way to deal with this is to pretend that it is a mutual fund with reinvested annual dividends. Create a fake security, make your initial purchase at C$10 per "unit", and enter a price by hand in the price editor every time you get a statement. Treat the year end tax statements as reinvested dividends. If you have separate tax treatment of capital gains and income, create appropriate income accounts and make the transactions so that whatever taxes you pay are recognized in the basis of your investment. The objective of that is so that you know when you redeem your investment in the pool you know how much of the gain you've already paid tax on.
> 
> John, I've been experimenting with your suggestion, but I'm still unclear on some of it so I would appreciate it if you could check me on them.
> 
> The first transaction is an opening balance entered as PRICE=10 and BUY=LAST_KNOWN_VALUE, where LAST_KNOWN_VALUE is the account value in dollars taken from the most recent monthly statement. That C$10 number is totally arbitrary, correct? No advantage to choosing another value?
> 
> Subsequent contribution/redemption transactions are entered as PRICE=LAST_KNOWN_VALUE/LAST_SHARE_BALANCE and either BUY=NEW_MONEY_IN or SELL=MONEY_OUT.
> 
> Upon receiving a monthly statement use the price editor to assign the price for the month end date to be STATEMENT_VALUE/CURRENT_SHARE_BALANCE.
> 
> One of the problems in entering transactions is determining LAST_KNOWN_VALUE. Although current value appears in the status bar at the bottom of the register view, this is only useful if one is always careful to enter all transactions in chronological order, which doesn't always happen. Is there any way to enable the display of a "Balance (CAD)" column in the register?
> 
> Of course the alternative to using PRICE=LAST_KNOWN_VALUE/LAST_SHARE_BALANCE is to use PRICE=LAST_KNOWN_PRICE but there is no way to determine the last known share price from within the register given that it may have changed between transactions. This necessitates opening the price editor and drilling down to the fund in question each time. Doable but inconvenient and error prone. I'd hoped that I could instead enter a month end zero-buy transaction in the register to do the value update. This actually does work as a convenient alternative to using the price editor because the price editor still gets updated, but it doesn't achieve the desired result in the register. As soon as such a transaction is entered, GnuCash reverts the price field to 1. Is there a way to achieve a zero-buy entry that would visually retain the new share price in the register transaction? As an aside, this style of recording balance updates would be extremely helpful when exporting the account's transactions for external XIRR calculations.
> 
> Your reinvested annual dividends from tax statements suggestion is what I have really been struggling with. I think you're saying that at the end of the year I need to add income entries for each of the year's accumulated total of each kind of income. An entry for total realized capital gains, another for total dividends, another for total interest, etc. The potential problem with getting these values from the tax statements is that such statements only report totals for taxable income. The missing non-taxable income would mean my book doesn't include all earned income. Is this not a problem? Will I not end up with an imbalance somewhere?
> 
> During the course of the year I would be updating the price editor using the month end account value. This value necessarily includes the real world effects of internally retained realized capital gains, dividends, interest, etc. Am I not effectively doubling all that income by depositing it all in again at the end of the year? I'm confused between thinking that is the case and realizing that the year's final account balance is actually only determined by my final entry in the price editor.
> 
> I'm afraid I haven't understood "make the transactions so that whatever taxes you pay are recognized in the basis of your investment". What does this mean?

Yes, the $10/unit price is simply to make it easy to calculate the initial number of units.

When you create a transaction you assign a "date posted" which is used for sorting. The actual entry date ("date entered") is immaterial except as a last-resort sort of transactions having the same date posted and number.

The last known value is the value of your investment at the time of the previous statement as reflected in that statement. Since you're recording that only in the price editor, that is indeed where you must look unless you have a copy of the previous statement at hand. The reseting of the price to 1 is a side effect of the balancing routine avoiding a divide-by-zero error. There's no real reason for it other than that whoever wrote the code wasn't thinking of your use-case.

Reinvested dividends might well be wrong if you don't include all income which will change the number of notional units. If the pool manager isn't providing you with complete reports, either via the tax forms or the periodic statements, then you have a problem that you need to work out with them. The same is true of the monthly value; you want that to reflect only the aggregate results of price changes, so you'll want to apply realized capital gains and income, whether taxable or not, before recalculating the price. Yes, you're absolutely correct that if you enter that monthly from the statements and again at year-end from the tax forms you'll be accounting twice for the same money. Instead consider the tax forms a reconciliation source to make adjustments for e.g. using the last-statement price for a reinvestment made between statements, since only the manager has the necessary day-to-day pricing information.

When you put more money into the pool, regardless of whether that money comes from an outside investment or internally-generated reinvestment of realized capital gains and dividends (taxed or tax-exempt) it changes your basis in the pool. The ultimate goal of this accounting exercise is to ensure that your books correctly reflect that basis so that when you redeem it you can correctly calculate the actual gain and the resulting tax. The only perfect way to do that is to actually track the individual investments just as if you were managing the portfolio yourself. I'm suggesting ways to get close with less work, but there's a trade-off with accuracy.

Regards,
John Ralls