FICA and other tax complications
Posted: Sun Jan 26, 2020 3:08 pm
The FPR is absolutely the best retirement planning tool I have ever seen. Kudos to its designers.
That said, I would like to point out one thing that makes modeling complex in a way that I think Is unnecessary, and propose what I think is a simple program modification to deal with it.
In order to use the tax feature, you must calculate an effective tax rate and enter it. That is not always easy. For example, My effective rate varies because I pay state and local tax on some of my income streams, but not all of them. I address this by doing some additional calculations which work (at least approximately) to get an effective rate - then figure out what that effective rate is as a percentage of the main rate entered, and say the income stream is partially tax exempt by the percentage. A little bit of a pain, but OK. But what about FICA and/or self-employment tax if the additional income is employment? This makes the tax greater than the primary rate. I then need to calculate these taxes as additional expenses and put them in as "additional input" expenses. Further, I think the "page 1" fields for "annual retirement income" would be interpreted by many people as income from post retirement work. FICA and/or self-employment tax come into play there, but cannot be addressed unless you calculate them and put them in as additional item expenses. I also find the "annual retirement income" field unusable because it offers no end date.
This is what I would suggest. Instead of having a "percent taxable" field for the "additional inputs" that are income, make that field "tax rate". That way a user can assign different tax rates to different income streams without messing with additional calculations. FICA or self-employment can be added to the rate without confusion. And behind the scenes, it is probably slightly (very slightly) easier to program. Secondly, because of the lack of a end date and the FICA and other taxation issues, eliminate the "annual retirement income" field, and force the users to put it in as an "additional input" field, where a tax rate and an end date are both required. I think this is lots clearer for the users, more flexible and I would imagine easier to program then any other solution.
Thanks for reading this. And once again, thanks for your wonderful program!
That said, I would like to point out one thing that makes modeling complex in a way that I think Is unnecessary, and propose what I think is a simple program modification to deal with it.
In order to use the tax feature, you must calculate an effective tax rate and enter it. That is not always easy. For example, My effective rate varies because I pay state and local tax on some of my income streams, but not all of them. I address this by doing some additional calculations which work (at least approximately) to get an effective rate - then figure out what that effective rate is as a percentage of the main rate entered, and say the income stream is partially tax exempt by the percentage. A little bit of a pain, but OK. But what about FICA and/or self-employment tax if the additional income is employment? This makes the tax greater than the primary rate. I then need to calculate these taxes as additional expenses and put them in as "additional input" expenses. Further, I think the "page 1" fields for "annual retirement income" would be interpreted by many people as income from post retirement work. FICA and/or self-employment tax come into play there, but cannot be addressed unless you calculate them and put them in as additional item expenses. I also find the "annual retirement income" field unusable because it offers no end date.
This is what I would suggest. Instead of having a "percent taxable" field for the "additional inputs" that are income, make that field "tax rate". That way a user can assign different tax rates to different income streams without messing with additional calculations. FICA or self-employment can be added to the rate without confusion. And behind the scenes, it is probably slightly (very slightly) easier to program. Secondly, because of the lack of a end date and the FICA and other taxation issues, eliminate the "annual retirement income" field, and force the users to put it in as an "additional input" field, where a tax rate and an end date are both required. I think this is lots clearer for the users, more flexible and I would imagine easier to program then any other solution.
Thanks for reading this. And once again, thanks for your wonderful program!