What’s inside your Amazon data download ZIP

The ZIP at a glance

When the email link finally arrives and you download the file, you get a single archive named something like Your Orders.zip or YYYY-MM-DD-AmazonExport.zip. Inside that one archive: a directory containing 50 or so sub-zips, each named for a category of data. The Intercept reported 74 in 2022; the count drifts a bit year-over-year as Amazon adds and consolidates categories.

A typical layout looks like this:

Your Orders/
├── FileDescriptions/
│   └── DataExportManifest.csv         (reference, not orders)
├── Retail.OrderHistory.1/
│   └── Retail.OrderHistory.1.csv      ← THIS is the file you want
├── Retail.CustomerReturns.1/
│   └── Retail.CustomerReturns.1.1.csv ← returns, separate file
├── Retail.OutboundShipments.1/
├── Subscribe-and-Save.Subscriptions/
├── Retail.AddressBook/
├── Audible.*  (multiple folders)
├── Kindle.*   (multiple folders)
├── Digital.PrimeVideo.Viewinghistory/
├── Digital-Music.*  (multiple folders)
├── Alexa.*    (multiple folders)
├── Search-Data.Customer-Engagement/
├── Advertising.* x3
├── ... and 30+ more

The exact folder names vary slightly by account region and request type, but Retail.OrderHistory.1 is consistent across every account.

Folder-by-folder map

The full list of folders runs to 50 or more on most accounts. The table below covers the ones that appear on every account, with a frank assessment of which ones matter for order-history work.

The folders flagged Yes are what OHD reads when you drop the ZIP into the popup. Folders flagged Sometimes are read opportunistically (for example, address-book data is used to label shipments by destination if the toggle is on). Everything else is ignored.

The one file: Retail.OrderHistory.1.csv

Inside Retail.OrderHistory.1 is a single CSV with one row per line item across your full account history. The file is comma-separated, UTF-8 encoded, with a header row. Most personal accounts produce a CSV in the 0.5 to 5 MB range; very large accounts (a decade-plus of monthly Amazon shopping) can hit 20 MB or more.

Here is the full column list. Type and a short note for each:

A few columns surprise people on first read. Quantity is per line, not per order, so a single order with three items shows up as three rows. Payment Instrument Type is a label, not a number, Visa ending in 1234 rather than the full card number, no full card data ever ships in the export. Item Serial Number is populated for hardware purchases where Amazon captured the serial at fulfilment, often blank for everything else.

The other file you can’t skip: Retail.CustomerReturns.1.1.csv

Returns live in their own folder, Retail.CustomerReturns.1, and their own CSV. That single design choice is the source of most reconciliation errors when people build their own Excel template against the data ZIP, the order CSV looks complete because every row has a Total Owed, but those totals don’t reflect anything you returned. If you spent $4,200 on Amazon last year but returned $600 of it, a naive sum of the orders CSV reports $4,200. The actual net is $3,600.

The returns CSV holds: Order ID, Return Reason, Return Date, Refund Amount, Refund Currency, Refund Type (cash, credit, gift card), Item Title, ASIN, and a few metadata columns. The Order ID column is the join key. To reconcile, you LEFT JOIN the returns CSV onto the orders CSV on Order ID, then subtract the Refund Amount from the Total Owed.

Doing this by hand in Excel involves VLOOKUP and SUMIF and a lot of patience. OHD does the join automatically when you upload the ZIP, so refunds appear netted against the original line in the viewer, and the Insights tab shows true net spend rather than gross. For a deeper dive on how OHD handles refunds, see Amazon refund history.

The Excel trap: leading zeros

When you double-click Retail.OrderHistory.1.csv on a Mac or Windows machine, Excel opens it with a default import that aggressively type-casts every column. Numeric strings with leading zeros, the most common case is US zip codes from New England states like 02134, get auto-converted to integers and the leading zero is permanently dropped.

Recent Excel versions show a dialog before opening: “Some of the data in this file appears to have leading zeros. Do you want to convert?” The correct answer is Don’t Convert. If you already clicked Convert, close the file without saving, then re-open with the right option, otherwise the saved version locks in the bad data.

This is one of the genuinely annoying parts of working with the raw CSV by hand, and it’s why a lot of bookkeeping guides recommend importing into Google Sheets instead (Sheets handles leading zeros more gently). OHD avoids the issue entirely because the parsing happens in JavaScript, which keeps strings as strings. Whatever export format you pick (CSV, Excel, PDF), zip codes stay intact.

How OHD parses the ZIP

Drop the original Your Orders.zip onto the OHD popup’s Amazon Export tab. Within a few seconds, OHD has:

• Read the orders CSV and parsed every row into a structured order record.
• Read the returns CSV and joined refunds onto the matching orders.
• Read the optional metadata folders (addresses, subscriptions, shipments) for enrichment.
• Loaded everything into the OHD viewer, sortable by date, total, retailer, or status.
• Computed year-over-year spend, monthly subtotals, and recurring-subscription flags for the Insights tab.

From the viewer you can export back to a clean CSV (for tax software), a multi-sheet Excel workbook (for bookkeeping), or a bulk-PDF zip of receipts (for HMRC or IRS files). All processing happens in your browser; nothing about the ZIP or its contents leaves your computer.

The full upload walkthrough is on the Amazon data export and backfill page. If your upload fails with an “invalid format” error, the most common cause is that the ZIP was extracted and re-zipped, which breaks the inner folder structure. See troubleshooting the GDPR ZIP upload for fixes.

Common questions