StoreBuilt’s review of Shopify’s order export documentation puts one reporting issue ahead of every formula: a spreadsheet row is not necessarily an order. Extra line items, order-level fields and transaction records represent different things. Our approach is to define what each row means before anyone uses the file to answer a trading question.
A Shopify order CSV export is useful for UK ecommerce teams investigating sales, fulfilment and operational exceptions. It can also produce convincing but wrong totals when its structure is misunderstood. This guide explains how to choose an export, inspect its grain and build a repeatable handoff. The sample figures are invented teaching examples, not StoreBuilt client results or accounting advice.
In this guide
- Start with the question the export must answer
- Choose and record the export scope
- Understand the difference between rows and orders
- Keep monetary values at their original level
- Distinguish order status from payment evidence
- An illustrative report that overstates demand
- Protect identifiers during spreadsheet import
- Hand over a report someone can reproduce
- StoreBuilt point of view
Start with the question the export must answer
Write the question in plain English before opening the export dialogue. “How many orders contained this product?” differs from “How many units did we sell?” and both differ from “What money reached the bank?” Each question needs a different counting rule and, potentially, a different source.
Define the period and the event that places a record within it. An order created during September might be paid, dispatched or refunded later. A report based on creation time should not be compared casually with one based on payment activity. Record the time zone and date boundaries so another colleague can reproduce the selection.
Also identify who will use the answer. A warehouse investigation may need line items and fulfilment context. A trading review may need distinct orders and product quantities. A finance reconciliation may require payment-provider or payout evidence alongside Shopify records. The export should serve that decision without carrying unnecessary customer information into unrelated work.
Choose and record the export scope
From Orders, apply the relevant filters and open Export. Review the export options in the dialogue instead of assuming that the current page represents every matching order. Shopify supports order exports and transaction-history exports; use the option that matches the question and record the selection in the handoff note.
Shopify’s order export documentation explains that delivery can be a download or an email depending on the export scope. Large exports can take longer. A missing immediate download is therefore a reason to check the chosen scope and delivery path, rather than repeatedly starting identical exports.
Retain an untouched original with the export date, store identifier and scope in its filename or accompanying note. Work on a copy. If a later calculation looks wrong, the original lets the reviewer distinguish a source issue from a spreadsheet transformation. Never overwrite the only source file while removing columns or experimenting with formulas.
Understand the difference between rows and orders
Orders containing multiple items use additional rows in the CSV. Shopify leaves many order-level fields blank on those rows. Those blanks are part of the structure; they do not automatically mean an incomplete order or corrupted export. Inspect a known multi-item order before deciding how to transform the file.
| Teaching example | Order reference | Line item | Quantity |
|---|---|---|---|
| First row | Order A | Blue mug | 2 |
| Additional item row | Same order grouping | Gift box | 1 |
| Separate order | Order B | Green mug | 1 |
This example contains two orders, three line items and four units. Counting the rows would answer none of those questions correctly without further definition. Preserve the source order grouping when building a line-item table, and create a distinct order table when the question concerns order count or order-level totals.
Do not fill every blank down indiscriminately. Some blank values have a different meaning from an inherited order field. Decide which columns belong to the order and which belong to the line item, then document the transformation. Verify the result against several source orders, including one with more than one item.
Keep monetary values at their original level
An order total describes the whole order. If a transformation repeats it on each line item and a later pivot sums those repeated values, revenue can be overstated. The same mistake can affect shipping, discounts or other order-level amounts. Keep the order table separate, or explicitly prevent repeated values from being summed.
If the business needs product-level profitability, agree an allocation method before spreading shipping or discounts across items. Allocating by item value, quantity or another rule can produce different answers. Label an allocation as an analytical choice, preserve the original amount and avoid presenting the calculated split as a field Shopify directly supplied.
Currency also belongs in the calculation design. Do not combine amounts merely because the spreadsheet formats them with the same symbol. Identify what each source field represents and separate currencies where needed. Our month-end close guide covers the broader reconciliation process; this article focuses on getting the source rows into a trustworthy shape first.
Distinguish order status from payment evidence
A financial-status label is useful context, but it is not a complete list of payment events. Shopify states that the exported transaction history contains captured-payment data and excludes authorisations. If the question concerns an authorisation, inspect the appropriate payment record rather than interpreting its absence from this export as proof that it never happened.
Likewise, a payment capture and a bank settlement are different events. For a question about money received, use the relevant provider or payout records and their dates. Do not rename an order-total column “cash received” because that is the result a stakeholder wants to see.
Document any matching method used between sources. Prefer appropriate stable references, preserve them as text where necessary and investigate unmatched records separately. A report that silently drops unmatched rows can appear cleaner precisely because it excludes the exceptions the team most needs to understand.
An illustrative report that overstates demand
Imagine a UK gift retailer reviewing a weekend promotion. A colleague imports the export and counts rows to estimate how many orders the warehouse must handle. Orders containing gift packaging contribute extra rows, so the apparent order count rises with the number of add-on items. This is an illustrative scenario rather than a client case.
The correction starts by separating three measures: distinct orders, line items and units. The warehouse may care about all three, but for different reasons. Orders indicate parcels or packing jobs only after fulfilment assumptions are checked; units indicate picking demand; line items help describe the complexity of the basket.
The revised report shows each measure with a definition. A small source sample confirms that the grouping survived import. The team can then discuss capacity using the right measure instead of arguing about why two spreadsheets disagree. The improvement comes from clearer definitions, not a more elaborate dashboard.
Protect identifiers during spreadsheet import
Use the spreadsheet’s import controls rather than accepting every automatic type guess. Long identifiers, leading zeroes and date-like text can change when software interprets them as numbers or dates. Keep reference fields as text when their exact characters matter for matching.
Check separators, encoding and quoted text before analysing the file. Product names and notes can contain punctuation or line breaks. A proper CSV parser understands those boundaries; splitting every line at each comma does not. If columns appear shifted, resolve the import issue before deleting apparently unusual records.
Perform a few deliberate spot checks: a multi-item order, a refunded order, an order with a discount and an order near the date boundary. Choose examples relevant to the actual report. The purpose is to expose a transformation error early, not to claim that four rows prove every business interpretation is correct.
Hand over a report someone can reproduce
A useful export handoff includes the source, period, selection, transformations and unresolved exceptions. Keep that note next to the working file. The colleague receiving it should not need to reconstruct the analysis from cell colours or a conversation held several days earlier.
| Handoff field | What to record | Why it matters |
|---|---|---|
| Selection | Store, filters and export option | Establishes scope |
| Period | Date basis, boundaries and time zone | Explains inclusion |
| Grain | Order, line item or transaction | Prevents incorrect counting |
| Transformations | Grouping, typing and allocation rules | Makes calculations reproducible |
| Exceptions | Unmatched or ambiguous records | Preserves uncertainty |
| Distribution | Intended recipients and storage location | Limits unnecessary copies |
Review recurring exports when the question, source columns or connected systems change. A spreadsheet that worked last month is not automatically suitable for a new purpose. Where manual reporting becomes fragile, StoreBuilt’s Shopify implementation services can help define a more reliable data handoff before an integration is commissioned.
StoreBuilt point of view
A trustworthy export workflow begins with the meaning of a row and ends with a reproducible decision. Keep the original, separate order and item measures, and make assumptions visible. A smaller report whose totals can be explained is more useful than a large workbook that only its author understands.