Mapping Toast menu items to inventory items

Here's the real reason most "do inventory on a spreadsheet" attempts collapse: the sales data and the inventory data are on different lists, and connecting them is work nobody wants to do.

The two lists

Menu items are what you sell. They live in your POS (Toast, Square, etc.). For a typical bagel shop:

• Plain bagel
• Everything bagel
• Sesame bagel
• Plain bagel with plain cream cheese
• Plain bagel with scallion cream cheese
• Everything bagel with plain cream cheese
• Oat milk latte
• Iced oat milk latte
• Matcha latte
• Cold brew
• Cold brew with oat milk

Maybe 40–60 menu items on a small QSR.

Inventory items are what you order from vendors. For the same shop:

• Plain bagels (sold by the dozen, cased in cases of 10 dozen)
• Everything bagels
• Sesame bagels
• Cream cheese, plain (sold by the 8-oz tub, cased in cases of 12)
• Cream cheese, scallion
• Oat milk (sold by the half-gallon)
• Whole milk
• Espresso beans
• Matcha powder
• Cold brew concentrate

Maybe 20–40 inventory items.

The mapping

Every menu item consumes one or more inventory items. Every inventory item is consumed by one or more menu items.

Why this matters for PAR

PAR is set on inventory items (the things you order), not menu items. So to compute PAR for oat milk, you need:

1. Take the daily sales count for every menu item that uses oat milk
2. Multiply by the ounces of oat milk each one uses
3. Sum across all oat-milk-using menu items
4. Divide by 64 oz (half-gallon) to get half-gallons used per day

That sum is the "daily usage" input to the PAR formula. Without the mapping, you can't compute it.

The shortcut operators take is to use one menu item as a proxy — "oat milk latte sold X per day, so we need X × 4 oz of oat milk." This is wrong by however much oat milk goes into iced lattes, matcha, cold brew, etc. For a shop with one oat milk drink it works; for a shop with four, it undercounts by 60–70%.

What the mapping looks like

A simple mapping structure:

menu_item → [ (inventory_item, quantity, unit), ... ]

Example rows:

To get inventory usage, aggregate the sales by the (inventory_item, unit) pair:

oat milk usage today =
  (oat milk latte sold × 4 oz) +
  (iced oat milk latte sold × 5 oz) +
  (matcha latte sold × 6 oz) +
  ... / 64 oz per half-gallon

How to build the mapping

The hard part is the first pass. Do it once, carefully.

1. Export your full Toast menu. Reporting → Menus, or the menu section of the admin. Get a list of every active menu item.
2. List your inventory items. Either from your accounts-payable records (things you pay vendors for) or by walking the walk-in with a clipboard.
3. For each menu item, write down what it consumes. Quantities matter more than you think — 2 oz vs 4 oz of oat milk per drink doubles your oat milk PAR.
4. Sanity-check by reverse-mapping. For each inventory item, list every menu item that uses it. Did you miss any?

This takes 2–4 hours for a 40-menu-item shop, longer if you're being thorough about ingredient quantities. Do it when you have time, not the day before a count.

Maintenance

The mapping drifts. Every menu change requires a mapping update:

• New menu item → new mapping row(s)
• Changed recipe → update existing quantities
• Dropped menu item → remove mapping row(s)
• New inventory item (e.g., switched oat milk brands) → remap everything that used the old one

Nobody actually does this on time. Most operators discover the mapping is stale when they over-order by 40%.

The automated version

Par Inventory asks you for this mapping once during setup. You can paste it in, upload a CSV, or let our LLM parse a loose description ("matcha latte has 6 oz oat milk and 0.1 oz matcha powder, plus a splash of vanilla syrup") into structured rows. After that, every PAR computation uses the mapping to translate Toast sales into inventory usage automatically.

When you add a menu item, you update one row. When you change a recipe, you update the quantity. The translation math happens every time — you don't re-run it by hand.