nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Estimated Tax math in Planner seems incorrect

leishirsute

Using Deluxe R36.57 .

Maybe I'm looking at this incorrectly, but I can't figure out how the Tax Planner is calculating the estimated taxes paid.

From the picture, the amounts in the actual transactions don't add up to the 1040-ES line total.

Am I reading this wrong?

Find more posts tagged with

Windows

Tax Planner

Comments

markus1957

Strange. R37.66 adds up my 2021 estimated taxes correctly.

leishirsute

markus1957 said:

Strange. R37.66 adds up my 2021 estimated taxes correctly.

Good to know. Maybe it's been fixed since R36.57.

Chris_QPW

leishirsute said:

markus1957 said:

Strange. R37.66 adds up my 2021 estimated taxes correctly.

Good to know. Maybe it's been fixed since R36.57.

Mine looks fine in both R36.57 and R37.66.

That is a strange number 21724 - 1692 = 5432 which doesn't match any of your payments.

leishirsute

I agree. I can't figure it out.

leishirsute

Here's that actual payments estimated tax payments made in 2021.

As you can see none of the math works out with the tax planner and the tax planner used a payment made in 2022. Very bizarre behavior or I'm misreading something. Oh well, thankfully I can put in an adjustment in the planner.

Chris_QPW

leishirsute said:

Here's that actual payments estimated tax payments made in 2021.
As you can see none of the math works out with the tax planner and the tax planner used a payment made in 2022. Very bizarre behavior or I'm misreading something. Oh well, thankfully I can put in an adjustment in the planner.

Not that I think it matters, but you are showing the January payment for 2020, not 2021.

leishirsute

I agree, But the payment date was in 1/14/2021. The tax planner did not pick up a payment made in 2021, unless the planner is now parsing memo comments.

Chris_QPW

leishirsute said:

I agree, But the payment date was in 1/14/2021. The tax planner did not pick up a payment made in 202, unless the planner is now parsing memo comments.

That's why I said I don't think it matters. Note even if Quicken "read comments" it still has the wrong amount.

Rocket J Squirrel

Quicken understands that an estimated tax payment in January is for the previous year.

But I have no explanation for the weird math @leishirsute is seeing in the planner.

leishirsute

I think I solved the confusion. On 3/22/2021, I received a tax refund of $5432 from 2020 taxes, the amount different in the tax planner. The tax planner does not show the refund transaction even though it has the same category as the tax payments:

This seems to me a flaw that the tax planner does not list the refund in the transactions list, yet uses the amount in the calculations. In any event, I understand what is going on now.

Rocket J Squirrel

A refund for TY2020 should not count as a payment for TY2021. I use a different category for refunds to keep them separate.

Chris_QPW

It is interesting that the Tax Planner didn't show that transaction in the details, but that is probably because they wrote special code to deal with the unusual pattern of payment estimated taxes have.

I agree with @Rocket J Squirrel your refund isn't an estimated tax payment, so it shouldn't be in that category.

leishirsute

@Rocket J Squirrel What tax category do you use for refunds?

Also, why is the refund amount being used in the calculations and the transaction not shown in the transaction details?

I'll stick with just adjusting the amount in the tax planner due to a refund and the tax planner not showing all the transaction details involved in a computation.

I've reported this as a bug since the transaction detail does not match the amount in the 1040-ES line. Either show the refund transaction and leave the amount on the 1040-ES line as is or don't use the refund in the computations so that it matches the current transaction detail (this would be my preference).

q_lurker

Refund -- I too manage refunds differently, but I manage all my tax payments differently as well. For example, I have different categories for estimated payments and withheld payments. But beyond that ...

Why shouldn't the refund be applied back to the same category? That is the common recommendation for when we return items - apply the 'refund' to the same category.

Now clearly here, Quicken is somehow applying that to the total estimated 2021 taxes (because it occurred in 2021?) rather than applying it as a 2020 tax 'payment' (because somehow it was supposed to know that too.) But that 'error' is on Quicken, not the user, IMO.

I've often felt Quicken's tax handling had too much hidden away from the user.

markus1957

Not so much now but prior to recent tax law changes, some portion of a refund could be taxable if the taxpayer itemized deductions. This makes them different than a typical retail return.

IMO, the "bug" is not displaying a value assigned a category that is being used in the calculation, but the practice of using the same category for a tax refund and tax payment, particularly ones that apply to different years, is a bad one that cannot be resolved with coding changes.

leishirsute

@markus1957 I agree that the issue is more that the calculation does not match the transaction detail.

Rocket J Squirrel

leishirsute said:

@Rocket J Squirrel What tax category do you use for refunds?

Over the years, I've evolved my own set of tax categories different from the defaults. I'll show it below. I don't see a need to include tax refunds in any calculations; they only show up on reports. I happen to use a separate top-level category for them, which moves them out of the total tax computation. You could still make them subcats of "Tax" so they will roll up in reports, but they need to be in a category that does not share the "estimated tax" TLI.

This is what I use. I'd guess nobody else uses the exact same set of cats, but it works for me. And if it doesn't, it's easy enough to change.

Image: https://us.v-cdn.net/6031128/uploads/editor/4m/x2pdld1n5kdd.png

Chris_QPW

The biggest problem I see with using the estimated tax category for a tax refund is that you are assuming that is where it came from, and that might not be the case.

When I buy a shirt and then return it, there is no doubt what category I need to credit.

When I pay taxes some of it comes from paying estimated taxes, some of it comes from my wife's deduction from here salary, and some of it might come from my checking account where I still owed some more tax.

I might add that if I got a vote, I would vote against changing Quicken's tax planner for this.
The handling of this is already complicated by the fact that the January payment is included in the year before. And now you want it also to understand that if you put in a "negative payment" no matter if it is in January or February, or March or April, and even beyond because of filling extensions, that it should treat it as an adjustment for last year?

Also estimated taxes have some "interesting" ramifications. Say I pay $1000 for the first payment, but in reality, that quarter should have been $2000. If by the end of the year I get in enough payments that I "balance" then it will "go unnoticed". But if I don't get it balanced at the end of the year and I have to pay a penalty it is going to look back at each estimated payment and start the penalty from the point where I didn't balance, as in start on that first quarter.

The point is that estimated tax payments are also "quarter based", and as such you really don't know which quarter you are getting the refund for so that you can "properly" account for which one(s) should be reduced. This part is "nit picking", but it illustrates that a refund for your taxes isn't really the same as returning a shirt. And changing Quicken to handle it seems like asking for trouble.

leishirsute

However in quicken, doesn’t the tax planner just look at categories? If fact, in the planner I can select the link tin the detail to see what categories were used to gather transactions. The problem I see is that quicken is not showing all transactions used to calculate an amount even though those transactions are associated to the same category. You seem to be describing a workaround for a flaw in the quicken planner. The planner is using categories to calculate the estimated taxes but not to display those transactions. It is not behaving consistently. I don’t want it to understand, I want it to show all ytd transactions in the tax payment category as the detail describes it is showing when it is actually not. I want it to show all transactions detail. used in a calculation and not misrepresent the amounts the detail and the calculation. I have no problem with quicken calculating the 1040es amount with the refund included. I have a problem with quicken not displaying the refund transaction in the transaction detail since it used it in the calculation.

leishirsute

@Rocket J Squirrel thank you for sharing the categories.

Chris_QPW

@leishirsute let me see if I can clear up my viewpoint on this.

It is definitely a bug that Quicken has this number here:

Image: https://us.v-cdn.net/6031128/uploads/editor/2i/uhng33kujjlz.png

And it doesn't add up here:

Image: https://us.v-cdn.net/6031128/uploads/editor/ht/w0xx4vlqceed.png

Above all things, Quicken should be consistent with itself!

On the other hand, I don't extend that to "Quicken should take into account that you are using the estimated tax category for refunds.".

Normally you would be right, that Quicken just gathers the transactions from a given set of categories (note is the tax line that mostly counts not the category itself) and reports on it.

But the screwed up "tax quarters" makes this one entry "tricky". In programming the easiest is when there aren't any exceptions. But that payment in January is just such an exception. They had to right special code to go out and "collect it for the year before".

If they now go in and say we need more "exception code" to deal with refunds, there isn't any telling what they might also mess up.

Note the very fact that it comes up inconsistent implies that they have two separate parts of the code that are trying to deal with this complication and doing something different. That doesn't give me a high level of confidence they will fix it in a way that won't mess up other things.

Maybe I'm just being too pessimistic, and the actual fix is to fix the inconsistency by allowing for the fact that people might use the category for refunds. Of course, you are assuming that they are going to make this change for you when no one else has ever reported this as a problem. That to me seems very optimistic.

leishirsute

I understand your point. Thank you. I actually think it clever that Quicken selected the january payment transaction as an estimated payment.

I just expect the transaction detail to match the 1040-ES amount, by either omitting the refund transaction from the calculation or showing the refund transaction in the YTD detail information if it was used in the 1040-ES calculation.

Now that I know what is going on, it is minor adjustment to add the refund amount into the Adjustment Column.

I have no idea the difficulty or ease it will take to fix this problem. They obviously managed to somehow include the refund in the calculations. It seems they could include the refund transaction in the detail similarly.

"If they now go in and say we need more "exception code" to deal with refunds"

They have already done that when they included the refund in the 1040-ES calculation.

As far as never reported before as a problem, there's always a first time.

Chris_QPW

Note given that this is a "first time" I would also submit the problem using Help -> Report a problem

leishirsute

@Chris_QPW I've already submitted the problem including the screen shots. However, a situation like this may be the reason the Tax Planner has an Adjustments column. Once I understood the real transactions involved in the calculation. it was an easy adjustment to correct manually.

q_lurker

@leishirsute - How about a check? Right-click on the refund transaction. Choose the "tax Line assignment" option. What tax line shows up?

While you have identified that you used the category "Tax:Federal Income Tax" for that and other tax transactions, I am curious what tax line you have assigned to that category. You can confirm that by editing the category details. Lacking other action on your part, the same tax line applied to the category would also apply to the transaction. The behavior you are showing suggests the tax line might be: "Form 1040:Federal estimated tax, qrtrly".

Back to the actual transaction -- You can override the pre-assigned tax line for that specific transaction. If it is the "Form 1040:Federal estimated tax, qrtrly", try deleting that. See what that does to the tax planner.

My observations

Quicken's tax planner module is programmed well enough to identify that the January payments are applicable to the prior year's taxes. The tax schedule and tax summary reports are similarly programmed. If there is a tax payment made in January, 21, the reports for 2020 will look ahead and include that transaction. If you specify custom dates for the full year (1/1 - 12/31), it will look ahead. Any custom dates longer or shorter than the full year will omit that look ahead.

Beyond that, I don't know what their methodology is. Is it driven by: payee, category, tax line assignment, dates, intuition? I would hope tax line assignment would be the primary factor, but I would also hope that would 'require' the tax line I cited above. Somehow I am skeptical that such is the case.

In my own case, I have a Tax:Federal:Estimated category with that line assignment and data flows through the reports as I would expect. (I tend not to use the tax planner, so I can't comment on behavior there.)

Sorry I do not have enough time to pursue the many possibilities right now to better determine how Quicken manages these processes.

leishirsute

@q_lurker That was an excellent suggestion.

The refund was assigned: Form 1040:Federal estimated tax, qrtrly

Image: https://us.v-cdn.net/6031128/uploads/editor/2t/e7kht1gvcak7.jpg

Once I deleted the tax assignment for that single transaction, the tax planner 1040-ES calculation matched the transaction details. I think you solved the the issue. The bug still remains that the transaction detail does not list all the transactions used in the 1040ES calculation, but I tend to agree that a refund is not a payment and the tax line assignment should be removed.

I didn't realize a tax assignment could be removed for a single transaction.

Image: https://us.v-cdn.net/6031128/uploads/editor/qn/vasjydbwz6db.jpg

Thank you for the suggestion.

markus1957

To be clear, Quicken did not automatically assign that tax line to the category. That was manually assigned by the user, probably long ago. When it comes to categories and taxes, with few exceptions, each tax line needed by a user should have its own category.

leishirsute

Good point. It was most likely a long time ago assigned. It's still a bug that the tax planner includes a transaction in the tax calculation that it doesn't show in the transaction detail.

q_lurker

So apparently your category "Tax:Federal Income Tax" has the Form 1040 estimated tax line assigned to it. In line with @markus1957 comment, I have a Tax:Federal category (no tax line assignment), and a Tax:Federal:Estimated category with that 1040 estimated line assigned there. The operation significance would be that the four estimated payments would go to that second category and any April 15 payments (or refunds) would go to the upper level category. I suggest you consider a modification to your categories rather than 'remembering' when to adjust an individual transaction. Some might prefer an alternate approach where the upper level category gets no transactions assigned, they all go to categories at the lowest level. Make your choices accordingly.

[In my personal approach and file, I make it more complicated than that. I will skip those details as not appropriate for anyone but me.]

leishirsute

The only reason there is a need to adjust an individual transaction's tax line assignment is to accommodate a bug in Quicken and unburden Quicken with the task of displaying all transactions used in the calculation of 1040-ES in the tax planner. Had Quicken correctly displayed all transactions associated with the calculation, I would have immediately understood how it derived its calculated amount and would have adjusted the tax planner Adjustment Column.