WooCommerce Analytics Missing Orders or Showing Outdated Sales?

In this guide

When WooCommerce Analytics misses an order or shows outdated sales, compare a known source order with the report’s date range, date basis, filters, and excluded statuses before rebuilding analytics data. A reporting mismatch does not mean the original order disappeared or that a payment failed.

Choose one report and one metric. “Sales is wrong” is too broad to investigate reliably: gross sales, net sales, shipping, tax, returns, and payment-provider payouts describe different values. Establish what the report should contain before deciding it is inaccurate.

Start with a known order and a written expectation

Open an order that should appear and note its ID, creation time, paid-date field where present, status, item totals, discounts, shipping, taxes, and any refund records. Do not edit these fields to make the report match. First preserve what the source actually says.

Then record the report name, selected date range, comparison range, filters, and displayed metric. Use the same timezone and date boundaries when comparing examples around midnight. A refund recorded after the original sale can also make two periods look different.

The official Orders Report guide describes the report’s filtering and order data. Use an individual order row to test your expectation before comparing a large dashboard total.

Check settings before importing again

In Analytics settings, inspect status exclusions, date type, and update behavior for the installed version. Compare them with the selected order and the business question. A report based on payment dates can reasonably differ from a list filtered by creation dates.

The Analytics and Sales Reports documentation explains metric definitions, reporting settings, historical imports, failed-order import controls, and the analytics cache. Those reporting controls should be reviewed before a reset.

Follow this decision sequence:

1. The order exists but fails the report’s current filters: correct the comparison or choose the intended reporting rule.
2. The order qualifies but is absent: inspect import progress, failed-import warnings, and update jobs.
3. The order row is present but the summary is stale: investigate reporting cache and refresh behavior.
4. The source order itself is missing or inconsistent: investigate the order workflow before treating this as analytics-only.

If a paid order’s source status is incorrect, use the pending-order payment review. Re-importing analytics cannot repair the gateway relationship or prove receipt of money.

Inspect background work instead of repeatedly restarting it

Record any current import’s date range, progress, and start time. If the screen shows failed orders, open the corresponding log and identify the first meaningful error. Repeated retries without correcting that error can consume resources without recovering the missing data.

The Action Scheduler administration guide documents how to inspect statuses and per-action logs. A developer can use that evidence to distinguish a specific import failure from a wider scheduling problem.

The owner can collect report settings and redacted log messages. A developer or host should investigate failed database operations, unavailable callbacks, timeouts, or blocked background requests. Do not bulk-run unrelated scheduled actions: the same queue can contain payments, emails, and other business work.

For a store-wide backlog, use the scheduled-action performance guide to structure the infrastructure investigation. Fixing the queue is a separate task from deciding which analytics orders need importing.

Choose the least disruptive reporting repair

If settings explain the difference, document the chosen reporting basis and stop there. If stale cache is confirmed, use the supported analytics-cache tool and compare the same report again. If orders were not imported, plan a scoped historical import using the installed version’s controls.

Take a backup and record the current reporting state before a larger rebuild. For a busy store, agree a suitable window and monitor resource use. Smaller, documented ranges can make progress and failure points easier to assess than repeated all-history imports.

Deleting imported analytics data is not the same as deleting source orders, but it can temporarily remove reports that staff depend on. Do not reset simply to see whether it helps. Capture the reason, planned range, expected comparison, and recovery owner first.

Reconcile the result without confusing reports with settlement

Verify the originally missing order, another order in the same period, and one excluded example that should remain excluded. Compare the defined metric with a source-order sample using the same date basis. Check a period containing refunds if those contributed to the discrepancy.

A clean import completion message is useful, but the acceptance criterion is correct reporting for the agreed records and rules. Monitor the next naturally created orders to establish that ongoing updates work, not only that a historical rebuild finished.

Keep native analytics separate from payment settlement. Provider payouts include their own timing, adjustments, and records. The refund-record versus returned-money guide explains a related distinction: a website record is not itself confirmation of a funds movement.

Finish with the settings used, affected periods, import outcome, and any unresolved source-order exceptions. That makes the next reporting comparison reproducible and prevents another reset based on different filters.

FAQs

Should I re-import all history when one order is missing?

Start with the order’s eligibility, reporting dates, and import error. A scoped repair is easier to verify and avoids unnecessary processing.

Does clearing analytics cache change payments?

No. It refreshes reporting data; it does not collect a payment, return funds, or repair provider records.

Why do Analytics totals differ from my processor payout?

They measure different records and timeframes. Reconcile orders and provider transactions separately, then account for the provider’s payout entries and adjustments.

Prepared for website owners by Nithu / Suthakaran Nithursan. Dated advisory facts link to primary sources. Examples are illustrative and are not client results or guarantees.