Why depend on Jetpack ?

Hi Jairo – thanks for taking the time to share the details.

A quick clarification on the Jetpack part: WooCommerce Tax (this plugin, formerly WooCommerce Services / WooCommerce Shipping & Tax) needs a WordPress.com connection to securely access our hosted tax calculation service (and to help prevent API abuse). Jetpack used to be the common way to create that connection, but Jetpack itself is no longer required. If Jetpack is already connected on the site, the plugin can reuse that connection. If not, the plugin can connect to WordPress.com on its own during setup.

About the taxes ‘disappearing’ from the Taxes table: if ‘Enable automated taxes’ is turned on, automated taxes take over from the manual tax rate tables in WooCommerce. That can look like tax rates were removed, because the store is no longer relying on the rates you manually configured there. WooCommerce also creates a backup of your previous tax rates in your site’s wp-content/uploads folder when you switch to automated taxes, so nothing is lost.

Cases like Spain + Canary Islands can be a bit nuanced (VAT vs special territories). If you’re willing to share a couple of your Tax settings, I can help you sanity-check the setup and explain what WooCommerce is using to decide the rate.

In WooCommerce > Settings > Tax, what is this set to?

• Calculate tax based on (shipping address, billing address, or shop base address)

Also:

• What’s the store postal code?

With those details we can check this better and find a solution.

Thanks!

Thanks for the extra details @jairoochoa!

On the CSV restore, WooCommerce’s tax CSV import does not preserve tax_rate_id. The CSV format doesn’t include that field, so the importer always creates new rows and MySQL assigns new IDs in the order the rows are read. That’s why the rates come back but the IDs change.

So moving further I can think of two ways to fix this:

Option A:

1. Export your current tax rates (the same CSV you restored).
2. In your plugin, replace any lookup that uses tax_rate_id with a lookup based on stable fields:
   • country/state/postcode/city
   • rate, name, class
   • priority/compound/shipping
3. If the plugin stores links per order item, rebuild those links by matching existing stored values to the current rates using those fields.
4. Test with a couple of new orders to confirm the link uses stable fields rather than the ID.
   If the plugin doesn’t support this today, the plugin author will need to update it to avoid relying on tax_rate_id.

Option B:

1. Restore the tax tables from a full database backup taken before the CSV import.
   
   Tables involved: wp_woocommerce_tax_rates and the related location tables (e.g., wp_woocommerce_tax_rate_locations).
2. After restoring, re‑check the tax IDs and confirm the plugin links resolve again.

If you get stuck on either path, share what you’re seeing and I’ll help you work through it.

Regarding this part:

I am able to configure taxes (IVA/VAT) for any country, including EU member states, non-EU countries, and Spanish territories. However, I don’t feel confident proceeding if I cannot review the tax tables directly.

Totally understand wanting to see the tax tables directly.

If Enable automated taxes is on, WooCommerce ignores the manual tax rate tables and can hide/empty them in the UI, because the rates are being pulled from the automated tax service instead, and unfortunately they’re only pulled after a user inserts their address in the checkout form. This is designed to work like this to avoid bloating the database.

Anyways, please let us know if you experience any issues following one of the options above.