Best multi-site inventory software for UK restaurant and pub groups

Running one site, most inventory software looks the same. Running several, the differences that didn't matter suddenly do:

1. Does stock data move between sites, or stay separate?

A central kitchen supplying satellite sites needs stock to move — a transfer out of one location is a transfer into another, not two disconnected events. A group where each site buys and stores independently needs the opposite: separate stock, so one site's shrinkage doesn't get lost in another's numbers.

2. One supplier list, or several?

A group buying centrally wants one supplier list and one set of prices applied everywhere. A group where each site manager buys locally — common where sites are in different regions with different suppliers — needs supplier lists that can differ per site without becoming five unrelated systems that happen to share a login.

3. Do the numbers roll up, or do you want them apart?

An owner wants one gross profit figure for the group. A site manager wants their own site's number, not blended with four others hiding whether their site specifically is trading well. Multi-site software needs both views, not one or the other.

4. Pricing that scales the way your group actually trades.

A flat per-site fee is predictable and easy to budget, but it charges a quiet Tuesday site the same as your busiest weekend location. Usage-based pricing rewards uneven trading between sites but is harder to forecast until you have a few months of real data across all of them. Neither is wrong — it depends whether predictability or fairness-to-usage matters more to how the group is actually run.

What to check before choosing, across sites specifically — not just once:

• Can a recipe be edited once and apply everywhere, or does every site need its own copy updated separately?
• If a supplier price changes, does that update ripple to every site using that supplier, or does someone have to repeat the update per location?
• Can you see one site's numbers in isolation, not just the group total?
• What happens to the cost per site as you add a fifth, sixth, tenth location — does it scale linearly, or does the per-site cost fall as the group grows?

How the categories of platform compare

Not a brand-by-brand comparison — the honest differences are between categories of platform, and any specific product's fit changes with them.

• Stock and recipes — Single-site tools stretched across sites: usually separate per site by default; sharing is a workaround. Flat per-site enterprise platforms: shared centrally, built for it. Usage-based platforms: can be shared or kept separate.
• Pricing shape — Single-site tools stretched across sites: cheap per site, but the workaround costs staff time. Flat per-site enterprise platforms: predictable flat fee per site, same whether the site is busy or quiet. Usage-based platforms: scales with actual use, rewards uneven trading.
• Setup for a new site — Single-site tools stretched across sites: rebuild the workaround each time. Flat per-site enterprise platforms: add a site, add the fee. Usage-based platforms: add a site, pay for what it uses.
• Best fit — Single-site tools stretched across sites: a group that hasn't outgrown single-site thinking yet. Flat per-site enterprise platforms: groups that trade steadily and want one predictable number. Usage-based platforms: groups with uneven trading between sites, or still finding out how heavily they'll use it.

A readiness checklist before you switch

• You know, per site, roughly how many invoices, counts and recipe changes happen in a normal week — not exactly, but enough to judge a usage-based cost against a flat one.
• Someone owns "what the supplier list looks like across sites" as an actual decision, not a default nobody chose.
• You've decided whether site managers see only their own numbers, only the group total, or both — before the software forces an answer on you.
• You have a rough order for onboarding sites — all at once, or one at a time while you learn what breaks.

What actually happens when you switch, in phases

Multi-site rollouts fail less often from the software and more often from trying to do everything at once. A rough shape that holds up:

1. One site first. Get recipes, suppliers and counts right on a single site before anyone else touches it — mistakes here are cheap to fix and expensive to repeat five times over.
2. A second site, on purpose different from the first. Your busiest site and your quietest, or two with different supplier setups — this is where you find out whether "shared" and "separate" were configured correctly, not just possible in theory.
3. The rest, once the first two haven't surprised you. Rolling out to ten sites before the second one has run a full week is how a software problem becomes a ten-site problem instead of a one-site problem.

Where FoxEra fits, honestly:

Stock, recipes and suppliers can be shared across sites or kept separate per site, and every site's numbers are visible both individually and rolled up to the group.

We don't have a large multi-site customer base to point to yet — that's the honest limitation, not a hidden one.