portfolio
portfolio copied to clipboard
portfolio-performance
Return of Capital events or transactions required to keep Book Value in sync with brokers
Describe the bug Some types of securities, in Canada these are often Trusts, not only pay dividends but also return capital to shareholders.
Often the RoC portion of the dividend is decided after, sometimes only once a year, so there isn't always income associated with the event - it just adjusts Book Value. Other times the RoC is separate from the dividend so there is actually income from the transaction as well as adjustment to Book Value.
To Reproduce Steps to reproduce the behavior: Review definition at https://www.investopedia.com/terms/r/returnofcapital.asp See also https://forum.portfolio-performance.info/t/how-to-record-a-return-of-capital-from-a-share/22406 and https://forum.portfolio-performance.info/t/accounting-for-changes-in-purchase-value-in-the-case-of-return-of-capital-roc/31369
Expected behavior Adjust the Book Value of a security with or without associated income
Desktop (please complete the following information):
- OS: Linux
- Version 0.75.1 (April 2025)
This is also the case in the US. i.e. SPYI is an example of a fund that classifies its dividends as ROC until your adjusted cost basis reaches 0, for more efficient tax treatment. Thus my cost basis in PP does not reflect the adjusted cost basis shown by my broker, & so if/when I sell shares, the reported gain/loss will be incorrect.
Verifying the data in PP becomes much easier the more of it is the same as the statement from your broker.
Some types of securities, in Canada these are often Trusts, not only pay dividends but also return capital to shareholders.
This is an issue with Trusts not specific to Canada.
I seems to me given securities are revalued each day they should also be revalued regarding change of cost basis (increase or decrease).
GnuCash treat it as follows:
9.9. Return of Capital This refers to a transaction where an investment returns capital to the investor and doesn't have any accounting implications other than reducing the cost basis. The number of shares held is not changed.
A Return of Capital transaction can be entered in the stock register by entering the stock split with:
Shares 0 Price 0 Sell Return of Capital value The other side of the double entry would usually be a debit to the brokerage bank account.
Figure 9.38. Example Of Return Of Capital Transactions
An image of the Stock Account register after a return of capital.
Note: It is not possible to use the Stock Split Assistant to do this type of transaction. Tip: If you accidentally entered a non-zero price in the stock split, GnuCash may have created an unwanted price database entry which could cause reports to be wrong. Check for and remove such an unwanted entry from the price database using Tools → Price Database .
Reclassified as enhancement as this is not a bug.
In fact I do understand what you guys try to achieve. BUT you need to understand the following.
Performance is calculated between 2 points, buy and sell. Not more not less.
Buying a security for 10 $ on the Jan 1st and selling on Dec. 31st at 20$ equals 100% Performance. Changing the initial purchase price to 8$ because of 2$ RoC equals 150% Performance. Did the security reached this performance? Surely not, this is only the Tax Administration looking at things.
I understand this is bothering, but PP can't support taxes as they differ from country to county, and it would break internal architecture, which would end in 100's of hours on coding.
The goal of PP is to have a rock solid and crystal clear on performance, not on tax.
And after adding your sell statement with the "increased" amount of tax, PP will show you the REAL performance.
In the German part of the forum you'll find workarounds with the split feature in order to adjust all purchase prices, but you need to be aware this will break your performance view. One would say this is fine, because one is more interested in the tax view, but another may not be so happy with it. And at a certain point you do need to make a decision, so do the developers of PP.
PP can't support taxes as they differ from country to county
ROC is a general financial concept tho, it isn't really tied to a country's taxes. Just the general ability to return capital & have it lower the cost basis.
this will break your performance view [...] one is more interested in the tax view, but another may not be so happy with it. And at a certain point you do need to make a decision, so do the developers of PP.
Not really? This is getting a bit into the weeds of implementation, but it's not hard to think of ways that this could be provided without having any impact on reporting. i.e. each security would have an extra internal value for its "cost basis adjustment." A new transaction type "ROC" would subtract from this value. This additional value wouldn't be used for reporting, but could provide an additional column, "adjusted cost basis", which is just purchase price - adjustment. Then nothing would be affected. Doesn't at all seem like 100's of hours of coding.
ROC is a general financial concept tho, it isn't really tied to a country's taxes. Just the general ability to return capital & have it lower the cost basis.
I'm not saying it's not a financial concept, but it is a tax topic, if it wouldn't why would one need to adjust the costbase?
This is getting a bit into the weeds of implementation,
Correct
but it's not hard to think of ways that this could be provided without having any impact on reporting i.e. each security would have an extra internal value for its "cost basis adjustment."
Which must be taken in the calculation, otherwise it wouldn't make any sense, rather than displaying a reduce number.
A new transaction type "ROC" would subtract from this value.
Technically right, but transaction types are part of any calculation and therefore need to be included.
This additional value wouldn't be used for reporting, but could provide an additional column, "adjusted cost basis", which is just purchase price - adjustment. Then nothing would be affected. Doesn't at all seem like 100's of hours of coding.
So what you are saying is.... let me see a column with an adjusted value of the purchase price, but never considered it in any calculation... And therefore you would create a new transaction type. Sorry, this is weird and doesn't make much sense to me.
it is a tax topic, if it wouldn't why would one need to adjust the costbase?
I just was responding to the statement that PP can't support taxes because "they differ from country to county." The concept of ROC doesn't differ from country to country.
this is weird
It was just one very quick not-thought-out idea. Don't want to go further into the weeds here, the point was just there might be alternative ways to satisfy the needs of users with ROC securities without having to go too overboard & reengineer everything in a way that would necessarily take 100's of hours of work.