Skip to main content

Menu and pricing

Your menu is the single source of truth that every channel — the POS, your online ordering site, the kitchen display, third-party delivery — reads from. This page walks through the structure, the pricing options, and how to push changes live.

OrderUp's menu is built from five building blocks. You'll find each one under Menu in the management app.

  • Items. A single sellable thing: "Margherita Pizza," "Iced Latte," "House Burger." Each item has a name, description, photo, base price, sales category, and tax rate.
  • Modifier groups. Reusable lists of choices attached to an item: "Choose your bun," "Add toppings," "Pick a size." A modifier group can be required or optional, and you set min/max selection counts.
  • Modifiers. The individual options inside a modifier group: "Brioche bun," "Tomato +$1," "Large +$2."
  • Menu groups. The way you organize items for guests and staff. Groups can be nested — for example, MenuLunchSandwiches → "House Burger."
  • Sales categories and courses. Sales categories drive your reports ("Beverages," "Food," "Retail"). Courses control kitchen routing and order timing ("Appetizer," "Entrée," "Dessert").

Tags (under MenuTags) let you mark items with attributes guests filter by — vegan, gluten-free, spicy, new — and they show up on the online menu and POS.

Composite items (meal deals)

Some items aren't a single dish — a "Lunch Special" is one snack plus one entrée, each guest-picked, and each one needs to fire to its own kitchen station on its own timing. For these, use the Components tab on the item editor instead of a modifier group.

A component group asks "choose N," the same as a modifier group, but each choice points at a real menu item rather than a text option. At ring-up, the composite becomes one line for "Lunch Special" carrying the full price, plus one line per pick — and each of those behaves like an ordinary item, with its own course and kitchen station. A modifier group can't do this: a modifier isn't a line on the ticket, so a meal deal built from modifier groups would fire and route everything as a single dish.

When you add a choice, you also pick which menu group it belongs to. That's what decides its course and station, and it's asked explicitly because a composite choice isn't reached by navigating the menu the way an à la carte item is — the editor can't infer it. You can set a price add-on per choice (for example, "Shrimp Dumplings +$2"); the base composite price stays on the parent line and add-ons stack on top of it.

Composite items are rolling out gradually — if you don't see a Components tab on an item, it isn't enabled for your restaurant yet.

Open Food and Open Drink

Every restaurant has two built-in items, Open Food and Open Drink, that back the POS's open-item ring-up — the button a server uses to type a custom name and price for something that isn't on the menu. Configure their course, tax rates, sales category, prep stations, kitchen name, and POS color like any other item, so an open-rung line still routes to the right station, taxes correctly, and shows up in the right report category.

They can't be archived, deactivated, renamed, or added to a menu group — a menu group is how an item reaches the POS, online ordering, and every delivery marketplace, so keeping them out of every group is what keeps them off the customer-facing menu entirely.

Display order

Menu groups and items appear in the position you set. Sort the group list by Position, and use Move to top from a group's menu to bring it to the front. That ordering is consistent everywhere a guest or staff member can see your menu: the POS, the management app's own group list, and your online ordering site all render groups and items in the same operator-authored order, with the same rule for where a sub-group sits when it's nested under more than one parent (its position under that parent wins).

Because groups can nest under more than one parent, some structural mistakes don't show up anywhere in the tree view — a group can end up reachable only through another group's schedule, listed twice under the same menu, or connected on one side but not the other. Each of those is invisible until it causes a symptom, like a whole section of the menu disappearing outside a happy-hour window it was never meant to be tied to.

The MenuGroups page checks for this automatically and shows a banner naming the affected groups when it finds a problem — nothing appears when the menu is structurally clean. Use the banner to jump straight to the group that needs fixing.

Pricing strategies

You have three ways to price an item, and you can mix them across your menu.

Fixed price

Set a single price on the item itself. This is the default and works for most things.

Size-based pricing

Some items don't have one price — a coffee comes in 12oz, 16oz, and 20oz. Use a modifier group with a price-bearing modifier for size choices. Each modifier carries its own price, and the item itself can have a base price of $0.

Group-level pricing

Sometimes you want to override the item's price based on where it appears on the menu. For example, a side salad sold à la carte is $8, but the same side salad inside a "Lunch Combo" group is $4. Open the menu group, set its pricing strategy, and every item under that group inherits the override.

The POS uses the group nearest the item to decide which price to show. If you have nested groups and only the top-level group sets an override, the override still flows down. If a deeper group sets its own, that one wins.

Per-parent overrides

This is the feature most other POS systems can't do cleanly. The same modifier — say, "Add tomato" — might be a free option on a sandwich but a $1 add-on on a salad. With a per-parent override, you keep one canonical "Tomato" modifier and tell each menu group what it should cost (or whether it should appear at all) inside that group.

To set one up, open the menu group, find the item or modifier in the override panel, and set the price (or hide it). Overrides take priority over both the modifier's own price and any group-level pricing. Use them when:

  • A modifier should cost different amounts in different contexts (lunch combo vs. dinner).
  • A topping should be hidden on certain menus (no avocado on the breakfast menu).
  • You want a single "happy hour" price layered on top of an existing menu without duplicating items.

A modifier can also be renamed independently of price — separately for Display name (what the guest sees), POS name (the till button), and Kitchen name (what prints on the ticket). This lives on the modifier itself, not on the per-parent override panel above: open the modifier group and use its Modifiers tab, rather than the pricing/visibility tab you use for per-group overrides. Because the rename isn't parent-scoped, it applies everywhere that modifier is used, the same way in every menu group — it's for keeping a ticket-facing name short and specific ("PORK WONTON") while the guest-facing name stays descriptive ("Fried Pork Wontons"), not for making a modifier read differently on different menus. Leave any of the three blank to fall back to the modifier's own name.

Tax rates

Set up your tax rates first under Settings → Restaurant Settings → Operations → Tax Rates. Then assign a tax rate to each item — or to a sales category, which cascades to every item in that category.

For multi-jurisdiction setups (a single item taxed differently for dine-in vs. takeout, or in vs. out of state), assign multiple rates and let the order context pick the correct one at checkout.

Publishing changes

Every menu edit you save is published immediately. The POS keeps a local copy of the menu for offline resilience and pulls a fresh copy whenever:

  • A device starts up.
  • A manager taps Refresh Menu from the POS settings.
  • A push notification fires after a significant menu change.

For larger reorganizations, work in the management app, save as you go, and ask your team to refresh menus on their devices before the next shift. Online ordering and your public menu page update within seconds — there's no separate publish step there.

Common workflows

  • Daily specials. Add an item, mark it active, place it in a "Specials" group at the top of your menu, and deactivate it at end of day.
  • 86 an item. From the POS or management app, toggle the item to unavailable. It greys out everywhere within seconds.
  • Seasonal menus. Build the entire menu inside a parent group, set the group inactive, and flip it on when the season starts.

For pricing math at the order level — discounts, promos, comps — see the POS guide for taking and adjusting orders.