Certainly, this is the crux of the issue, portfolio performance would be reported correctly but not security performance.
Portfolio Performance
Security Performance
It is not a crux if you accept that PP is not designed to reflect the internal relationships of an asset. In relation to the portfolio, the market price is the only relevant indicator. Therefore, this indicator also reflects the correct price.
You are also not interested in what happens internally in funds - and if you are, you analyse this with financial software and not with portfolio management software.
Cheers, Laura
Hello everyone, Iâm an investor from Argentina. Here the fixed income market (sovereign and corporate bonds) holds greater relevance than the equity market. I would like to contribute to this thread in the requesting a functionality that I believe is essential.
In Argentina, it is quite common for fixed income bonds to offer, in addition to interest payments, the possibility of early capital repayment, which we call âearly amortizationâ. This mechanism works as follows:
| Date | Amortization (%) | Residual Value | Interest | Cash Flow | Market Value |
|---|---|---|---|---|---|
| 10/11/2024 | 0 | 100 | 2.99 | 2.99 | 103.75 |
| 04/11/2025 | 33 | 67 | 2.99 | 35.99 | 69.51 |
| 10/11/2025 | 33 | 34 | 2.00 | 35.00 | 35.28 |
| 04/11/2026 | 34 | 0 | 1.02 | 35.02 | 0.00 |
As you can see, the market value of the bond starts at 103.75 (above its nominal value). As capital is amortized and interest payments are made, the market value decreases proportionally, as there is less outstanding capital, and therefore, lower expected future returns. By the end of the period (04/11/2026), the market value will be 0 as all the capital will have been repaid.
Itâs important to highlight that amortization is not a capital gain, but rather a recovery of the original capital. This differentiates it from the interest payments, which are considered gains.
Currently, the lack of functionality to represent amortizations in Portfolio Performance causes the balances and returns of my portfolios that include such bonds to be inaccurate. Any performance metric is incorrect as amortizations are wrongly accounted for as gains.
1 Like
You can treat it as a (partial) sell; same as the repayment of the bond at the end.
With amortization, the total number of units of the bond or asset doesnât decrease. In contrast, a sell would reduce the number of units held, which isnât the case here. The bondholder still holds the same number of units, just with a reduced principal.
Bonds do not have units, they have a nominal value, and that does decrease.
Every bond is a title. If you have 100 bond titles of 1000 nominal that partly amortises 30% of their nominal value, how would you input a partial sell? How many titles and what price? Selling 30% of the titles would lead to having 70 titles of 1.000 nominal, when you actually have 100 titles of 700 nominal.
A feature to reduce cost basis / disinvest per title as proposed in the introduction of the OP would solve this problem.
1 Like
There are no âtitlesâ, there is only a nominal value. And indeed, it used to be 100000 and is then 70000, so all is fine.
(In fact, as a workaround to make percent price notation work, we often recommend using a ânumber of sharesâ of nominal value divided by 100, so in this example 1000 before and 700 after. But properly supporting nominal value is an altogether different topic.)
Could you walk me through the process of adjusting the nominal value using the current features in Portfolio Performance? For example, using the bond from the tables below and as the bond amortizes, how should I reflect this adjustment while keeping the number of titles (shares) unchanged?
This is the technical detail of the bond:
| Date | Amortization | Interest | Residual Value | Nominal Value | Cash Flow â Interest | Cash Flow â Amortization | Comments |
|---|---|---|---|---|---|---|---|
| 01/12/2021 | 0,00 % | 9,625 % | 100,00 % | 100 | Issue Date | ||
| 01/06/2022 | 2,00 % | 9,625 % | 98,00 % | 100 | 4,81 | 2,00 | First payment |
| 01/12/2022 | 3,50 % | 9,625 % | 95,00 % | 100 | 4,72 | 3,50 | |
| 01/06/2023 | 3,50 % | 9,625 % | 91,00 % | 100 | 4,55 | 3,50 | |
| 01/12/2023 | 7,00 % | 9,625 % | 84,00 % | 100 | 4,38 | 7,00 | |
| 01/06/2024 | 10,00 % | 9,625 % | 74,00 % | 100 | 4,04 | 10,00 | |
| 01/12/2024 | 10,00 % | 9,625 % | 64,00 % | 100 | 3,56 | 10,00 | |
| 01/06/2025 | 10,00 % | 9,625 % | 54,00 % | 100 | 3,08 | 10,00 | |
| 01/12/2025 | 10,00 % | 9,625 % | 44,00 % | 100 | 2,60 | 10,00 | |
| 01/06/2026 | 10,00 % | 9,625 % | 34,00 % | 100 | 2,12 | 10,00 | |
| 01/12/2026 | 10,00 % | 9,625 % | 24,00 % | 100 | 1,64 | 10,00 | |
| 01/06/2027 | 10,00 % | 9,625 % | 14,00 % | 100 | 1,16 | 10,00 | |
| 01/12/2027 | 14,00 % | 9,625 % | 0,00 % | 100 | 0,67 | 14,00 | Due Date |
Hereâs the movement of assets and cash flow:
| Date | Shares | Quote | Purchase Value | Market Value | Cash Flow â Interest | Cash Flow â Amortization | Cash Flow â Sell |
|---|---|---|---|---|---|---|---|
| 01/12/2021 | 500 | 1,000 | 500 | 500,00 | |||
| 01/06/2022 | 500 | 1,040 | 490 | 520,00 | 24,05 | 10,00 | |
| 01/12/2022 | 500 | 1,030 | 472,5 | 515,00 | 23,60 | 17,50 | |
| 01/06/2023 | 500 | 0,980 | 455 | 490,00 | 22,75 | 17,50 | |
| 01/12/2023 | 500 | 0,790 | 420 | 395,00 | 21,90 | 35,00 | |
| 01/06/2024 | 500 | 0,730 | 370 | 365,00 | 20,20 | 50,00 | |
| 01/12/2024 | 500 | 0,580 | 320 | 290,00 | 17,80 | 50,00 | |
| 01/06/2025 | 500 | 0,550 | 270 | 275,00 | 15,40 | 50,00 | |
| 01/12/2025 | 500 | 0,380 | 220 | 190,00 | 13,00 | 50,00 | |
| 01/06/2026 | 500 | 0,430 | 170 | 215,00 | 10,60 | 50,00 | |
| 01/12/2026 | 500 | 0,160 | 120 | 80,00 | 8,20 | 50,00 | |
| 01/06/2027 | 500 | 0,110 | 70 | 55,00 | 5,80 | 50,00 | |
| 01/12/2027 | 0 | 0 | 70 | 0,00 | 0,00 | 70,00 |
It would be really helpful if you could outline the exact steps to reflect this scenario accurately.
Remember that âCash Flow â Interestâ represents gains, while âCash Flow â Amortizationâ reflects capital reduction.
2 Likes
Trade matching code in PP is underfunctional (doesnât support short trades) and yet weird. Turns out, that weirdness is based in some usecases people have [with which Iâm not familiar]. Adding support for short trades yet keeping support for those usecases is pretty hard, and clearly requires understanding those weird usecases. So, Iâm doing mental gymnastics of trying to do that. Hereâs my notes on the issues raised in this thread.
Amortizing bonds
@chirluâs idea is pretty clear. Suppose you have a BondA which has nominal of 100 and its current price is 103.5. You want to buy 1 such bond. What you record is a transaction of buying 100 nominal units (shares) of it for 103.5. I assume that the coupon (dividend) and amortization payments happens at the same time, but of course ordered like that - first, dividend is paid on the current number of nominal units using the stated interest %, then amortization is paid. So, at the date of first payment, you record 4.81 divvy paid against 100 nominal units, then 2 units sold (and paid back to you) at the nominal price (i.e. 1). At the next payment date, you record divvy against 98 remaining shares, then sell next 3.5 of them, etc.
âCost basis modification transaction typeâ
Iâd say @Crisauâs argumentation has many questionable suggestions/claims, e.g.
Same happens for splits, and there is a transaction type for that.
Thereâs no âsplitâ transaction. Split is a destructive operation which irreversibly modifies historical quotes and earlier transactions (both optionally, per user guidance) to account for splitâs effect. You can in the same way modify your earlier transactions to pretend you bought at different prices than you actually did, to get the desired cost basis.
I would suggest a transaction type for cost basis modification. This transaction would add or subtract certain amount per share to the purchase price on the purchase transaction of every share still held (still not sold).
âof every share still heldâ sounds too magical, I understand why it led to response of âchocolate dividendâ. So far, all transactions have fields for specific amount and specific number of shares, so any new transaction would have such either.
But is a new transaction really needed? Delivery Outbound/Inbound is a magic pair which allows you do any kind of creative accounting. But you shouldnât try to do something with 0 shares. Contrary, you should do that with all the affected shares. Send (outbound delivery) them straight to heart of freezing hell of accounting madness, then next second (per the operation timestamp) bring them back. You can lose or spawn any number of shares in the process, or assign any valuations. For example, if you have 123 shares for which you want to drop cost basis for $1000 total, record:
Delivery Outbound of 123 shares for amount of X
Delivery Inbound of 123 share for amount of X - 1000
As discussion in Feedback on "Splits" section ¡ Issue #109 ¡ portfolio-performance/portfolio-help ¡ GitHub shows, the best value for X is the actual valuation of asset on the date of operation, that allows to have reasonable values for time-sensitive performance metrics. But as itâs for creative accounting, different choices are possible.
This idea is discussed in the PP manual: Recording a stock split - Portfolio Performance Manual . It suggests to Sell/Buy transactions for adjustments, Deliver Out/In is surely more clean (Deliver Out is effectively sell without crediting any cash, and Deliver In is buy without debiting it). OTOH, using a dedicated âbalanceâ account and Sell/Buy may be beneficial to have more visibility into operation and track multiple of them over time.
Summing up, I donât see, based on the discussion so far, a need for a new âadjust cost basisâ operation, because everything can be modelled by existing operation, which are already too many in PP.
The weirdest one isthe âtransferâ - one might think itâs equivalent of delivery outbound from one account and delivery inbound into another, but itâs actually not, because people expect that it maintains the original date of the original (non-transfer) transaction: BerĂźcksichtigung des initialen Anschaffungsdatums bei mehrmaligem Wertpapiertransfer - #15 by Rafa . Just think about it: a transaction done at date X should behave as if it was done at much earlier date. Thatâs weird. I wonder if all the time-related performance calculations in PP are correct in regard to that madness, because transfer date is clearly not fully correct, as that thread shows.
Bottom line: if someone comes up with a usecase where the original opening date is important (e.g. for future reordering), then Deliver Out/In idea falls apart, as it clearly doesnât preserve the original date.