Automated Tax Calculations Incorrect

@beckyrisch & @adamrobisch:

I’m sorry this has been so slow to resolve. ??

When we initially found the bug, it was happening for a couple States (not just CO) and the fix that TaxJar had for that issue partially resolved the problem. However, more recently we found that CO still had a similar, unresolved bug, so we passed along that info to the TaxJar team. They were able to identify the cause from their end and were in the process of creating the fix, however, since we haven’t heard anything recently, I’ve reached out to see where they are at in the fix/release process. As soon as I know more, I’ll update this thread.

Thanks for sharing that helpful info, Becky, and thanks to everyone else who has provided info and patiently waited for this to be resolved. Again, I’m terribly sorry about how long this has taken, but I will let you all know what is happening soon.

@beckyrisch @adamrobisch @czeller @npuana @patvanb6 @ageekonabike @hluoma –

We just heard back from TaxJar and they have pushed the fix live!

I just tested this myself using an example from Denver that previously was only returning 4% and it is now correctly returning 8.31%.

This fix should resolve all of the remaining issues for Colorado, but if any of you notice anything that doesn’t seem to be correct, please let me know.

It’s not working for me… the calculations are not correct. Glenwood Springs returned a rate of 4.75% and it should be 8.6%. My client is asking to move to Shopify ??

Hey @czeller,

I just tested Glenwood Springs and it is returning 8.6%, as seen in this screenshot:

https://cld.wthms.co/LzQgR1

Can you make sure that your client’s site is using version 1.19.0 of WooCommerce Services?

I don’t know if this has truly been fixed since some of us are still having problems. My current solution is to have the tax rates determined by zip code, for every current zip code in Colorado. Any cities that share the same cumulative tax rates are grouped together. Keep in mind that this does not break out taxes by county or district but it gets a more accurate rate for houses in different counties within the same city. In order to get that information correct, I use https://www.taxjar.com/sales-tax-calculator/ to get the tax distribution breakout. (I hope I’m making sense here.)

Again not a long term solution as taxes will change but this is as close to what we can get to “rooftop” accuracy.

Here’s a link to the tax rate table for the individual zip codes.
https://drive.google.com/open?id=1czBaWeTSVJEwpeWqJ8iNf4pswDAl53ei
Feel free to use the file if you’re still having issues. Please note that automated taxes should be disabled if you use this rate table.

• This reply was modified 5 years, 8 months ago by npuana. Reason: additional info

@shaunkusche One additional thing to note. The address used in your example doesn’t exist. For that street address, the city shows to be Denver and the correct zip code is 80202-5030. The correct address is 1450 Glenarm Pl Denver CO 80202-5030. How does WooServices determine the tax rate, just by the city?

Please note, the actual tax rate for the corrected address is 8.310% according to multiple tax calculators, including TaxJar and Avalara.

Hey @npuana,

Yes, you are correct about the street address in my example (1450 Glenarm Pl) actually being from Denver, but I also tested with just the zip code as well as actual Glenwood Springs addresses too and got the same, correct 8.6% rate. When the store location is in Denver and that real Denver address is used, the correct 8.31% rate is calculated:

https://cld.wthms.co/sZtxc2

To answer your question about how Services determines tax rates, here are some examples:

Colorado has “Home Rule” jurisdictions. That means that merchants (store owners) will only need to pay city tax if the destination address is also in their same home rule jurisdiction. So, for example:

• A merchant has an economic Nexus in Louisville, CO. He gets an order from Denver, CO. Denver and Louisville are in different Home Rule jurisdictions, so that order doesn’t have city tax.
• A merchant has an economic Nexus in Louisville, CO. He gets an order from Louisville, CO. That order does have city tax, and that tax will be collected directly by the city, not the state.
• A merchant has an economic nexus in San Francisco, CA. He gets an order from Louisville, CO. That order doesn’t have city tax (or any kind of tax, really).
• A merchant has an economic nexus in San Francisco, CA. He also has a lot of clients from Colorado, so he has also an economic nexus in Colorado as a whole. He gets an order from Louisville, CO. That order doesn’t have city tax.

So, the TaxJar rate calculator can’t account for some of these cases, because it doesn’t allow to specify both the origin and destination addresses. However, the API (and the Services plugin) should be returning the actual, correct rates.

Hopefully this helps clarify how it works, but from all the different tests that I’ve done after (very recently) hearing that the fix was released, the rates do seem to be correct based on the various shop base locations and destination addresses for all the cities I’ve checked.

@shaunkuschel
Unfortunately, that is not how tax collection works in Colorado any longer.

Per the Colorado Department of Revenue (https://www.colorado.gov/pacific/tax/information-state-retailers)

Effective Dec. 1, 2018, the Colorado Department of Revenue will adopt new sales tax rules. The new rules state that sales tax must be collected and remitted based on the jurisdiction’s tax rate at the point of delivery for the taxable good when taxable goods are delivered to a Colorado address outside the retailer’s jurisdiction. This includes any applicable state-administered local and special district taxes. For example, if a retailer delivers taxable goods to a customer’s address, sales tax must now be collected at the rate effective for the customer’s address, not the taxes that are in common between the customer’s address and the seller’s location.

This is affecting our sales tax rates for the state of Texas too. I was going back and noticed we have several sales where we undercharged for sales tax and some very large sales. Please let us know when this bug is fixed.

Thanks for that info, @npuana.

@mreed3689 – I just got some info from TaxJar about Texas rates, which was a different issue but it has been resolved on their end. California rates may have also been affected by that bug too- but should also be working correctly now.

Any word on the Colorado end of this? Calculations based on the information you shared two weeks ago would not be accurate (see the post right below yours) since the tax collection laws have changed in Colorado.

I’m in Colorado and I can tell you there are still issues with the rates. 81201 is 8.65% but in my store it calculates 7.65. I 100% do not have time to go through every tax rate in the state and fix it. This needs to be corrected NOW as it’s costing all of us money!

@shaunkuschel

Do we have any updates? Or is a new thread required to get the proper attention to this matter?

@npuana & @bignuggetfarm – Is the updated information in this post from TaxJar correct for Colorado, based on your understanding of the somewhat recent tax changes?

https://blog.taxjar.com/colorado-changing-way-tax-collected-online-sellers/

If this is not correct, can you clarify what part of that updated post is incorrect?

If the info in the post is correct, but the rates you are seeing on your site are wrong, can you provide more info to us regarding that? It would be best to do that in a new thread. Since this thread was resolved a while back, and I haven’t been around recently, it hasn’t been getting the attention it needs from the teams that are currently supporting these forums. I apologize for the delay in getting back to you regarding this issue. ??