Getting data out of Shopify: exports, reporting and warehousing

Sooner or later someone asks a question Shopify's reports can't answer, and you need the data somewhere else. There are three routes out, and picking the right one saves a lot of manual work.

Route 1: CSV exports

Products, orders, customers and inventory export as CSV from the admin. Right for a one-off, for handing something to an accountant, or for a migration.

Limits worth knowing: exports are a snapshot, there's no scheduling, large exports arrive by email rather than immediately, and the column set is fixed. Orders in particular export as multiple rows per order — one per line item — which trips up anyone summing a column without deduplicating.

Route 2: Bulk operations

For anything programmatic and complete, bulk operations are the correct tool. Submit a GraphQL query for the whole catalogue or all orders, Shopify runs it asynchronously, you download JSONL.

You choose the fields, you get metafields, you can run it on a schedule, and it's exempt from the normal rate limit. This is what a nightly extract should use — not pagination.

Route 3: A data warehouse

Once the questions involve joining Shopify data with anything else — ad spend, cost of goods, returns, subscriptions, support tickets — you want the data in a warehouse rather than in spreadsheets.

Two ways there:

• A managed connector that syncs Shopify into your warehouse. Fastest route, and the right first answer.
• Your own extract, using bulk operations nightly plus webhooks for near-real-time changes. More control, more to maintain.

The nightly-bulk-plus-webhooks pattern is the same architecture as any reliable integration: webhooks for immediacy, a scheduled full pass for correctness.

The fields that make numbers disagree

The most common source of "the numbers don't match" between Shopify and anything else:

• Discounts. Use the final_ and discounted totals rather than raw line prices, or your totals exceed what was charged.
• Refunds. They're separate records, not adjustments to the order. Any revenue figure that ignores them is wrong.
• Shipping and tax are separate from the item subtotal. Decide which figure you mean before comparing.
• Cancelled and test orders. Filter them out deliberately.
• Currency. Presentment currency (what the customer saw) and shop currency (what you report in) are different fields. Mixing them silently is the classic multi-currency reporting bug — localisation.
• Timezone. Shopify timestamps are UTC. A "daily sales" report built without converting to your business timezone will disagree with the admin.

That last two produce more reconciliation meetings than anything else.

What Shopify's own reporting covers

Report depth varies by plan, and the built-in reports genuinely answer a lot: sales over time, by product, by channel, by traffic source, plus the checkout funnel.

Before building anything, check whether a native report or a custom report on your plan already does it. A surprising proportion of "we need a data warehouse" requests are answered by a report nobody looked for — and if the gap is real, it's usually one specific question rather than everything.

Where reporting meets finance

Accounting reporting is a different problem from analytics. It needs order-level or summarised revenue mapped to the right accounts, tax codes and payouts reconciled to the bank — which belongs in your accounting system, not a dashboard.

Don't try to solve both with one export. Connecting Shopify to your accounting system covers the finance side, including why summary sync usually beats order-level.

A practical setup

For a growing store, this covers most needs without a project:

1. Native reports for day-to-day trading.
2. A nightly bulk extract of orders, products and customers into a warehouse or even a spreadsheet.
3. Webhooks for anything needing immediate reaction.
4. A proper accounting integration for finance.
5. A documented definition of what "revenue" means in your business, written down and used consistently.

Point five is not a technical step and it prevents more arguments than the other four combined.

Most reporting problems aren't extraction problems. They're two people using the word "revenue" to mean two different sets of fields.