Restaurant POS Modifier Mapping: One Recipe, All Locations

Curran Dye

October 1, 2026

Start Here: Which Modifier Problem Are You Solving?

Mapping a POS modifier to the right recipe breaks the moment you do it by name across multiple locations. The same modifier name can need a different recipe, depending on the dish it is added to. The codes behind it rarely match from one outlet to the next. Map by POS item code instead, and standardise those codes before you scale.

That one change, mapping by code rather than by name, is the decision everything else hangs on. The three situations below are the ones a multi-site group actually hits. They come in the order they usually appear. Find the one that matches your setup and go straight to its fix.

Decision tree: can one modifier name point to one recipe at every outlet? Usually no, so map by POS item code, not by name

When the Same Modifier Needs a Different Recipe

A single modifier name is not a single recipe. "Oat milk" on a flat white is a small barista pour. "Oat milk" in a porridge bowl is a larger quantity made in the kitchen.

Map those one-to-one by name and every sale depletes the wrong amount. Your theoretical usage drifts from reality on day one.

The reliable unit is the POS item code, not the label a guest sees. Give each parent-item-plus-modifier its own code. Then map that code to the matching recipe.

Supy links a POS item code, including modifier-level items, to the corresponding recipe. Every sale of that exact item then reduces the correct ingredient quantities. Anything you have not mapped yet surfaces on a review screen after each sync. A missed modifier shows up there instead of quietly depleting nothing.

Mapping by code also fixes the depletion maths that name mapping gets wrong. When the flat white sells, the 90ml barista pour comes off stock. When the porridge bowl sells, the larger kitchen quantity comes off instead, because each code points at its own recipe. Theoretical usage then tracks what the kitchen actually served, so variance against the count reflects real consumption rather than a mapping error you unpick weeks later.

Parent item	Modifier	POS item code	Supy recipe
Flat White	Oat Milk	LAT-OAT	Oat Milk 90ml
Porridge Bowl	Oat Milk	POR-OAT	Oat Milk 220ml
Iced Latte	Oat Milk	ICE-OAT	Oat Milk 120ml
Pancakes	Extra Syrup	PAN-SYR	Maple Syrup 30ml

When Codes Differ Across Every Outlet

Here is where most groups stall. You finish the mapping at one outlet and move to the next. The modifier codes are different, so none of the work carries over.

You redo it by hand at every site. That holds even when 80 to 90 percent of the menu is identical across the group. It stops scaling the moment you add a location.

There is no one-click copy that moves a mapping between outlets. Chasing one is the wrong goal. Standardise the modifier codes first.

Give the same modifier the same POS item code everywhere. Map each code to its recipe once. Then assign that recipe to each branch, with its own selling price, target food cost and tax.

The scheduled POS sync keeps sales flowing per branch. The review screen catches anything still unmapped. Recipe costs stay current at every site, not only at the one you set up first.

The per-branch assignment is what keeps margin honest as you grow. Each branch carries its own selling price, target food cost percentage and tax on the same recipe, so one mapping serves outlets that price the dish differently. The sync runs on a schedule tied to each branch and locks while it runs, so two syncs cannot fire at once and double-count a sale.

The cross-outlet fix in four steps: standardise the modifier code, map the code to a recipe once, assign the recipe per branch, review after every sync

When Your POS Has No Shared Modifier Code

Some POS systems do not give modifiers their own code field at all. The codes then stay inconsistent across outlets, and you cannot align them by copy-paste. This is the situation that forces the manual work the other branches let you avoid. Fix it at the POS before any mapping is reliable.

Agree one code convention and apply it everywhere. Write down how a modifier is coded: parent item plus modifier. Use that exact pattern at every outlet when you build the menu in the POS.

Once the codes are consistent, mapping by code works like it does for any other group. The review screen then tells you which items still need attention.

Decision tree: does your POS give modifiers their own code field? If no, set one code convention at the POS first; if yes, align the codes then map by code

Pick the branch that matches your group. If the same modifier name needs different recipes, map to the POS item code, not the label. If codes differ by outlet, standardise them first, then let the review screen catch the gaps.

If your POS has no modifier code field, agree one convention and roll it out before you scale. One recipe, mapped by code and assigned per branch, keeps every sale depleting the right ingredients. That is how each outlet's margin stays honest.

Book a Demo with Supy - POS modifier to recipe mapping

Get weekly insights and tips delivered straight to your inbox.

Ready to optimize your restaurant operations?

Book a demo



Blog

Our operational insights





No items found.

Your questions  answered

Everything you need to know about Supy — from setup to integrations, pricing, and daily use. If it’s not covered here, just ask.

How do you map POS modifiers to recipes across multiple locations?

Start by mapping each modifier to a recipe using its POS item code rather than its name, because the same name can mean different recipes on different dishes. Give the same modifier the same code at every outlet, so the mapping is consistent across the group. Map each code to its recipe once, then assign that recipe to each branch with its own price, food cost target and tax. After every sync, check the review screen for items that are not yet mapped. That sequence keeps every sale depleting the right ingredients, whether you run two outlets or twenty.

Why does mapping modifiers by name fail?

Because a modifier name is not tied to a single recipe. The same oat milk is a small pour on a flat white and a larger quantity in a porridge bowl, so a one-to-one name mapping sends the wrong usage to your inventory. Names also vary in spelling and formatting between outlets, which breaks any automatic match. Mapping by the POS item code avoids both problems, because the code is specific to that parent item and modifier combination. When you map by code, every sale depletes exactly the ingredients that item uses, and your theoretical usage stays close to what actually left the shelf.

What is the difference between mapping a modifier by name and by POS item code?

A name is what a guest sees, and it can point to several different recipes depending on the dish it is added to. A POS item code is specific to one parent item and modifier combination, so it maps cleanly to one recipe. Mapping by name looks easier at first, but it falls apart the moment the same modifier needs a different quantity on another item or the spelling differs between sites. Mapping by code is reliable because it is unambiguous. It is also what lets a multi-site group reuse the same mapping logic everywhere, instead of rebuilding the links by hand at each outlet.

Can you copy a modifier-to-recipe mapping from one outlet to another?

Not as an automatic one-click copy, and it is better not to rely on one. Modifier codes often differ between outlets, so a mapping built at one store will not line up at the next even if the menus are nearly identical. The dependable approach is to standardise the modifier codes first, giving the same modifier the same code everywhere, and then map by code. Once codes are consistent, each recipe is mapped once and assigned to the branches that sell it. The review screen then flags anything still unmapped after a sync, so gaps are caught instead of silently depleting nothing.

What do you do when your POS has no modifier code field?

When the POS does not give modifiers their own code field, the codes stay inconsistent across outlets and cannot be aligned by copy-paste. Fix that at the POS before you try to map anything. Agree one code convention, written as parent item plus modifier, and apply the exact same pattern at every outlet when you build the menu. Once the codes are consistent, mapping by code behaves the same as it does for any other group. After each sync, the review screen shows which items still need a recipe, so you can close the gaps in order rather than guessing which outlet is missing what.

How does Supy catch modifiers that are not mapped to a recipe?

After each POS sync, any item that has no recipe mapped to it, including modifier-level items, surfaces on a dedicated review screen. That means a missed modifier is visible instead of quietly depleting nothing and skewing your variance. You work through the list, assign the right recipe to each unmapped code, and the next sale starts depleting the correct ingredients. The review screen matters most in multi-site groups, where new items and menu changes appear at different outlets over time. Checking it as part of your sync routine keeps the mapping complete, so your theoretical usage and recipe costs stay trustworthy at every branch.

Why do the same modifier's codes differ across outlets?

Often because each outlet's menu was built separately in the POS, so the same modifier was given a different item code at each site. Some POS systems also lack a shared code field for modifiers, which leaves nothing to keep the codes aligned. The result is that a mapping finished at one store does not match the codes at the next, and the work does not carry over. The fix is to standardise the codes deliberately: decide one convention and apply it everywhere, so the same modifier carries the same code at every outlet. From there, you map by code once and assign each recipe to the branches that need it.