Reconciliation
Why WooCommerce tax reports differ: refunds, shipping, and discounts
Before treating a tax-report difference as a calculation error, check what each number includes. A refund date, an included shipping-tax amount, or a discount deducted twice can explain why two apparently similar totals disagree.
The short answer
Compare the same period, timezone, currency, and statuses first. Then check refund dates and tax allocations, whether shipping tax is already included, and whether discounts are informational. In TaxPack, use the orders/refunds export to locate a difference and the tax-line export to inspect its detail.
1. The refund belongs to a later period
Suppose an order was created on September 28 and its refund was created on October 3. TaxPack places the order in a September report and the refund in an October report. It does not move the refund back to the order’s month.
WooCommerce documents refund-date reporting in its Analytics reports as well. However, your comparison may be an order export, a legacy report, or a payment statement with another date basis. Check the actual source rather than assuming every system assigns the transaction to the same period.
| Event | Created | Recorded tax | TaxPack period |
|---|---|---|---|
| Original order | September 28 | 65.00 | September |
| Partial refund | October 3 | −13.00 | October |
The two events net to 52.00 across both months. That does not make 52.00 the original order tax for September.
2. Shipping tax was added a second time
In TaxPack, total tax for a stored tax line includes its non-shipping tax and shipping tax. The summary also shows shipping tax as an included component so the accountant can inspect it.
If a line contains 12.00 of non-shipping tax and 1.20 of shipping tax, its total is 13.20. Adding the 1.20 shipping component to 13.20 again would produce an incorrect 14.40. Check what the column means before summing a spreadsheet.
3. A discount’s tax effect was deducted twice
TaxPack reads the final stored tax amounts and displays discount information once per source event. It does not subtract the informational discount-tax value from those stored amounts again.
For example, an order may show 9.00 of recorded tax and 1.00 of informational discount tax. If the stored 9.00 already reflects that discount, subtracting another 1.00 produces 8.00 and understates the recorded amount. The export labels these fields discount_net_informational and discount_tax_informational.
4. A monetary refund has no tax allocation
A refund amount alone does not identify the tax refunded. If WooCommerce stores a monetary refund without tax lines, TaxPack flags refund_without_tax_allocation. It does not guess a rate or split the refund into tax categories.
That event remains in the orders/refunds file even though it cannot supply a tax-line breakdown. This is why the summary and tax-line CSVs alone are not a complete exception review. A positive tax value on a refund is also flagged; TaxPack preserves its recorded sign instead of silently changing it.
A repeatable investigation order
- Confirm matching dates, store timezone, statuses, currency, and province address source.
- Find the affected event in the orders/refunds CSV and compare recorded_order_tax, tax_line_total, and difference.
- Use its event ID and order ID to find the tax lines and open the source order.
- Inspect refund allocation, shipping, item/fee detail, and any review codes.
- If the source is corrected through your normal store process, generate a new report and keep the explanation with it.
TaxPack flags even small differences and keeps flagged amounts in the report. It does not change orders, repair tax allocations, or decide the correct filing treatment. Saved reports remain snapshots of the values read during generation.
Official references
These guides explain reporting workflows. TaxPack does not provide tax advice, calculate tax payable, or file returns.