How to Export WooCommerce Orders to CSV or Excel

WooCommerce has no order exporter — it has a downloadable Analytics report, which is fine for accounting totals and useless for moving orders anywhere. The Products screen has an Export button; the Orders screen does not. Which route you need depends on whether the file is for reading or for importing somewhere else.

Route 1: the Analytics report download

Analytics › Orders, set the date range, then Download. You get a CSV with one row per order:

What is missing matters more: no billing or shipping address, no email, no phone, no tax or shipping breakdown, no line-item prices. For a monthly sales summary or a quick check of which coupons were used, that is enough. For a fulfilment partner, an accountant who needs VAT per order, or a migration, it is not.

Two things make the report disagree with the Orders screen:

1. Excluded statuses. Analytics leaves out pending, cancelled and failed orders by default (Analytics › Settings › Excluded statuses). An export that "misses" orders is usually filtering them by design.
2. Lookup tables. Analytics reads wc_order_stats, not the orders themselves. Orders that arrived before the tables were populated — after a migration or a plugin import — appear only once the historical data import has run, and when that stalls the cause is covered in historical data import not working.

Large reports are not built in the browser: WooCommerce generates them in batches and emails a download link to the user who asked, so check the inbox — and spam folder — of the account you were logged in as.

Route 2: the database, for developers

With High-Performance Order Storage on — the default for new stores — orders live in wc_orders, with addresses in wc_order_addresses, payment and cart details in wc_order_operational_data and custom fields in wc_orders_meta. Line items are still in woocommerce_order_items and woocommerce_order_itemmeta. Stores on legacy storage keep orders as shop_order posts with meta in postmeta.

A SQL export of those tables is complete, but it is a dump, not an export: IDs, foreign keys and the storage mode all have to match on the receiving side. Inside a script, use the order API rather than raw tables — wc_get_orders() reads whichever storage the store uses:

$orders = wc_get_orders( array(
	'limit'        => 200,
	'date_created' => '2026-10-01...2026-10-31',
	'status'       => array( 'wc-processing', 'wc-completed' ),
) );

foreach ( $orders as $order ) {
	// $order->get_billing_email(), $order->get_items(), $order->get_total() …
}

Batch it. Loading every order of a large store in one request is the classic way to hit the memory limit, and a cron-run script that does it every night will eventually fail at the worst time.

Where the built-in tools stop

Neither route gives a shop owner a file that has addresses and line items and that another WooCommerce store can read back in. That needs a dedicated importer/exporter. The selection criteria:

• Column choice and line items. One row per order with items in a cell, or one row per line item — accountants and warehouses want different shapes.
• Filters by date, status, product and customer, so an export is a query, not the whole history.
• Import, not just export, with a choice of keeping or remapping order IDs.
• Formats beyond CSV if the receiving system wants XML or Excel.
• Scheduling and delivery — a nightly file to an FTP folder for a fulfilment partner is a common requirement nobody wants to run by hand.

WebToffee's Import Export Suite is one tool built for this: it covers orders, products, customers, coupons, subscriptions and reviews, reads and writes CSV, XML, TSV and Excel, and runs scheduled jobs from WordPress or server cron with files fetched from a URL or FTP/SFTP.

Moving orders to a new store

Order history is the part of a migration people want to keep and the part most likely to break:

• Order IDs collide. The new store has its own sequence; importing order 1045 where an order 1045 exists either overwrites it or gets a new ID. Decide which before importing, because customers' emails reference the old numbers.
• Customers must exist first. An order linked to customer ID 12 can attach to whoever is user 12 on the new site. Import customers before orders, matched on email — see exporting WordPress users.
• Products are usually matched by SKU, so products without SKUs can import as name-only line items with no link to the catalogue. Bring products across first, as in exporting WooCommerce products.
• Guest orders have no account to link to; that is expected, not a failure.

Personal data

An order export is a file full of names, addresses, emails and phone numbers. Treat it like a backup: do not email it around, delete working copies, and include it in the data inventory described in WordPress GDPR compliance.

Common mistakes

• Using the Analytics download for a migration. It cannot be imported.
• Reporting from it without checking excluded statuses, then wondering why totals differ from the payment gateway.
• Exporting with HPOS sync off and reading postmeta, which holds stale or no order data.
• Importing orders before customers and products, which links orders to the wrong people and to nothing in the catalogue.
• Double-clicking the CSV into Excel, which reformats order numbers and postcodes.

Verify

Export a week of orders, pick three — one guest, one with a coupon, one refunded — and compare every column against the order screen. If you are migrating, import into a staging site, not the live one, and check that the same three orders keep their totals, customer and line items.