Province reporting
WooCommerce tax reports by Canadian province
Build a Canadian WooCommerce tax report by province and tax type. Review address attribution, unmapped rates, refunds, and order-level reconciliation.
TaxPack field notes / Canadian WooCommerce stores
Start with a complete reporting guide, or find a focused answer to a specific WooCommerce tax-record question. Every field note links back to the source record and explains what the report can—and cannot—tell you.
Province reporting
Build a Canadian WooCommerce tax report by province and tax type. Review address attribution, unmapped rates, refunds, and order-level reconciliation.
Accountant exports
Export WooCommerce tax reports to CSV using native Analytics or TaxPack. Learn which files, date settings, and reconciliation details to send your accountant.
GST / HST
Separate recorded GST and HST in WooCommerce, review refunds and dates, and export traceable totals for your accountant without recalculating historical taxes.
Reconciliation
Trace WooCommerce tax-report differences caused by refund dates, shipping tax, discounts, missing allocations, and report settings. Includes worked examples.
Québec / GST / QST
Prepare separate GST and QST totals from recorded WooCommerce tax lines. Review Québec attribution, refunds, rate mappings, and English/French worksheets.
PST reporting
Separate recorded PST from GST in WooCommerce, keep BC and Saskatchewan groups distinct, and review refunds and unmapped rates before exporting.
Manitoba RST
Build a Manitoba RST and GST breakdown from recorded WooCommerce taxes. Classify rate IDs, review missing allocations, and export a clear summary.
Native reports
Compare WooCommerce’s built-in Taxes report with Canadian province and tax-type reporting. Check date settings, refunds, exports, and source traceability.
Reconciliation
Trace a WooCommerce tax summary to stored tax lines and refund records. Work through date, mapping, shipping, currency, and missing-allocation differences.
A first report should answer one narrow question before you try to reconcile an entire year of store activity.
A one-day test isolates date, status, and address settings before a full month introduces many different records.
A plugin can be active while its report screen is hard to find among WooCommerce's many admin menus.
The built-in Taxes report may already answer a tax-code question, while a Canadian province review needs a different grouping.
A store-wide total is easier to trust when you can follow one source order through the summary and detailed files.
Some WooCommerce orders have no recorded tax lines, so a tax summary can be empty even though orders exist.
A multi-currency store can show similar province and tax-type rows that are not mathematically combinable.
TaxPack asks for one province attribution source because WooCommerce orders can carry both shipping and billing addresses.
The free edition regenerates data when you download, so preserving the original files matters if records later change.
A tidy summary can hide unresolved source questions unless you look at the review section before exporting totals.
Two WooCommerce rates can share a label while representing different historical configurations or tax types.
An old rate ID can remain on past orders after the live tax table changes, and it still matters to historical reports.
Duplicate tax labels make a summary ambiguous unless the underlying rate IDs are reviewed separately.
Renaming a current tax-rate row can change what an administrator sees without rewriting every historical order line.
UNMAPPED means a stored tax line references a rate ID without a verified reporting classification.
TaxPack rejects a download from a report screen whose mapping revision has changed since the screen was generated.
A WooCommerce tax class controls checkout configuration, while TaxPack's type is a reporting label for a stored rate ID.
A tax-rate CSV import may introduce new IDs even when the imported labels look familiar.
A rate name containing GST or HST is a clue, but the source order and rate ID should decide the reporting label.
A store can begin with the free plugin and later use the paid edition without reclassifying every existing rate ID.
WooCommerce can store different shipping and billing provinces on one order, so a report needs a stated attribution rule.
A digital or pickup order may have no shipping province even though it has a valid billing address.
A guest checkout can still contain order address fields, but the customer account cannot be used as a substitute for them.
Digital-only WooCommerce orders often lack shipping details, which changes what a shipping-based report can show.
A store selling internationally may have tax lines on orders whose selected address is outside Canada.
A conflict flag helps you find orders whose two stored province fields disagree.
A province code alone is ambiguous when an order's selected country is missing or not Canada.
WooCommerce stores province codes while an administrator may see a full province name in an address form.
Running both shipping-based and billing-based reports can show how sensitive a breakdown is to the chosen address.
UNRESOLVED keeps tax-bearing events visible when the selected address cannot support a Canadian province group.
A full refund is a separate recorded event whose tax should be read with its own date and sign.
A partial refund may reverse only selected item or shipping tax lines rather than the whole order's tax.
WooCommerce can record a refund amount without matching tax-line allocation when the operator enters only a value.
A manual refund entry in WooCommerce does not by itself prove that funds returned through a gateway.
A refund created this month can refer to an order created months earlier, so order and refund periods need separate treatment.
Month-end reconciliation can differ when the shopper purchase and its refund cross the reporting boundary.
A single order can have multiple refund events with different dates, items, and tax allocations.
Order status filters apply to current orders, while refunds are queried as their own dated events.
A refund can reverse shipping tax as well as product tax, but only when that allocation is stored on the refund.
A refund's recorded tax total and summed tax lines can disagree when its allocation is incomplete or unusual.
An inclusive catalog price can make the customer-facing amount look different from an exported tax-line amount.
WooCommerce can round at line or subtotal level, so visible prices and stored tax detail can differ slightly.
WooCommerce's shipping tax class setting affects checkout calculations before TaxPack reads the completed order.
A WooCommerce discount can change the tax stored on an order, but the discount itself is not a second tax adjustment.
An order fee can carry its own tax line, which may be easy to miss when reviewing only products.
WooCommerce can mark a tax rate as compound, which affects its checkout calculation order.
A zero-rate or exempt order may contribute no tax even while the sale itself appears in order records.
A mixed cart can produce several tax rate IDs on one order, not a single universal category.
A change to checkout tax settings affects new orders but should not cause TaxPack to reprice historical orders.
A rate-table import can add or replace rows that later appear under unfamiliar IDs in report detail.
The three free CSV downloads describe different levels of the same recorded WooCommerce events.
The tax-line CSV is the place to inspect stored rate IDs, labels, mapped types, and item-level tax components.
The order/refund file includes source events that may have no tax-line row, making it essential for exception review.
The summary export includes separate exception rows so unresolved source events are not hidden behind grouped totals.
An empty, unflagged selection still needs metadata showing which period and filters were run.
A province/type total is easier to verify when its contributing order and refund event IDs remain visible.
A CSV date range is ambiguous if the store timezone and event-date rule are lost during sharing.
Tax-rate labels and other exported text can contain accented characters that spreadsheets may misread if encoding is guessed.
A spreadsheet can display fewer decimal places than TaxPack exported, hiding small differences during reconciliation.
A stored label or identifier beginning with a formula character can be interpreted as a command by spreadsheet software.
Two tax reports can use different dates, statuses, refund handling, and grouping even when they read the same store.
WooCommerce stores an event tax total and tax-line detail that should be compared when reviewing exceptions.
A payout statement combines settlement timing, fees, and possibly currency conversion, while TaxPack reads order tax events.
An order near month-end and a later refund can make adjacent monthly reports look asymmetric.
Sales reports and tax reports measure different fields, so their grand totals should not be compared as if equivalent.
TaxPack shows shipping tax as an included component so reviewers can explain a net tax amount.
Discount fields can explain why a stored tax amount is lower than a full-price expectation.
A store with CAD and USD orders needs separate tax totals before any external conversion policy is considered.
An order-level tax amount without matching tax-line detail creates a traceability gap.
A reviewer needs filters, source IDs, and exceptions, not just a screenshot of a grand total.
Date pickers can cause off-by-one errors if a store owner assumes the Through date is excluded.
The store timezone, not a UTC email timestamp, determines the local date used by TaxPack.
A monthly review is easier to reproduce when every run records the same set of filters and source files.
Adjacent quarterly reports should cover every local day once without sharing a boundary day.
A payment can settle after an order is created, so a payout period need not match the order report period.
TaxPack filters orders by their current status when a report is generated, not by a historical status snapshot.
A refund should be found by its own creation date even when its parent order is outside the selected period.
Year-end reviews need special attention to events created around midnight and refunds of prior-year orders.
A very short period is useful when you need to isolate one confusing order or refund without thousands of other events.
TaxPack has a 5,000 order/refund event limit per report to avoid unsafe resource use on shared hosting.
WooCommerce stores orders in dedicated tables under HPOS, so a reporting plugin must use WooCommerce order APIs.
An older WooCommerce store may still use WordPress posts tables as its authoritative order storage.
A storage migration is a good moment to compare a few known order and refund events before relying on a full period.
A WooCommerce update can change admin presentation or data APIs, so a sampled report is a useful operational check.
A staging copy can contain old, synthetic, or partially synchronized orders that should not be mixed with production evidence.
A store owner may need to understand whether creating a tax summary uploads customer or order records.
TaxPack reporting is an admin task that requires the WooCommerce management capability.
A temporary plugin deactivation should not erase the store's reporting classifications.
Extensions can add order statuses, and TaxPack presents current statuses as selectable checkboxes.
A report is read-only, but edits to source orders, rates, or mappings can affect future generated exports.
An empty summary can result from a date or status filter, no tax lines, or a period with no matching events.
A deleted or replaced WooCommerce rate may no longer be in today's tax table even though old orders reference it.
An export can be refused when rate mappings changed after the displayed summary was generated.
A long-open WordPress admin tab can have an expired security nonce when you finally submit a form.
The TaxPack menu may be absent when the plugin or WooCommerce is inactive, or when the user lacks permission.
A host can run out of PHP time or memory before reaching the plugin's 5,000-event ceiling.
Some imported order data can contain tax values outside the precision TaxPack's exact arithmetic supports.
A surprising province may come from the selected address basis rather than a tax-rate mapping error.
A refund that seems absent may have a creation date outside the store-local range or no stored tax allocation.
A spreadsheet may guess the wrong delimiter or encoding and make a valid CSV look misaligned.