How to measure dividend growth of a portfolio still adding funds to

[nmdhqbc]

They'd have to be paid out first though right? ie. the unit inc price would need adjusting down to account for them going out. Then if they are re-invested later they buy new inc units. And the sell units if you withdraw cash bit is for the acc units isn't it.

No. Let's say that you have £300 of dividends accruing in a month. You want to withdraw £500, so you sell income units equal to £200 to make up the difference.

Likewise if you pay in £1000 one month and have £300 of dividends, then you buy units to the value of £1300.

The big question is, what unit value do you use? You could work it out for that day but it gets complicated if your calculation for that day uses the new number of units. I prefer to use the last recorded unit value, which would be the end of the previous month. Otherwise you end up with circular calculation errors.

TJH

Yeah, that makes sense. You've just bungled it into one transaction whereas in my mind I was going to do those things separately to keep it straight in my mind. Just feels easier for my little brain to understand it that way.

[Gengulphus]

Please excuse the silly question, but I'm having trouble working out how income units help me determine the increase in dividends of the portfolio as a whole.

OK. First off, accumulation units themselves measure the total portfolio value with the effects of deposits/withdrawals adjusted out - i.e. so that they 'see' changes due to the investments changing value and producing income, but not ones due to you adding money (e.g. from your salary) or removing it (e.g. to pay for a holiday).

They do that by regarding the portfolio as consisting of a number of accumulation 'units', each worth a certain amount - so at all times, the total portfolio value is equal to (number of units) * (unit value). The rules for updating them are designed so that changes to the portfolio value due to deposits/withdrawals are dealt with by leaving the unit value unchanged and adjusting the number of units to make that still be true, while changes due to investments changing value and producing income are dealt with by leaving the number of units unchanged and adjusting the unit value to make it still be true. That way, the accumulation unit value has the desired property of measuring the total portfolio value with the effects of deposits/withdrawals factored out.

Or to be precise, it does so with an arbitrary scaling factor applied to all unit values (the same factor for every one of them, not a different factor for each). That because one can take any scaling factor F and any unitisation calculation, multiply every (number of units) in it by F and divide every (unit value) in it by F, and one will still have the property that the total portfolio value is equal to (number of units) * (unit value) at every stage in the calculation. That arbitrary scaling factor enters the unitisation calculation when the initial deposit into a new portfolio is made: the unitisation rules don't determine what the (number of units) and (unit value) are set to by that deposit, but merely say to choose a pair of them whose product is equal to the initial deposit (which is of course the total portfolio value at that point).

Because of that arbitrary scaling factor, individual unit values are of no real significance - if I tell you that my accumulation unit value today is £197.53, that tells you nothing because I could just as well have said £123.45 or any other value, simply by having chosen the arbitrary scaling factor differently. But percentage changes between them (or equivalently ratios of them) are significant: if I tell you that my accumulation unit value two years ago was £123.45 and today it is £197.53, the fact that the latter is 60.01% more than the former (or that the ratio of the latter to the former is 1.6001) tells you what my total return over those two years was, with the effects of deposits/withdrawals factored out. Or in other words, what the total-return effect of the investments themselves was - it could for instance be that I made substantial capital withdrawals from the portfolio over the course of those two years, with the result that my number of units dropped from 810.04455 to 506.25221 and the portfolio value itself is unchanged: £100,000.00 both at the beginning and the end of those two years. If that were the case, it would mean that the negative effect of the withdrawals on the total portfolio happened to have exactly cancelled out the positive 60.01% effect of the investments themselves.

Like any other percentage change over a period, that total return figure can be converted into an annualised rate - in the above example, 60.01% over 2 years annualises to a rate of total return due to the investments themselves of 26.49% (which would be pretty good going if these were real figures rather than a made-up example!).

One more point to make before moving on to income units: for the results of the accumulation unit calculation to be an accurate reflection of the total-return effects of the investments themselves, it is important that all of those effects, both capital and income ones, are reflected in the total portfolio values it uses. That often happens automatically - for example, a very standard type of nominee broker account keeps all the investments in the account and collects all income, sales proceeds and other capital payments into a cash balance, and in that case the broker's valuation of the account, including both the values of the investments themselves and the cash balance, is precisely the total portfolio value the accumulation unit calculation wants. But there are other situations where some or all payments go/come from elsewhere, such as:

• Nominee broker accounts with a 'pay away' facility on dividends, to the extent that one uses that facility;
• Nominee broker accounts that don't have a cash balance, but instead require one to nominate a bank account that they will do direct debits/credits on as and when needed;
• CREST accounts (which could in principle either have a cash balance or use a nominated bank account, though I've only ever seen ones with cash balances), where the dividend payments are made directly to you by the company registrars, either by cheque or (much less hassle!) by you giving them a 'dividend mandate' authorising them to make them by direct credit to a bank account you nominate;
• Certificated holdings, which obviously don't have an associated cash balance, can be treated like a CREST account without a cash balance.

For those situations, for accumulation units you need to make certain that you record transfers in and out of the portfolio as appropriate to fit in with accumulation unitisation's model that deposits are transferred into the portfolio, withdrawals are transferred out of the portfolio and everything to do with the investments themselves (purchases, sales, dividends, corporate action proceeds, etc) happens entirely within the portfolio. So paid-away dividends and the other cases above where dividends go to an external bank account need to be treated as the dividend arising within the portfolio and then being withdrawn from it; likewise for sales proceeds and corporate action proceeds where those proceeds go to an external bank account. And similarly, in cases where purchases are funded from an external bank account, that needs to be treated as a deposit of the required funds into the portfolio followed by the purchase happening within the portfolio.

Or there is the alternative of setting up a dedicated bank account that you use for portfolio-related purposes only and regarding it as an additional, home-made cash balance of the portfolio. Ensure that all funds for purchases that don't come from a broker account's cash balance come from it and that all sales proceeds, dividends and corporate action proceeds that don't go to a broker account's cash balance go to it, and do deposits/withdrawals into/from either it or a broker cash balance. This is easy for nominee accounts - you just need to set the dedicated account to be the nominated bank account or the account to send paid-away dividends to as appropriate. For CREST and certificated holdings, it's a bit harder: you need to set up dividend mandates to it for all holdings, and pay any cheques you receive relating to the holdings (e.g. for dividends paid before the dividend mandate has been set up, or for corporate action proceeds) into it. For CREST accounts that don't have a cash balance, you also need to use it as the account's nominated bank account, and for certificated holdings, to fund their purchases and receive any sales proceeds.

The advantage of doing all of that is that if you regard the dedicated bank account as part of the portfolio, i.e. include its balance in the portfolio valuations used by the unitisation calculations, you're then effectively in the very simple position first described above where the unitisation calculations are only required to be done when there is a "real" deposit/withdrawal into/from the portfolio. Especially for portfolios like HYPs that tend to have a lot of dividend payments compared to other types of transaction, this can save one from needing to do an awful lot of data entry work. (But do make certain it's a dedicated bank account, i.e. used only for portfolio-related purposes. Don't be tempted to use it for other purposes as well, since that's liable to throw away that advantage. E.g. using one's current account for the purpose doesn't save data entry work: regarding it as part of the portfolio may get rid of data entry work for dividends - but it makes every bit of everyday spending taken from the current account into a withdrawal from the portfolio that does require data entry work!)

So on to income units. They're basically just like accumulation units, except that they don't merely prevent deposits/withdrawals affecting the unit value by updating the number of units rather than the unit value: they do the same for income payments (*) as well. As a result, they measure the capital return of the portfolio rather than the total return (**). To do this, the income unitisation model is that income payments appear outside the portfolio without being withdrawn from it, whereas (as indicated above) the accumulation unitisation model is that they appear inside the portfolio without being deposited into it. So the data for the accumulation unit calculation needs to be modified by:

* Where an income payment was ignored for the accumulation unit calculation because it actually arrived inside the portfolio, matching accumulation unitisation's model, it should instead be recorded as a deposit into the portfolio for the income unit calculation.

* Where an income payment was recorded as a withdrawal from the portfolio for the accumulation unit calculation because it actually arrived outside the portfolio, failing to match accumulation unitisation's model, it should instead be ignored for the income unit calculation.

If you only want to do income units and not accumulation units as well, that changes the best account set-up from the point of view of minimising data entry from a nominee account with a cash balance and without any dividends paid away, or one using a dedicated bank account as described above, to a nominee account with a cash balance and with all dividends paid away, or one using a dedicated bank account as described above except that paid-away dividends and dividend mandates don't go to the dedicated bank account, but to some other bank account. (This isn't possible for nominee accounts without cash balances unless they offer the facility to have two nominated bank accounts, one for dividend payments and the other for everything else - a facility I've never seen offered...) With either of those set-ups, you'll still need to treat cases where you want to regard a non-dividend as an income payment or a dividend as not being an income payment (see (*) below) specially, but they're generally pretty rare and so shouldn't be too much extra work.)

On the other hand, if you want to do both income units and accumulation units, every income payment creates a deposit/withdrawal for one or the other, so you basically cannot get rid of data entry work for income payments no matter what account set-up you use. The same goes if you want to do income units and not only calculate numbers of units and unit values, but also income-per-income-unit figures, regardless of whether you also want to do accumulation units. As their name suggests, they are calculated by dividing each income payment by the number of income units in existence at the time of the payment: what they basically measure is the income payment's contribution to the amount an investor who doesn't want to accumulate income within the portfolio, nor supplement it with sales, should withdraw from the portfolio per income unit. Or more briefly, its contribution to the 'natural income' of an income unit - i.e. its income if neither supplemented by sales nor reduced by retaining income within the portfolio.

Add up the income-per-income-unit figures for all income payments within a period, and you get the 'natural income' of an income unit for that period. Make the period a year and divide by an appropriate income unit value and you get a portfolio yield (as usual, adjusted to get rid of the effects of deposits/withdrawals). The appropriate income unit value is usually (***) the income unit value at the start of the year concerned, telling you what the yield of the portfolio for that year actually turned out to be.

Finally, all of the above assumes that you want the unitisation to be done as accurately as possible. There are a number of ways that you can sacrifice a probably-insignificant amount of accuracy to reduce the amount of work significantly - for example, by inputting the sum of all the income payments received in each month as a single income payment received mid-month rather than inputting each income payment separately, or by deciding that the case where whether a payment is a dividend doesn't match whether you want to treat it as an income payment are too rare to justify the extra work of finding them and adjusting the income unitisation's input data accordingly.

(*) I'm saying "income payments" here rather than "dividends" for two reasons. Firstly, all of this applies to portfolios of all types of investments, not just shares, and thus to all the different types of income payment they can produce. Secondly, for performance-measurement purposes (but not tax purposes), even for shares there are sometimes reasons why people might want to treat a non-dividend as an income payment (for example, Rolls-Royce's shareholder payments made by issuing redeemable shares and then redeeming them), or a dividend as a non-income payment (for example, special dividends accompanied by share consolidations basically have identical effects on a portfolio's performance to those of a sale of the shares lost in the consolidation for the special dividend payment).

(**) It is rather counter-intuitive that income units measure capital return. The explanation is that the terms originate from the accumulation and income units of unit trusts, which are designed respectively for investors who want to accumulate the income produced by the underlying investments within the units and for investors who want to take it out as income they can use for other purposes, especially to pay their living expenses. I.e. basically the "income" in "income unit" describes what is taken out, not what is left inside...

(***) I say "usually" because there is a special case: if the period is the year ending today, and you want the historical yield for the purpose of making a buying/selling decision about income units today, then the appropriate income unit value is the current one, i.e. at the end of the year concerned rather than its start. But income units in one's own portfolio are not tradeable securities, so that sort of decision generally only applies to the income units of unit trusts, which are. One can achieve an equivalent effect by deciding what proportion of the portfolio's income units one wants to buy or sell, and then buying or selling that proportion of each of the portfolio's existing holdings - but that's cumbersome enough and expensive enough on trading costs that the only case of it that I think is at all likely is one of selling 100% of everything, i.e. liquidating the portfolio. For that, I can imagine wanting to know the historical yield of the existing portfolio for the purpose of comparing with the historical yield of some other type of portfolio one was thinking of buying in its place, but it must be a pretty rare case, because I'd have thought that the driving consideration on that sort of whole-portfolio replacement was likely to be some sort of impracticality - e.g. no longer feeling capable of running a HYP and not having anyone who is willing and able to do it for you and to whom you are willing to grant a Power of Attorney to do so...

Am I right in thinking Accumulation units measure the total return of the portfolio (and can be compared to a benchmark such as Ftse 100 total return index).

Yes - hopefully the much longer answer above will explain why that's the case!

Secondly, income units measure the performance of the portfolio minus the income which is paid out? Hence, would be benchmarked against an index such as the Ftse 100.

Again, yes.

So between the 2, how do I get a measure of the actual increase in income, ie the dividends?

Basically yes, but see the above long answer to understand the nature of that measure.

While here, I do measure the XIRR of my portfolio. Would that be much different to the results given by Accumulation and Income Units?

Well, as the results given by the two types of units differ from each other for anything other than a zero-income portfolio, the XIRR has to differ from at least one of them. And for a high-yield portfolio, the results given by the two types of unit differ from each other by quite a lot, so the XIRR has to differ from at least one of them by at least half that difference.

But I can give a somewhat more useful answer (though only somewhat) about the XIRR and the annualised rate of total returns given by accumulation units. In that case, they're identical if there are no deposits/withdrawals other than the initial deposit, since they're both the percentage increase from the initial deposit to the portfolio's current value, annualised. I would expect them to be little different if there were such deposits/withdrawals but either their total value was reasonably small compared with the portfolio value, or they were individually reasonably small compared with the portfolio value and there was a reasonably large number of them spread out reasonably evenly over a long period - long enough for the portfolio to have undergone a good variety of market conditions in the period. (That would for instance apply to a portfolio built up over 2-3 decades using regular savings and not having had anything much in the way of other external sources or consumers of capital.)

The more the portfolio's history deviates from that sort of pattern, the more likely a big difference is. For example, doubling the portfolio size by adding a large lump sum (e.g. from a Lottery win or an inheritance) could produce quite a large difference, especially if it happens to occur near a market peak or trough. The same would apply to halving it with sales and withdrawal of the sale proceeds, e.g. to help fund a house purchase.

Gengulphus

[Breelander]

Regarding the FTSE 100 TR index, it is available on the FT website, under the heading World Markets at a Glance, but they have just started limiting access to those who pay a subscription.

The limits are that you can see today's price for free, but only FT subscribers can get the historic prices or charts.

This is a free site with the latest and the historic FT100 TR prices. https://uk.investing.com/indices/ftse-1 ... rical-data

[tjh290633]

Thanks, Bree. I found another site that gives the FT30 index, using the EPIC FTII. It's bookmarked on my PC, but not on my phone. It could be the same one. What's the EPIC for the TR version of UKX?

One point that just occurred to me is that, for accumulation units, the value of a dividend should be accrued on the XD day, and not on the day it is paid. That's because, when dividends go XD, the value of the accumulation unit does not fall.

TJH

[tjh290633]

Yes, it is the same one. Now I can see that the Code is TRIUKX.

TJH