An empty WooCommerce Analytics Orders report after testing 11.3 can come from a custom SQL query that refers to payment_method without identifying its table. Check the error log before restarting imports. A failing query and an unfinished background update need different fixes.
Release status, October 27, 2026: WooCommerce 11.3 is a beta. Use a protected staging copy for this procedure. This is preparation for an upcoming change, not a claim that every live store has this defect.
Identify the failing request first
Open Analytics, then Orders, and reproduce the failure with a narrow date range that contains known test orders. Record the selected filters and whether the table, chart, summary, or all three fail. In the browser Network panel, inspect the report request and its response. Keep authorization headers and customer details out of tickets.
Ask the developer to check the matching server log timestamp. The important distinction is between a request that fails with an ambiguous-column error and a successful report that has incomplete payment-method values. A blank screen by itself does not establish either cause.
The 11.3 developer advisory explains that Analytics adds payment_method to wc_order_stats. An extension joining the orders table can therefore expose a previously unambiguous bare column reference.
Find the extension that owns the SQL
Search the site's custom plugin and theme code for payment_method and woocommerce_analytics_clauses_. Inspect the generated query, including aliases, rather than changing every matching string. The same field name can also occur in harmless JSON, order APIs, or display labels.
For example, imagine a custom query already defines an orders-table alias named orders. A condition such as payment_method = 'stripe' needs the appropriate qualified reference, such as orders.payment_method. That example is only correct when the query actually defines that alias and intends the order-table value. Do not paste an alias into unrelated SQL.
Have the maintainer make the change in the extension's source, not in WooCommerce core. Review WHERE, SELECT, ORDER BY and GROUP BY expressions that the extension adds. One qualified SELECT does not repair an unqualified condition elsewhere in the same query.
Diagnostic branches: a failed SQL query needs a qualified column; missing historical gateway values need a backfill check. Synthetic troubleshooting diagram.
Do not mistake backfill for a query defect
Existing Analytics rows need their new gateway values populated. In staging, inspect the relevant background update and its failures using the site's supported Scheduled Actions interface. Record whether work is pending, running, completed or failed. Do not manually rewrite the Analytics table to make a filter appear populated.
Compare one recent order with one older order whose gateway is known. If the report works but only older rows lack the value, investigate migration progress before changing SQL. If the server explicitly rejects ambiguous SQL, waiting for backfill alone will not fix it.
For a genuine historical import failure, continue with the Analytics import recovery guide. Avoid running an unrelated product lookup-table rebuild for an order-report column problem.
Use a small acceptance worksheet
Create a staging fixture containing two known gateways and an order with no gateway. Use artificial customer data and do not initiate live payments for this test. Write down the expected order IDs before changing the extension.
| Test |
Evidence to retain |
Acceptance condition |
| No payment filter |
Returned IDs and error log |
Report loads without SQL ambiguity |
| One gateway selected |
Table, chart and summary |
All views describe the same filtered population |
| Different gateway |
Same date and status settings |
First gateway's orders no longer appear |
| CSV download |
Raw exported rows |
Export matches the selected report scope |
| Historical order |
Order gateway and migration state |
Stored reporting value reconciles after backfill |
The payment-method filter implementation is a useful reference for how list and statistics filters are paired. Do not compare a filtered table to an unfiltered chart and call the difference lost revenue.
Roll out a narrow repair
Keep a copy of the previous extension package and the query change. Test with the actual database engine and Analytics extensions used by the store. Do not assume a small staging dataset measures production migration time; it only checks behavior.
After the final supported release is installed, repeat the worksheet before relying on the new breakdown for business reporting. Record the WooCommerce version, extension version, affected callback and result. If the error persists without that extension, preserve the minimal reproduction for its maintainer rather than repeatedly rebuilding reports.
For help tracing the callback and validating the report, request a one-time WooCommerce fix. Supply redacted errors and expected order IDs, never a full customer export in a public support thread.
Sources checked October 27, 2026. Procedures and synthetic diagrams are explanatory, not claims of customer testing.
If the report loads successfully but old gateway values are incomplete, use the dedicated backfill checks: WooCommerce 11.3 Payment Methods Missing on Old Orders? Check Backfill.