Tax in WooCommerce is a settings screen and a set of rate tables. The software will do whatever you configure faithfully, what it cannot do is tell you what you are obliged to charge, and that is the part that matters.
Find out your obligations first
Whether you must charge tax, at what rate, and to which customers depends on where you are registered, where your customer is, and what you sell. Digital goods and physical goods frequently follow different rules, and selling across borders can create obligations in the customer's country rather than yours.
This is an accountant question, not a plugin question. Configuring the software correctly against the wrong understanding produces a store that is confidently wrong.
The setting that changes everything
Under WooCommerce tax options, you choose whether prices you enter include or exclude tax.
Get this right at the start. Changing it later means every product price is now interpreted differently, and you are re-entering the catalogue.
Consumer stores usually enter prices including tax, because customers expect the displayed price to be what they pay. Business-to-business stores usually exclude it. Whichever you choose, make the display setting match; a price entered including tax and displayed excluding it produces a checkout total higher than the product page, which is the most reliable way to lose a sale at the last step.
Which address the rate is based on
You can calculate on the customer's billing address, their shipping address, or your shop's address.
Whichever your obligations require. The common error is leaving it on the shop base address while selling to other countries with destination-based rules. Every order is then taxed at your local rate in place of the customer's, and the shortfall is yours to make up.
Rate tables
Standard rates cover most products. Reduced and zero rate classes exist for categories that are taxed differently, books, food and children's items in many jurisdictions.
A rate row is a country, optionally a state or postcode range, a percentage, and a name that appears on the invoice. Order matters where rows overlap: more specific rows should sit above general ones.
Assign the class per product. A product left on standard rate when it should be reduced is undercharged or overcharged on every sale until someone notices.
Shipping is often taxable too
Whether tax applies to the shipping charge depends on jurisdiction, and WooCommerce has a separate setting for it.
Easy to overlook, and it produces a small error on every single order, which accumulates into a real number by year end.
Test with real scenarios
Place test orders to each region you sell to and check the tax line against what you expect.
Specifically: a domestic order, an order to another country you sell to, an order with a reduced-rate product, and an order with shipping. Those four exercise the parts that are commonly wrong.
Check the invoice too, not just the checkout total. Tax is usually required to be shown as a separate line with the rate named.
Automated rate services
Extensions exist that maintain rates for you, which is worth considering if you sell across many jurisdictions where rates change.
Two things to know. They add an API call to checkout, on the page you cannot cache, so a service outage becomes your checkout outage: check what happens when it cannot be reached. And they do not decide your registration obligations, only the rate once you have decided where you are liable.
Keep records
Whatever you configure, tax reporting needs order-level records showing what was charged and why.
WooCommerce stores this per order, which is another reason to archive old orders rather than delete them, retention requirements are usually years, and a database cleanup that removes order data can remove the records you are required to keep.
For the extensions worth adding once the basics are configured, Best Free WooCommerce Plugins for 2026 goes into a short list.
Selling across borders changes which tax applies and adds two decisions alongside it. There is more in How to Sell in Multiple Currencies and Countries.
Check what the store is actually calculating
Tax configuration is judged by the total a customer sees, and that is testable directly rather than by reading settings.
wp db query "SELECT tax_rate_country, tax_rate_state, tax_rate, tax_rate_name, tax_rate_priority
FROM wp_woocommerce_tax_rates ORDER BY tax_rate_order LIMIT 20;"
wp db query "SELECT option_name, option_value FROM wp_options
WHERE option_name LIKE 'woocommerce_%tax%' LIMIT 20;"
Read the priority column carefully. Two rates at the same priority for one location do not add together, they compete, and only one applies. Rates that should compound need different priorities.
Then place a test order to each of the regions you sell to and compare the total against what you expect. A rate table that reads correctly and produces the wrong total is usually a priority or a matching problem rather than a wrong percentage.
Prices including or excluding tax is one decision with wide effects
The setting that decides how prices are entered affects the catalogue, the basket, the invoice and any import you ever run.
Changing it later does not reprice the products. It reinterprets them, so a catalogue entered one way and switched to the other silently changes every price by the tax rate.
wp option get woocommerce_prices_include_tax wp db query "SELECT COUNT(*) FROM wp_postmeta WHERE meta_key='_price';"
Decide it before entering the first product, record the decision, and check it after any migration. An import from a store configured the other way produces a catalogue that is wrong by exactly one tax rate, which is large enough to matter and small enough to go unnoticed for weeks.
Keep what you will need at the end of the year
The store records what it charged. What an accountant needs is that broken down by rate and by period, and that is worth confirming is available before the year ends.
wp db query "SELECT DATE_FORMAT(p.post_date,'%Y-%m') AS ay, SUM(m.meta_value) AS vergi FROM wp_posts p JOIN wp_postmeta m ON m.post_id=p.ID WHERE p.post_type='shop_order' AND m.meta_key='_order_tax' GROUP BY ay ORDER BY ay DESC LIMIT 12;"
Run it once now. If the figures look plausible, the data is being recorded correctly and the year end is a report rather than a reconstruction.
If the tax column is empty on older orders, the configuration changed at some point and the earlier records do not carry it. That is much better to discover in a quiet month than in the week a return is due.