Inventory
Procurement

Multi-Site Restaurant Rollout: What to Standardise Before You Open

What to standardise before you open the next site

Standardise your data before the next site opens, and counts and costs reconcile across every location from day one. It means fixing six things in the master data first: a complete item master, one code per item, a shared category tree, consistent naming, par levels per site and tidy supplier records. Set them while you still run one site well, so the new location inherits order instead of copying your mess.

  1. Fill in the item master. Every item needs its unit of measure, pack size and price before upload. Operators routinely hand over a master with blanks in these fields, which forces guesses at migration and leaves the costing wrong from the first count. A case that should read as 6 x 2 litres instead lands as a single unit, and every recipe built on it inherits the error. Check that each item carries all three before anyone loads it.
  2. Keep one code per item. The same product entered under two codes splits its usage across two records, so group-level variance and theoretical cost never add up. One site counts it, another orders it, and the numbers drift apart with nobody at fault. Merge duplicates into a single code before you clone the catalogue to a new site, because the clone copies the duplication too.
  3. Agree one category tree. A category structure that each site invents on its own makes reports unreadable across the group. One location files an item under produce, another under prep, and the category spend report stops meaning anything the moment you compare sites. Decide the categories once, apply them everywhere, and sort every item into exactly one. A shared tree is also what lets a regional manager compare food spend across sites without re-mapping anything by hand.
  4. Settle on one name per ingredient. Unmanaged data breeds variants: one operator carried about 20 versions of a single ingredient after three years, which made its inventory and recipe numbers unreliable. Each variant counts, orders and costs on its own, so usage scatters and no report can total it. Pick one name per ingredient and retire the rest, so a stock count and a recipe point at the same thing.
  5. Set par levels per item, per site. Each location holds different stock and sells at a different rate, so par levels belong to the site, not the group. A downtown lunch site and a suburban dinner site should never share the same reorder points. Agree the method for setting them before rollout, even though the numbers themselves differ by location.
  6. Tidy the supplier records. One supplier record per vendor, with consistent pack sizes and prices, lets a new site inherit a clean setup instead of rebuilding it. Messy supplier data is the part that quietly breaks ordering at the new location: the wrong pack size turns every purchase order into a manual correction. Reconcile the records to what the supplier actually delivers before go-live.

Par levels are the hardest standard to set for a brand new site, because it has no sales history to base them on. Copy the par levels from a comparable location, then tighten them once a few weeks of real usage come in.

If you'd rather not work par out by hand, the free par level calculator does it for every item on your sheet from your usage, delivery days and supplier lead times.

About 20 variants of a single ingredient found in one operator's unmanaged data, with one name per ingredient as the fix

How to roll the standard out to each new location

Once the master data follows one format, restaurant inventory management software replicates it to each new site instead of rebuilding it by hand. When you add a location, the platform inherits the supplier item configurations, including pricing and ordering settings, from an existing site. Nobody re-enters the same supplier setup for every new venue, so the standard you set once travels to the next opening on its own.

Recipes carry across the same way. A recipe can be assigned to specific branches, each with its own selling price, target food cost and tax rate. A group runs different margins on the same dish without ever creating a duplicate recipe. Stock count templates stay saved per outlet, so each site keeps its own shelf-order list while the item master underneath stays shared across the group.

The new site then needs a clean starting point. A first opening count sets a verified inventory baseline before any stock moves, which is what lets variance mean something from week one. Skip it and the first month's numbers measure your setup error, not your operation. For the counting controls that keep that baseline honest across the group, see our guide to stock count controls across multiple sites.

Rollout sequence: standardise master data, add the new location, supplier configs inherit, run the opening count, counts and costs reconcile group-wide

Before you open the next site, pull your current item master and scan two columns: blanks in unit of measure, pack size or price, and any item that appears twice under different codes. Fix those two first. They are the gaps that multiply with every location, and the cheapest place to close them is the one site you already run well. Everything else on the list is easier once those two are clean, because a tidy master is what the new site copies from.

Book a Demo with Supy - standardise before your multi-site restaurant rollout

Ready to optimize your restaurant operations?

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.

What does it mean to standardise data before a multi-site restaurant rollout?
+

Standardising means every item, supplier and recipe follows one agreed format across the group before any new location goes live. In practice you lock six things: a complete item master, one code per item, a shared category tree, consistent ingredient naming, an agreed method for setting par levels, and tidy supplier records. Fix these in the master data once, while you still run a single site well, rather than letting each new location recreate its own version. A clean standard is what a new site can copy, so counts and costs reconcile across the group from day one.

Why do duplicate item codes break group-level reporting?
+

Duplicate codes split one product's usage across two records, so no report can total it correctly. One site counts the item under the first code while another orders it under the second, and group variance and theoretical cost drift apart with nobody at fault. The problem compounds when you clone the catalogue to a new location, because the clone copies the duplication too. Merge every duplicate into a single code before rollout. A product that lives under one code is counted once, ordered once and costed once, which is the only way the group numbers add up.

How do you set par levels for a new location with no sales history?
+

Copy the par levels from a comparable site you already run, then tighten them once a few weeks of real usage come in. A new location cannot calculate its own par from history it does not have, so a similar site is the best starting point: match it by format, menu and covers rather than by region. Review the numbers after the first month, when actual consumption replaces the estimate. Par levels belong to the site, not the group, so expect the final numbers to differ by location even when the method for setting them is shared.

What should be in the item master before you upload it?
+

Every item needs its unit of measure, pack size and price filled in before anyone loads it. These three fields drive costing and counting, so a blank in any of them forces a guess at migration and leaves the numbers wrong from the first count. A case that should read as six two-litre bottles must not land as a single unit. Check each item carries all three, remove duplicate codes, and sort every item into one agreed category. A complete, deduplicated master is the strongest predictor of whether a new site's numbers reconcile after go-live.

How does a new site inherit supplier and recipe setup?
+

When you add a location, the platform inherits the supplier item configurations, including pricing and ordering settings, from an existing site, so nobody re-enters them by hand. Recipes work the same way: a recipe can be assigned to specific branches with its own selling price, target food cost and tax rate, so the group runs different margins on one dish without duplicating the recipe. Stock count templates stay saved per outlet, so each site keeps its own shelf-order list while the item master underneath stays shared. The standard you set once travels to each new opening.

Do you need a stock count before a new location opens?
+

Yes, a first opening count sets a verified inventory baseline before any stock moves. Without it, the first month's variance measures your setup error rather than your operation, because there is no trusted starting quantity to compare against. Run the opening count once the site is stocked and before service begins, using the same count template and controls as the rest of the group. A clean baseline is what lets variance mean something from week one, and it is far cheaper to establish on day one than to reconstruct after the numbers have already drifted.

When should you standardise, before or after rollout?
+

Standardise before rollout, while you still run a single site well. Fixing the item master, codes, categories, naming and supplier records after you open means every new location has already copied the gaps, so you reconcile the same problems in several places at once. Done beforehand, the clean standard is what each new site inherits, and the data stays consistent as you grow. The one exception is par levels, which a brand new site cannot set from history it lacks; there you copy a comparable site first, then refine. Everything else is cheaper and safer to lock in advance.

Ready to transform your operations?

Join 3500+ restaurant operators cutting costs, streamlining operations and making smarter decisions with Supy.