At Techfi definitely, we were scared to go poking around in the cost module. Not only was it originally written by me (scary enough), but we didn’t have it locked down with unit tests, so we had no idea whether a change we made would cause something else to break. And if you break cost basis, every one of your users knows. Well, every one who looks at their reports at any rate.

You are so right about the lack of understanding with cost basis particularly with the PM vendors. I tried to explain it to Dusty at DBCams, but they still did a horrible job of impletmenting it (he actually said it wasn’t important because he wasn’t getting requests for better tax accounting from users). With PortfolioCenter, I thought they would have redesigned tax lot accounting when they changed to SQL, but from what I can tell they migrated their design flaws right on over.

The folks at Poweradvisor did a pretty good job on the basic design- the best of any of the systems I’ve seen. As you point out there are a lot of little tools and processes to make it friendly, which even PA is short on.

If custodians are required to keep that info, there will still be some needed pieces in a portfolio management system, for one to deal with lot specification when trades are made. Ideally for us, we want to be able to see the gain/loss impact of recommended changes, and then have the lots we picked communicated in the trade communication to the custodian, since the IRS says its FIFO unless communicated to the broker at time of execution.

You also have to have a “lock down” when average is used, since you can never go back with a fund once you’ve used average.

You could also solve the problem of cost basis transferring when assets move from one custodian to another, or when gifted, if positions are not one to one with accounts. Instead, if you use something like a location table with date in/date out, trade lots would be associated correctly with the position rather than account. They also wouldn’t blink out of existence during transfer.