What matters first: WooCommerce chooses rates from billing/shipping/base location settings and applies them to prices that may include or exclude tax. Shipping classes and compound rates add further branches.
Where WooCommerce tax totals start to diverge
A screenshot of the total is not enough. Line net, tax class, matched rate and rounding method are needed.
Rebuild one cart from price to tax total
- Export one affected order or cart with addresses, line prices and tax totals.
- Confirm whether catalogue prices are entered inclusive or exclusive of tax.
- Identify the matched tax rate and priority for the customer location.
- Check rounding mode, shipping tax class, exemptions and currency conversion.
Check location, price mode and rate priority
- Location mismatch: Geolocation, billing or shipping address selects the wrong jurisdiction.
- Price mode mismatch: Imported prices are treated as inclusive when they are net, or vice versa.
- Overlapping rates: Multiple rates or priorities apply unexpectedly.
- Rounding/integration: Per-line rounding or ERP/currency conversion changes totals.
Correct the calculation before touching history
- Reproduce the calculation with one simple taxable product.
- Correct location and tax-rate rules before editing historical orders.
- Align imports and external systems on net/gross price semantics.
- Test mixed tax classes, coupons, shipping and refunds.
Wrong jurisdiction or wrong net/gross assumption?
Recalculate one line manually from catalogue price to taxable base and matched rate. If WooCommerce chooses the wrong jurisdiction, fix location and rate matching; if the jurisdiction is right but the base is wrong, inspect inclusive/exclusive price semantics and imports. Rounding is a third branch, not the first guess.
If the tax discrepancy appears only after the payment transition, compare the order with paid transactions whose WooCommerce order remains failed and duplicate payment retries before editing tax tables. A payment/order-state mismatch can make the accounting symptom look like a tax-engine fault.
Keep completed orders out of the first repair step
Do not rewrite completed-order tax totals without an accounting and audit plan.
Reconcile storefront, gateway and accounting
- Representative carts match the approved manual calculation.
- Invoice, order, gateway and accounting values agree.
- Refunds reverse the same tax basis correctly.
Close the incident only after representative carts match an approved manual tax calculation and the storefront, order, gateway, invoice and refund all preserve the same taxable basis.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
A screenshot of the total is not enough. Line net, tax class, matched rate and rounding method are needed.
Export one affected order or cart with addresses, line prices and tax totals.
Confirm whether catalogue prices are entered inclusive or exclusive of tax.
Identify the matched tax rate and priority for the customer location.
Check rounding mode, shipping tax class, exemptions and currency conversion.
What must be verified
- Representative carts match the approved manual calculation.
- Invoice, order, gateway and accounting values agree.
- Refunds reverse the same tax basis correctly.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is a screenshot of the wrong total enough to diagnose a tax problem?+
No. You need the line net price, the tax class, the matched rate and priority, and the rounding method for that specific order or cart, since the same wrong total can result from several different combinations of these factors.
Can imported product prices cause tax errors even if the tax rates are set up correctly?+
Yes. If imported prices are net amounts but WooCommerce treats them as tax-inclusive (or the reverse), the calculated tax will be wrong even though the tax rate table itself is accurate.
Does the customer's shipping address always determine which tax rate applies?+
Not necessarily. WooCommerce can select rates based on billing, shipping, or store base location depending on configuration, and geolocation settings can also override the address the customer entered, so the wrong jurisdiction can be selected in more than one way.
Should completed orders be edited directly to fix historical tax totals?+
Not without an accounting and audit plan. Rewriting tax totals on completed orders affects financial records and refund calculations, so the underlying rate or price-mode issue should be fixed going forward before touching historical data.