I really nice feature would be to be able to update balances of accounts throughout the year and account for remaining year returns etc. Other products have this feature. If using the current end of 2024 balance the values can get way off especially with incremental increase/decreases on other income that are not always predicted. Some tools have the ability to bring in external account information on demand or when using the product. I don't see that that level is necessary but being able to update to the current date makes a lot of sense if possible.
I agree that it would be a nice feature and we’ve certainly considered it; however, it is very problematic and at least for now we’ve elected to stay with initial balances that are start-of-year balances. Here are just a few potential issues that would have to be addressed if we allowed initial balances on arbitrary dates during the year:
- Let’s assume you define an income stream that is in effect on the model’s starting date but is lumpy by nature (that is, it doesn’t come in a fixed amount every week or month). If you specify initial account balances on some arbitrary date during the first year, how does the model know how much of that income stream has already been received and is reflected in the initial account balances? Prorating the income stream can be a source of error.
- Same as #1, but with lumpy expenses.
- If you are doing Roth conversions in the first year, how will the tool know how much of the annual conversion had already been accomplished on the date the initial account balances were specified?
- If you are already taking RMDs in the model’s first year, how will the model know whether and to what extent the initial account balances reflect those RMDs having been taken?
- How would the model account for the taxes on unscheduled withdrawals taken prior to the model’s starting date?
- How would the model account for dividends paid before the model’s starting date, and the associated taxes?
I could go on, but I think this should shed some light on why we’re reluctant to open this particular can of worms in the Pralana design.
Stuart
The ability to revise assets in July (like Pralana gold) will go some way to getting around this issue.
I suspect that other tools that update things any old time are just ignoring all the issues Stuart mentioned. If you are good with ignoring those and other issues, you can enter updated account values any time and just understand that the first year is off-kilter. For big picture stuff, that may be OK.
Having worked through the other issues around retirement, my main use of Pralana these days is to plan Roth Conversions and to do that, I want more accurate numbers. In practice, I only do my Roth Conversions near the end of the year when income and expenses for the year are known and we have the brokerage's estimate for 4Q dividends to go along with actual for the other quarters. I then make manual adjustments to the starting values for the year so that income, taxes, ending values, etc. for each account will be right. That takes some manual effort to work out adjustments for everything, but for us it's the only time of year that works well.
@jlevas The privacy aspect has always been a big attraction for Pralana. No linking your accounts. No account numbers needed, not even last names! This is a long-range planning tool, mapping out decades of your financial life. There's really no reason to be updating it with more than start of year balances. Even with it now being online, that's a major reason my clients use it. The linking accounts thing "other" tools do is primarily for them to grab that very valuable data on you, sell it, and use it to sell more to you. It's a major hacking concern. I've had it out of necessity in my past cash flow monitoring and other tools, and it's *always* a mess as APIs and protocols change.
@jkandell Well, the fact is that Pralana Gold ignores most of these issues in doing that mid-year adjustment, as @ricke suspects that other tools do. Of course, I agree with him on that point.
Oh, got it: I naively thought those issues didn't arise back when I used Pralana Gold! Oh the innocence of youth. Wait that was only a year ago....
Hi Stuart,
not trying to be argumentative; rather just want to provide a counterpoint.
- Let’s assume you define an income stream that is in effect on the model’s starting date but is lumpy by nature (that is, it doesn’t come in a fixed amount every week or month). If you specify initial account balances on some arbitrary date during the first year, how does the model know how much of that income stream has already been received and is reflected in the initial account balances? Prorating the income stream can be a source of error.
- Same as #1, but with lumpy expenses
When doing a mid-year update, the software could simply ASK; eg; it could ask the user "You had previously projected $XXX of income during the year; how much of that have you received so far? Alternatively, would you like me to simply estimate (eg if you are in April, assume 4/12 of the income has been received?)"
To the bolded point, yes, of course it could be a source of error, but is doing nothing better than doing something, even if approximate?
- If you are doing Roth conversions in the first year, how will the tool know how much of the annual conversion had already been accomplished on the date the initial account balances were specified?
- If you are already taking RMDs in the model’s first year, how will the model know whether and to what extent the initial account balances reflect those RMDs having been taken?
Similarly, just tell the software what you've done.
- How would the model account for the taxes on unscheduled withdrawals taken prior to the model’s starting date?
Yes, this is more complex. Again, simple tell the software what you've done, or ask the user if the tax implications should be ignored.
- How would the model account for dividends paid before the model’s starting date, and the associated taxes?
Same answer as the one above plus answer to #1
I would also add:
1. You mention lumpy expenses. We all have times where there unexpected expenses or outlays. Eg, unexpected car purchase, or maybe an unexpected real estate opportunity, etc. It would be valuable to be able to update the balances mid-year or even quarterly to reflect this.
2. What happens if mid-year market returns are significantly above or below estimations? Would be valuable to be able to update balances to reflect this.
Etc.
IMHO, You are raising valid points, but perhaps letting "perfect" get in the way of "good enough"! Thanks for listening!
@larryc Thanks, Larry, for your thoughts on this subject! I do appreciate them and we'll take them into consideration as we continue to ponder this topic. I don't intend to engage in a debate but will offer you another way of dealing with the other thoughts you added regarding unexpected car or real estate purchases in the first year, and market returns being significantly higher or lower than expected in the first year. For those lumpy expenses, you can simply add them in mid-year, and the end-of-year balances will be just fine without worrying about mid-year effects on account balances. If you believe that market returns are going to be significantly above or below long-term expectations in the first year, you can create a one-year time period and set the returns for that period based on the way you see the first year playing out. That's definitely a bit of a pain, but so is having to tell the model all the things you suggested in your first response regarding income, expenses, unscheduled withdrawals, Roth conversions, etc. Regardless, we want to keep making Pralana better so we'll continue studying this topic.
Stuart
@jlevas HI Jamie, and thanks for your follow-on comments, but I can assure you that prorating without additional explicit information is problematic and can potentially create larger errors than those you are seeking to avoid. I like Larry's suggestion for how to accomplish mid-year updates and we would need to do something akin to that if we elected to go down this road. Please note, though, that you currently have the option of creating a one-year time period for the first year where you can set the market returns higher or lower than your long-term expectations if you so choose. Yes, that's a bit of a pain, but so is trying to tell the tool how to prorate income, expenses, Roth conversionsm etc, for the first year.
Stuart
The programming techniques are certainly do-able, I run through them manually in our case each year towards the end of the year. From a programmer's standpoint, they would have create input forms to allow supplemental first year information for each account balance, income type and expense type to allow the user to enter what's already happened vs. forecast and there has to be an input date so the program can project the remainder of the year. That's a really big task and potentially creates unexpected input problems - maybe you've already done Roth Conversions that exceed what the program thinks you should do if the market has taken a dive or maybe the year's market history was complex, where you timed a conversion perfectly when the market was down and now the Roth has shot up in value. Note that once you input all that and a couple months pass, you would have to review all the input again to see what has changed.
I think it would be a tremendous amount of effort, a many months-long build that would delay lots of other cool features and improvements.
However, the current method, which is impacted by potentially volatile return rates, doesn’t provide sufficient accuracy for the current year, impacting decisions later in the year.
But this is a long-range financial planning tool, not a "this year" tax planning tool. I'd hate to see it crippled by trying to be all things to everyone, a financial swiss army knife. I've seen other great products go down in flames by trying to do so.
When we work with clients, we do our "this year" tax decisions by using a tool designed to give us that precision. Using a drill to drill, hammer to hammer. We use Holistiplan, which allows us to import the last year tax return as a baseline, then in early December we use *current* *accurate* data (final brokerage numbers, pay stubs, etc) to plug in the deltas for this year, and get *precise* guidance from the tool on doing end of year Roth conversions, loss/gain harvesting, charitable giving, and many other tax matters. It allows us to visually see the guardrails we want to avoid like IRMAA, LTCG brackets, ACA premium tax credits, and more. You don't use a tool that's based on assumptions, standard deviations, foreward forecasting to make these short term decisions. You could do it yourself using the dinkytown.net tax tool, early release versions of your favorite tax software, etc.
The bonus is that after all that's done, we can then run the tax reports from Pralana, look at what it was thinking our end of year account balances should be, Roth conversions should be, and see if it's all in the ballpark. If not, there may be an error in our pralana settings, or even our tax calcs, or it was just an outlier year where the investment returns were way out of balance up or down.
I agree with @hines202. I think any enhancements should be limited to longer term term results and simulations.
Thanks folks for all your inputs on this subject. Given the complexity of this feature, we will definitely not be making any near-term changes in this area and will continue focusing on enhancements that are consistent with our goal of providing a great long-term planning tool and that benefit the majority of our users.
Stuart
