WooCommerce 11.0 exposes failed historical import jobs and a retry path, while v3 sales reporting adds refund values by date bucket. A retry can finish successfully yet leave a partial refund duplicated, omitted, assigned to the wrong day, or disconnected from the order total used by finance and advertising reports.
Use this for WooCommerce store owners, finance, analytics, developers, and agencies reconciling historical imports, partial refunds, and net sales reports.
Quick answer
Create synthetic orders with full, partial, repeated, and cross-midnight refunds. Record order creation, payment, refund event, timezone, report bucket, retry job, source row identity, gross sales, refund value, expected net, actual net, and duplicate keys. Compare WooCommerce admin, v3 report output, order records, exports, and downstream BI. A retry passes only when each refund appears once in the documented bucket and every period reconciles to order-level net sales.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Same-day partial | $40 of $100 refunded | Refund once in documented day |
| Cross-midnight | Payment and refund on different local dates | Policy selects one clear bucket |
| Retry replay | Same failed job retried | No duplicate refund row |
| Full refund | Entire order value | Net and counts reconcile |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze order, refund, job, timezone, bucket, and expected-net evidence. | Record WooCommerce version, store timezone, report timezone, import state, failed jobs, retry endpoints, order storage, and analytics owners. | Failed jobs become completed or owned failures without orphaned work. |
| Identify partial commits and duplicate keys before retrying again. | Create paid orders with same-day, next-day, cross-month, full, partial, repeated, and failed-refund fixtures. | Partial and full refunds appear once in the intended v3 date bucket. |
| Repair the narrow import or reporting boundary that misplaces or duplicates the refund. | Capture stable order and refund IDs, UTC and local timestamps, source rows, retry job IDs, date buckets, gross, refund, tax, shipping, and expected net. | Order-level and period-level gross, refund, and net values reconcile. |
| Replay one controlled job and reconcile order, bucket, export, and BI totals. | Run the failed-import retry once, poll its state, and compare row identities before and after completion. | Exports, BI, finance, and ad adjustments use the same stable refund identity. |
What to check first
- Record WooCommerce version, store timezone, report timezone, import state, failed jobs, retry endpoints, order storage, and analytics owners.
- Create paid orders with same-day, next-day, cross-month, full, partial, repeated, and failed-refund fixtures.
- Capture stable order and refund IDs, UTC and local timestamps, source rows, retry job IDs, date buckets, gross, refund, tax, shipping, and expected net.
- Run the failed-import retry once, poll its state, and compare row identities before and after completion.
- Reconcile admin reports, v3 API buckets, order records, exports, BI, and any ad-value adjustment process.
Field notes
- Preserve immutable order and refund IDs through every report layer.
- Write the timezone and bucket policy in the reconciliation report.
- Use synthetic orders that cannot affect fulfillment or real revenue.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
order,refund,paid_utc,refund_utc,store_day,retry_job,gross,refund_value,expected_net,actual_net,result
WC-91,R-1,13:55Z,14:20Z,2026-08-19,J-44,100,40,60,60,pass
WC-92,R-2,04:55Z,05:05Z,2026-08-19,J-45,80,20,60,80,fail
WC-93,R-3,16:00Z,17:00Z,2026-08-19,J-46,120,120,0,0,pass
Why this usually happens
- Order, payment, refund, import, and report clocks can use different timezones.
- A retry may replay work whose first attempt partly committed.
- Order-level net can look right while daily buckets are shifted.
- v1, v2, and v3 consumers may not expose refund values the same way.
Decision rule
Close the retry only when every synthetic refund appears exactly once, the documented date bucket is correct, order and period net totals reconcile, and downstream reports retain the stable identities.
Production verification checklist
- Failed jobs become completed or owned failures without orphaned work.
- Partial and full refunds appear once in the intended v3 date bucket.
- Order-level and period-level gross, refund, and net values reconcile.
- Exports, BI, finance, and ad adjustments use the same stable refund identity.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze order, refund, job, timezone, bucket, and expected-net evidence.
- Identify partial commits and duplicate keys before retrying again.
- Repair the narrow import or reporting boundary that misplaces or duplicates the refund.
- Replay one controlled job and reconcile order, bucket, export, and BI totals.
- Monitor the next real refund cohort with finance ownership.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful browser screen as proof that queues, caches, providers, reports, roles, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, consent states, networks, and failure paths real users have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache-policy changes, and schema work on staging first. Promote only the smallest measured change with a current rollback point.
What evidence should the report keep?
Keep exact component versions, UTC timestamps, stable synthetic IDs, expected and actual results, queue or provider identifiers, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, message content, addresses, and private infrastructure details before sharing evidence.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context. Record any observation window that remains instead of calling a quiet test a permanent fix.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, root cause or current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window is still open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, reconcile WooCommerce analytics and refunds.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references