Item Selection Details and Item Modifier Selection Details

When operators search "Toast inventory report," most guides point them to the Product Mix report. That's an aggregated view — fine for menu-engineering questions ("which items are stars?"), useless for inventory planning. For actual PAR math you need row-per-sale data. On Toast, that comes from two exports.

Item Selection Details

Where: Toast Web → Reports → Sales → Item Selection Details.

What you get: one row per menu item sold, per order. If a customer orders a latte and a bagel in the same check, you get two rows. If another customer orders two lattes, you get two rows (or one row with Qty = 2, depending on Toast's config).

Required columns (the shape our ingest expects):

• Location — which store
• Order # — Toast's order identifier
• Sent Date — when the order was fired to the kitchen (timestamp, usually MM/DD/YYYY HH:MM)
• Menu Item — the name shown on the register
• Menu Group — the category
• Qty — how many
• Void? — whether it was voided

What it's good for: counting "how many plain bagels sold on Saturday," "how many lattes at 8am vs 2pm," "which days of the week skew which items." The atomic data you need for any real inventory math.

What's missing: modifiers. A "latte" row doesn't tell you whether it was made with oat milk, whole milk, or almond milk. That's in the other report.

Item Modifier Selection Details

Where: Toast Web → Reports → Sales → Item Modifier Selection Details.

What you get: one row per modifier applied to an order. "Oat milk" selected on a latte is one row. "Extra shot" is another. Upsells ("add avocado") are in here too.

Required columns:

• Location
• Order # — ties back to the Item Selection row via the same order number
• Sent Date
• Modifier — the modifier name (e.g., "Oat milk")
• Option Group Name — the group it belongs to (e.g., "Milk type")
• Parent Menu Selection — the menu item the modifier was applied to
• Qty
• Void?

What it's good for: tracking ingredient usage that lives in modifiers. Most QSRs on Toast have a "milk type" modifier group, a "flavor" modifier group, and so on. The actual oat milk / almond milk / vanilla syrup usage is in here, not in Item Selection Details.

Why you need both

The two exports link on Order #. Item Selection says what was sold; Item Modifier Selection says how it was modified. For inventory you care about both because:

How to pull them

1. Sign in to Toast Web (toasttab.com).
2. Navigate to Reports → Sales.
3. Click Item Selection Details in the list of reports.
4. Set the date range. Go as far back as Toast will let you — 60 days is the usual PAR window but extra history only helps.
5. Export → CSV. Save it.
6. Go back and click Item Modifier Selection Details.
7. Same date range. Export → CSV.
8. You now have two files to upload.

Par Inventory's detect logic reads the header row and figures out which is which — you don't need to label them on upload. The file with Modifier and Parent Menu Selection columns is flagged as the modifier export; the one with Menu Item and Menu Group is flagged as the item-selection export.

What we don't use (and why)

For clarity on Toast's other reports:

• Product Mix. Aggregated daily/weekly per-menu-item totals. Looks convenient but loses order-level granularity, doesn't include modifiers, and doesn't give you day-of-week patterns unless you export it with the right settings. Most articles suggesting Product Mix haven't thought through the modifier problem.
• Sales Summary. Daily totals — revenue, orders, guests. Useful for high-level trending, not for per-item inventory.
• Menu Engineering report. Rates items as stars / plow-horses. A pricing tool, not an inventory tool.

We chose Item Selection + Item Modifier specifically because they're the finest grain Toast exposes. You can always aggregate up; you can't un-aggregate.

Common gotchas

Uploading into Par Inventory

Par Inventory's upload page (Data → Upload) accepts drag-and-drop for both files. On upload, it:

1. Parses the header row and classifies each file as Item Selection, Item Modifier, or Unknown.
2. Samples the first 20 rows to show you a preview and flag multi-location files.
3. Stores the raw CSV in blob storage and creates a toast_exports record.
4. Runs the import to fold the rows into daily toast_menu_item_sales and toast_item_modifier_sales tables, deduped by (store, business date, menu item / modifier).

Re-uploading overlapping date ranges is fine — the dedup logic replaces old rows with new ones. Add files as new date ranges come in; the system never double-counts.