In certain situations, you need to use sales tax as part of the itemized tax. However, the ProConnect computed sales tax wrong. I know it because I compared it with the IRS sales tax calculator, and the numbers are different, some times it is quite large. I further discovered that that is due to the local tax that the ProConnect omitted altogether. After I put in the local rate, then it is the same as the IRS value.
I reported this via chat, but I do not know where the issue stands, and that is why you should vote for the idea that we should be able to create a case.
I would like to post this problem here seeking comments before I post this as a bug in the idea exchange board. It is a bug instead of enhancement because we generally expect it to work. Intuit may not agree with me and most often they don't, but for me if you press the gas panel and you expect the car to run but it doesn't, it is a bug, but if you want it to fly, it is an enhancement.
You are absolutely correct. I believe this is another major difference between ProConnect and Lacerte. Lacerte has an ability to set up many Options, including local sales tax rate. That is useful when the major of clients are in the same table area. Where I live, even that does not really work and I need to go in and set the rate EVERY YEAR for EVERY CLIENT, which is what you need to do in ProConnect IF sales tax is really an item that affects the return.
Ideally the software would take care of this via the zip code of the client, but since more taxpayers would use state tax over sales tax, the likelihood of that being implement is probably slim to none.
@puravidapto Take a look at this thread. If it doesn't help, please provide the relevant details about your case and the expected outcome.
Still an AllStar
I understand that if you put the correct local tax rate, things come up okay. It should be automatic as PTO knows where the taxpayer lives.
No, it doesn't know where people live. What you have entered are only the mailing address at the time of filing and state residency during the tax year in question (but only if state return is required). There are not sufficient details for PTO to determine the locality and the period of residency, except for jurisdictions where local returns are required.
Of course you can have additional input fields built in just for that purpose but that's different from saying that PTO already has the details needed to automate the computation. Costs/benefits of the programming and its ongoing maintenance would be a consideration - and that would be for Intuit to decide.
Still an AllStar
I agree with you in theory, but it is a matter how things should be optimized.
For example, when I enter a taxpayer, the system does not have enough information to determine whether it should use form 1040 or 1040-NR, but it does not just sit there doing nothing but assume it is form 1040 which is the most common until we instruct it otherwise.
Same here with the local tax. The most common is that the address is the taxpayer's home address and he lives there the entire year. If it is not the case, then we should intervene and do the needful. Looking up the tax rate from the zip code does not seem to be that formidable task.
@puravidapto "It should be automatic as PTO knows where the taxpayer lives."
No, the program doesn't know where the taxpayer lives, and more importantly, where the taxpayer shops. For example, some of my clients have a mailing address of Glendale 85304, but they actually live in Phoenix. The Post Office drew the ZIP Code boundaries before the cities annexed the territory. The rate in Glendale is 2.9%; in Phoenix, 2.3%. So, many of the people who actually do live in Glendale still do their shopping (sometimes, just across the street) in Phoenix.
How long does it take to insert the most accurate rate in the program? 30 seconds? Be careful what you ask for, you might get it. Self-driving vehicles are already threatening to put thousands of taxi drivers and teamsters out of work.
"No, the program doesn't know where the taxpayer lives, and more importantly, where the taxpayer shops."
If the program does not know where the taxpayer lives and shops, how does it know that the local tax rate is zero?
"...how does it know that the local tax rate is zero?"
How does it know that it ISN'T zero? You'd rather have to program compute something, add it in, then you have to proactively go back and take it out?
That leaves room for a lot of 'overstatement' of a deduction IMHO.
Not every single ZIP code in CA (where I practice) has a local sales tax added to the base, state wide sales tax.
If a post answers your question, click on *Accept as solution* for future searches
"How does it know that it ISN'T zero? You'd rather have to program compute something, add it in, then you have to proactively go back and take it out?"
It is not a random "something" but something most likely accurate. True that they are not 100% sure, but if they have to choose a default value between zero and local tax rate based on zip code, which one is a better choice? Let me illustrate with an example:
When we enter a dependent. the program's default value is that the dependent lives with the taxpayer, which is a most likely case, so it is a reasonable choice. If the dependent does not live with the taxpayer, then we go in and make appropriate change.
Ultimately we are responsible for the accuracy. Would you rather see the system is 99% of times correct and we just need to make changes for 1% of the cases, or the other way around?
If the IRS can do it with its sales tax calculator, I do not know why PTO cannot do it. I often have to run the IRS calculator, and copy the numbers to the program. I simply ask to automate the process. Are you suggesting that we should lookup manually each time? There isn't much value add to the process.
You said "Not every single ZIP code in CA has a local sales tax", that is fine. I am suggesting the PTO looks it up, and if it is zero, then we know it is zero, it is better than it does not look up and blindly put it as zero.
There should be an existing database, so it might be easier than we think, but anyway I think we should leave the implementation details to the company to worry about.
You are missing the point that the ZIP code of the mailing address does not necessarily translate to where the shopping is done. Maybe in your world it does; I don't consider it a valid assumption for the entire country.
If a post answers your question, click on *Accept as solution* for future searches
- In the past years, Intuit does not make some important changes, such as water mark, fixed pricing, etc. These changes will come up automatically without us asking for it.
- If we ask for it, we may not get it, or may not get it immediately. However if we do not ask, it will not come. That is why I think you should vote, of course if you want to see the change happen. As it is stands right now, the company will think that I am the only one who needs it.
- Voting does not need unlimited resources. As for the company's resources, we do not know what it takes to implement, we should have our issues reported and it is up to the company to prioritize. The idea exchange board is not perfect, but that is what we have and we should work with what we have.
In retrospect there evidently was a time and a place for Intuit’s thumb down voting system. Maybe we should think about voting on whether or not that should be resurrected from the grave 😜
If you oppose the idea, you can always add a comment to state your reason and ask the company will never implement the idea. For me, the automatic feature saves me many times. It often occurs to me after I filed a return, I thought of "did I do this", "did I do that", and when I checked, thanks God, it was automatic.
I argue with reason. I do not know what you are against, so I cannot argue but provide an alternative way for thumb down.
@puravidaptoDon't get us wrong. It's totally within your right to submit your requests. There's no question that requests such as this, if implemented, could be helpful and would benefit everyone.
Given the limited resources Intuit would allocate to development, from experience, however, and knowing there are outstanding issues that have yet to be resolved, one would hope Intuit will prioritize what is more critical and impactful.
Similarly, genuine bugs should take precedent over enhancements. A bug is what causes an error and that includes faulty tax logic, which may be obscure or difficult/impossible to fix by users without causing other issues, like the ones related to multi-year sourcing for §911, scaledown ratios for FTC of fiscal year jurisdictions, and CT-2210 annualization of PY residents, just to name a few. Enhancements, on the other hand, are those that are good-to-have, things that could improve user experience. This request would be one example and a request to automate the highly complex computation as well as flow of PFIC could be another. A clear distinction needs to be made between a bug and an enhancement - unfortunately, Intuit often treats bug reporting as just another enhancement request.
Still an AllStar
I just reported a problem and request a fix. I did not dictate when and how it is fixed, for example, I am not asking that my issues should be fixed before your issues. I assume they have their way of prioritization for all the issues reported and use their resources appropriately.
I cannot prioritize all the issues. First of all, I do not see all the issues. Secondly, there are issues irrelevant to me, for example, I do not have a client who is a part of year resident of CT, but I do not make the judgement that it is not an important issue as it is a critical issue to you. Thirdly, I am not in charge of their development team, so I cannot determine how they should use resources. Therefore, I do as what a user can do: report the issue and let the issue run its due course.
I can see a number of ways the issue can be fixed: may be it is a simple call to assign local sales tax rate a value, or they could just raise a critical warning when local sales tax is used for us to manually assign the local sales tax rate a value if automation is not supported. It could be also possible that they have an intern developer, and want her to have all the small easy issues fixed first, in the same way for people who have fewer than 5 items in the supermarket go through the fast lane. Since we do not know what the company wants to do and we do not control their resources, I feel it is premature trying to prioritizing among ourselves. Let us do our job and they do theirs.
I do not know where your issues are logged. If you have your issues posted, I will vote for the issues that affected me, and I promise you that I will not thumb down your issues that do not apply to me, as I know they are important to you.
Please vote FOR the issues that affected you, or potentially affected you. Someone has taken the time to write up, please take a few seconds to vote, thank you, the link is in my signature.
"I argue with reason. I do not know what you are against, so I cannot argue but provide an alternative way for thumb down."
But you don't agree with reason. You completely blew off what the other folks said. That's what I am against. Based on this and past posts you appear to have tunnel vision, and I guess tunnel hearing, and don't like to listen to what anybody here has to say when they try to offer meaningful advice.
"But you don't agree with reason. You completely blew off what the other folks said."
I do not know how you concluded that. For example, people told me that PTO does not necessarily know where people live and where people shop, I acknowledged and agreed on that, and build my reasoning based on that. Someone suggested that I write up and report my issues on the idea exchange board, and I did exactly that. I just do not agree that Intuit cannot change and we should not report issues because I do not see Intuit change, water mark, for example.
I would like to respond if you have specific issues.