Reset cost basis on holdings from inheritance

[rlaggren]

Hi Mark

I am _not_ concerned with change of ownership, and the holdings show a "Purchase", usually many years ago and then a "Transfer" to move them into a common portfolio from the dozens or so brokers my parents held them in. That appears to be all proper and correct.

I think basis reset is a simple adjustment that I have figured out correctly, but I have reviewed a few posts here and am still not absolutely sure. Before I apply this to 150+ holdings, I would like to see if I can get a reality check.

For a stock to which a cost basis reset applies, with no other changes to the holding:

Enter, dated on the DOD of the deceased, one single ROC transaction with a negative amount to increase the cost basis to the MV for the stock on DOD. Memo to note purpose of transaction, "reset cost basis".

Does this provide the cost basis reset properly, with no other unwanted side affects?


Thanks for your attention.

Rufus

[Mark]

Hi Rufus,

Yes, a Return Of Capital distribution will lower your tax cost basis. There is one side effect of this, though, in that it will inflate the performance. It is a distribution, and will be treated as such in the return calculations. This type of distribution is treated special, in that it lowers your tax basis also. There are probably several ways you could handle this, I'm not sure there is one "best" way. You could transfer the shares to a new investment, you could sell/buy them into a new investment, etc.

[rlaggren]

Mark

That seems clear - GotIt, I think. Glad I asked. That might be a relevant "side affect" - have to think a bit. The Transfer sounds maybe the most "harmless" for the desired affect. I will give it a try and see how the reports look. It sounds like in order to show anything historic, I'd need to "do something" with the prior and new investment(s).

Any other transaction that affects the basis amount only? Do I recall there are custom transactions - could I construct what I want?

TBD.

Thanks.
Rufus

[Mark]

Hi Rufus,

The only way to change the cost basis, without buying/selling is with a Return Of Capital distribution. You can't define your own transactions.

[aviator]

An innocent bystander here, but I recently had to change the cost basis of a few investments.

Have you considered editing the original purchases? Increase or decrease the original purchase amount while keeping the share quantities the same. If preserving history is important, i.e. you want to keep the original purchases intact, create another sub-portfolio identical to the original in which you can experiment. Just a thought...

[rlaggren]

Aviator, great minds... <g>

I just came back to run an idea by Mark viz changing the first transaction to be a Transfer-In. I _think_ that would allow me to arbitrarily define basis. Except... As I think a little more, this great idea would probably be derailed by selecting Accout-by-Lots, or maybe FIFO. Each additional Transfer-In or, more importantly, each Distribution, would define another lot with its own basis and each/every one of those transactions would need to be reset to catch all the potential lots and apply the reset to _everything_ held on the DOD.

If Account-by-Lot processing is always global that means that the only way to reset all basises prior to a certain date is either to change the basis in every single lot-defining transaction or eliminate _all_ lots prior to that date.
But eliminating all potential lots (prior to DOD) will defeat the whole point of this exercise, because you could only do it by eliminating all the lot-creating transactions. Maintaining the transaction history as part of a single historical portfolio would be kaput.

I begin to see why, when reregistering a portfolio to a different owner, all the brokers insist on creating a completely new account. Goodness, is this the brokerage version of the speed of light? Nobody gets beyond it while remaining in the same universe?

Mark, am I right, that the bug-a-boo about reset w/in the same portfolio is the "basis by lot" accounting? As far as I've thought on this, it seems each lot has it's own basis (set by the transaction that created that lot) and there can, potentially, be a great many lots with a DRIP set up (hmm. Hope that is the right acronym...). Where else does the basis value get used in portfolio calculations besides tax calcs? Probably "Return on..." calcs? How about yield calcs? IOW, how important are those individual basis values in each lot? Are they used in just a few limited calcs or are the used _everywhere_ all the time (sorta speak)?

Regards,
Rufus

[Mark]

Hi Rufus,

If you have many transactions prior to the date you want to adjust the basis, you'd have to change all of them. It really doesn't matter whether you use a purchase or a transfer in. The only real difference between these 2 is that the transfer in allows you to have a separate cost basis date/value from the transfer date/market value. Purchases are simpler...

The tax basis figures are used in Capital Gains calculations. The amount you enter for your purchases also affects ROI calculations if the purchase is within a yield term.

[rlaggren]

Hi Mark

>...change each transacion...
Ok. Thanks for confirming. It was looking like that. <sigh>

>... affects CG...
Yes, that is the traditional consideration.

>... " ROI
Thanks, that is what I was asking. You can connect the dots much quicker than I can. This helps me decide the relative merits of the accounting method. I have a lot to consider.

I don't suppose FM would be amenable to adding a "Reset" transaction??? <sweet ingratiating sycophantic smile>

It would be a "mass edit" that hits all the lots. But on the face of it the logic seems fairly straight forward. Well, it's a thought. I don't see any costs (side affects) aside the direct programing time. All reports and graphs are done on the fly, right, so they just swallow the data as usual - nothing would change there. Preserving a history for "UnDo" might require an extra field or two, but backups prior (maybe as part of the Reset transaction) could avoid that need.

Cheers,
Rufus

[Mark]

Hi Rufus,

Thanks for the idea. That could get complicated quickly, but something to think about...

[rlaggren]

Mark

I wish I could actually help here. I think it would be a big feature. Inheritance is part and parcel of most portfolios, even though it hopefully doesn't come up more than once every 20-30 years. IF one wants to keep the history intact in one portfolio. That would seem very desirable in the case of trust ownership where the trust continues on, just with different trustees and beneficiaries, after the inheritance and reset.

Possibly you can package it as a completely separate program which can be purchased if needed. It would run separately from FM and would include it's own reporting and auditing in order to verify intended results and flag anything needing user intervention. Reports could, so show, in sample, what the program can do. I've rarely seen an automated mass change that didn't need a little clean up after. But that doesn't mean the automated part would not be a really huge help, and "cleanup can be guided by wizards.

I'm not in a position to know what all the implications are, and as you say, things can get complicated. But just as an example, based on recent experience, I'd say it was easily worth $100, additional, just for such a module. Quite possibly $200. As the number of holdings grows, the value grows of an automated helper grows very quickly. Any portfolio holding more than 40 (WAG) positions would start to make the Reset module look worthwhile.

One of the big selling points would be fewer errors. Not that a program cannot have bugs, but they are (usually) consistent bugs and once squashed, are gone. If a automation cannot do the job in certain cases, those cases remain consistent and can be consistently flagged for manual processing. A person doing _all_ manual editing can transpose numbers and letters here, but not there, and drop a decimal once in a while, etc in ways that can _very_ hard to track back to.

Another a significant value would be the dedicated reporting. Not just to verify the job was completed properly, but to provide a _record_ of what was done so when future questions arise about why/how-much for certain year or holding, there is a concise record that leads directly to the point of interest.

Well, it all depends on general interest in the option and on your ROI. I realize I'm in no position to 2nd guess there. Just wanted to try to lay out points and do justice as possible to something that would have certainly been a big help to me and looks like it might be worth considering at some point.

Regards,
Rufus

[Mark]

Hi Rufus,

Okay, thanks for the ideas...

[rlaggren]

Mark

Ok. I'm trying out the basis reset transactions, using an ROC and a split. I _think_ the shares entered in the ROC (in order to make the Reinvested-ROC transaction function, since it requires non-zero shares) are entirely arbitrary, on the theory that they will get "backed out" by the split. Just want to double check that is right.

I first tried using just 1 share on the theory that might make it very obvious that the share number was fake and also make the transaction simpler to remember how to construct. Did not work because for the 200::201 split, the calculations, probably because of rounding errors, gave me back tiny fractional values for what was originally a simple 200 share holding.

To make the ratio big and simple I entered 200 fake shares in the ROC and used a split 1::2 and got the nice whole number of 200 shares back as desired. Or (just recalled) is this tiny decimal problem a peculiarity of using the same date for both transactions? Seems I recall reading about a problem where a transaction pair would not balance exactly when entered for the same day - but place the 2nd one on the following day and everything works as expected. I'll see about testing this...

More broadly, is this the right concept and the right execution? On the face of it, I can't see why I would not just spec fake shares in some simple way (= the current holding) to avoid thought, computation, rounding error (if that's not the result of dates) and human error.

Not having gotten around to any distribution reports yet, I wonder if I'm disfiguring some reports in ways I'll regret in the future. However, it seems any of this type of manipulation with paired transactions requires "faking it" somewhere and _any_ "fake shares" in a transaction will distort reports, no? So messed up reports is kind of a given, using paired work-arounds for certain portfolio actions.

Just trying to see if I have understood this method correctly, so far. I suspect there is still much progress to be made.


Rufus

[Mark]

Hi Rufus,

It shouldn't be necessary to use a split. Just record a distributed (non-reinvested) distribution of type "Return of Capital". Distributed distributions don't require the entry for shares.

[rlaggren]

Hi Mark

Hmm. That sounds much neater. Maybe if I get this figured out finally, I can write up the Definitive Reset Crib. I will probably have explored most of the wrong turns by then. <g>

Rufus