WooCommerce Tax Not Calculating? Fix Missing or Wrong Rates

A customer gets to checkout, the cart total looks right, but the tax line is either missing entirely or showing an amount that makes no sense. No error, no warning in the WooCommerce logs - just a checkout page quietly charging the wrong amount, or none at all. This is one of those bugs that's easy to miss during testing because store owners usually check out from their own address, where the rate happens to work.

Symptom

A few variations of the same underlying problem, all reported the same way:

• The cart and checkout pages show no tax line at all, even though "Enable tax rates and calculations" is turned on.
• Tax shows for some customers but not others, depending on their billing or shipping state.
• GST is calculated correctly on the cart page but comes out different (or zero) at checkout.
• The rate changes after you edit it in WooCommerce > Settings > Tax, but customers keep seeing the old number for hours.

All four trace back to one of five places: the tax setting itself, an incomplete rate table, the "calculate tax based on" logic, a caching layer, or a mismatched product tax class. Work through them in this order - it's the order we see them in support tickets, roughly by frequency.

Cause 1: Tax calculation isn't actually enabled

Sounds obvious, but it's the single most common cause. WooCommerce ships with tax calculation off by default, and it's easy for this setting to get reset after a plugin update or a config import from a staging site.

1. Go to WooCommerce > Settings > General.
2. Confirm Enable tax rates and calculations is checked.
3. Save, then reload the cart page in a fresh incognito window - not just a normal refresh, since the cart is cached client-side too.

If this checkbox was off, that alone explains a completely missing tax line, and nothing else on this page needs touching.

Cause 2: The tax rate table has gaps

Once tax is enabled, WooCommerce goes looking for a matching row in WooCommerce > Settings > Tax > Standard rates (or whichever tax class the product uses). If it doesn't find a row matching the customer's country/state, it applies no tax - it doesn't guess, and it doesn't fall back to a default rate.

For Indian stores charging GST, the usual mistake is only adding one flat rate row and expecting it to cover both intra-state and inter-state sales. GST doesn't work that way - it's really two different rates layered together:

If you're not using a dedicated GST plugin (Webgility, WooCommerce GST plugins, or a custom tax class setup), you need at least these two rows per rate bracket, or interstate customers will checkout with zero tax while local customers get charged correctly - which is exactly the "works for some, not others" symptom above.

Quick sanity check: open WooCommerce > Settings > Tax > Standard rates and count the rows. If you sell across multiple states and see only one row with a state field filled in, that's your gap.

Cause 3: "Calculate tax based on" is pointed at the wrong address

Under WooCommerce > Settings > Tax, the Calculate tax based on dropdown decides whose address WooCommerce uses to pick a rate: customer shipping address, customer billing address, or shop base address. If this is set to "Shop base address," every single order gets taxed as if it shipped from your own state - which is wrong for interstate GST, and wrong for most non-Indian stores too.

There's a second setting worth checking right next to it: Default customer location. If it's set to "Geolocate," WooCommerce needs the MaxMind GeoIP database to guess a visitor's state before they've entered an address - and on a fresh install, that database often isn't downloaded yet.

• Go to WooCommerce > Settings > General > Default customer location.
• If it's set to "Geolocate" or "Geolocate (with page caching support)," go to WooCommerce > Settings > Integration > MaxMind Geolocation and confirm a license key is entered and the database has downloaded (check wp-content/uploads/woocommerce-uploads/geoip.mmdb exists via File Manager or SSH).
• If you don't want to deal with a GeoIP database, switch Default customer location to "Shop base address" - tax then shows a reasonable default on the cart page and corrects itself once the customer enters a real address at checkout.

Cause 4: Caching is serving a stale cart or checkout page

This is the one that catches store owners off guard, because it looks like the tax logic itself is broken when it's actually a page-cache problem. Cart and checkout are supposed to be dynamic pages - never cached - because their content depends on who's browsing and what's in their cart.

If you're on LiteSpeed Cache, WP Super Cache, W3 Total Cache, or a full-page cache at the server level, and the cart/checkout URLs aren't excluded, visitors can get served a cached snapshot from a different session - stale totals, stale tax, sometimes someone else's cart contents.

To fix it in LiteSpeed Cache (the default on most Getwebup WordPress hosting):

1. Go to LiteSpeed Cache > Cache > Excludes.
2. Under "Do Not Cache URIs," confirm /cart/* and /checkout/* are listed. WooCommerce usually adds these automatically when it detects LiteSpeed, but a manual cache rule or a page builder can override that.
3. Purge the full cache after saving: LiteSpeed Cache > Toolbox > Purge All.

If you changed a tax rate and customers still see the old number after several minutes, this is almost always why - a stale cached checkout fragment, not a WooCommerce bug. Also check any CDN (Cloudflare, etc.) isn't caching these paths at the edge; a page rule that bypasses cache for /cart and /checkout fixes it there.

Cause 5: The product's tax class doesn't have a matching rate

Tax rates in WooCommerce are attached to a tax class - Standard, Reduced rate, Zero rate, or any custom class you've added. Each product picks a class under its General tab. If a product is assigned to "Reduced rate" but you never added rows under WooCommerce > Settings > Tax > Reduced rate rates, that product will checkout with zero tax regardless of what's configured under Standard rates.

This shows up a lot after a CSV product import or a migration - the import sets a tax class value that doesn't exist as a configured tab in your store, and WooCommerce silently treats it as untaxed.

• Spot-check a few products under Products > All Products, open Quick Edit, and check the Tax class field.
• Cross-reference against the tabs actually present under WooCommerce > Settings > Tax.
• If you find a class with no rates configured, either add rate rows for it or bulk-edit the affected products back to Standard.

One more thing: inclusive vs exclusive pricing

If tax is calculating but the total looks "off" rather than missing, check WooCommerce > Settings > Tax > Prices entered with tax. If your product prices were entered tax-inclusive but this is set to "No, I will enter prices exclusive of tax," WooCommerce adds tax on top of a price that already had it baked in - and the displayed total jumps higher than customers expect. This isn't a bug either; it's a mismatch between how prices were entered and how the setting says they should be interpreted.

Prevention

• After any tax rate change, purge page cache and any CDN cache immediately - don't assume it'll "catch up" on its own.
• Keep cart and checkout on the do-not-cache list explicitly, rather than relying on a plugin to auto-detect WooCommerce.
• When adding a new tax class, add its rate rows in the same sitting - an empty tax class tab is easy to forget about.
• Test checkout from at least two different state addresses (not just your own) after any tax or shipping zone change.
• If you migrated or imported products, spot-check tax class assignments before going live, not after the first order comes in.

Quick diagnostic order