.jpg)
Multi-Brand Restaurant Groups: Why One Database Per Brand Fails
What a multi-brand restaurant group is actually deciding
A multi-brand group's inventory structure is the set of decisions about how many separate databases you run and where the boundaries fall between them. The real question is not one system or many. It is which brands share a database and which get their own, and most groups answer it with the wrong rule.
The instinct is to give every brand its own database because the brands feel separate. In practice a group runs on three tiers. The group is the top account where reporting rolls up. Each outlet is a brand or entity that holds its own supplier relationships, stock positions and cost centre. Each location is a physical site under an outlet. A group-level dashboard rolls every outlet up, so you can compare food cost and variance across brands from one view without forcing them into the same database.
That last point is what makes the per-brand instinct expensive. Separate reporting does not require separate databases. You get the cross-brand comparison from the group tier regardless of how the databases underneath are drawn, which frees you to draw them on the axis that actually saves work.
Why one database per brand collapses under its own maintenance
One database per brand fails because shared data has to be maintained in every database that holds it. A supplier price change, a new pack size, a renamed ingredient: each edit is repeated by hand in every brand database that lists that item. The more brands you split, the more times you redo the same change.
Take a group with six brands that mostly buy from the same suppliers. Under one database per brand, a single shared-supplier price change is six manual updates. Consolidate the brands that share suppliers into three databases and the same change is two updates. The work does not scale with how carefully you separated the brands. It scales with how many databases repeat the same supplier and product records.
This is the objection groups usually raise themselves once they picture the day-to-day. The brands look independent, but their purchasing is not, and the database structure has to follow the purchasing, not the brand chart. A one base item record with each supplier's pack sizes linked and kept in sync across outlets only pays off when the outlets that share it sit in the same database.
The real split: supplier and product overlap, not brand count
Split databases on two axes: how much suppliers and products overlap, and whether the brands sit in the same country and legal entity. Consolidate brands that share suppliers and products; split where they genuinely do not, and split across countries for tax and currency. Brand count never enters the rule.
Read it as four situations. High overlap in one country is a clear consolidation: run those brands together and maintain each item once. Low overlap in one country is a clean split by concept, because forcing unrelated items into one map creates its own cleanup work later. Different countries almost always split, since tax, currency and legal entity draw a hard line; where concepts inside a country still share suppliers, one database per country with those concepts merged is usually the shape that settles.
A useful counter-check operators land on is one core-brand database plus one combined database for the concepts that share everything. It follows the same overlap logic from the other direction, which is why it holds up. If your proposed structure cannot be justified by supplier and product overlap or by a country boundary, it is a structure built on brand identity, and it will cost you in maintenance.
The central kitchen is its own type of location, and a supplier to your outlets
An in-group central kitchen or bakery is not a supplier you bolt on from outside, and it is not just another outlet. In Supy it is its own type of location, managed alongside your outlets but with different functionality. You run it as a location with its own stock, production and ordering, and it acts as a supplier to the brands it feeds: it takes their orders, orders on their behalf, ships against delivery notes and bills them with a markup. Both roles are first-class, a location you manage inside the group and a supplier to your outlets, which is exactly what a plain outlet cannot be.
Set it up as a plain outlet that only transfers stock at cost and you hide two things you need: the true landed cost at the receiving brand, and the margin the central kitchen is making internally. Because it is a managed location as well as a supplier, billing the sites it feeds with a markup keeps both visible, while the kitchen still rolls up into the same group reporting as every other location. If it also sells to restaurants outside the group, that external order flow runs separately from the internal one, so the in-group relationship stays clean.
Genuine stock movements that are not a sale, such as lending a case between two sites, still belong in an inter-location transfer that the receiving site accepts before its stock updates. The test is simple: if one side is charging the other with a markup, that is the central kitchen supplying; if it is just moving stock at cost, it is a transfer.
Decide the group's inventory structure before you onboard, not during
Settle the structure as a written set of decisions before onboarding starts. The most expensive rework in a group rollout is not the data load. It is discovering mid-migration that two brands name and categorise the same items differently, or that nobody agreed how the central kitchen is modelled, and having to rename, reclassify and re-map while the clock runs.
| Decide before onboarding | Why it bites later |
|---|---|
| Item naming and category conventions across brands | Merged brands with different naming force a rename and reclassify pass mid-migration |
| Setting up the central kitchen as its own location and how it bills the sites | Changing it after go-live re-writes how every internal delivery is costed |
| Cost centres per site and per concept | Retro-fitting cost centres breaks the profitability history you already loaded |
| Multi-level menu categories for per-concept reporting | Added later, they cannot back-fill the periods already reported |
| How goods received notes are consolidated and invoices stored | Left open, receiving teams invent their own approach per site |
Documenting these up front means the implementation team starts from the real shape instead of re-asking basic structural questions at every site. Keep the finance lead in the loop as a decision-maker alongside operations, because the database boundaries are also the boundaries of the reporting they will live in.
The decision in four checks
Before you commit a structure, run each proposed database split through four checks. If a split cannot pass at least one of the first two, it is drawn on brand identity and should be merged.
| Check | Consolidate when | Split when |
|---|---|---|
| Supplier and product overlap | Brands buy the same items from the same suppliers | Ranges and suppliers barely intersect |
| Country and legal entity | Same country, entity and currency | Different country, tax regime or currency |
| Central production | Set a shared kitchen up as its own location that supplies the outlets | Never split a brand out just to hold its kitchen |
| Reporting need | Group rollup already gives cross-brand comparison | Only when a brand needs fully isolated records for an external reason |
Structure the group on this logic and the platform reflects how the business actually buys and cooks, not how the brand chart happens to be drawn. For the wider picture of what changes as a group scales, see our guide to multi-unit restaurant management, explore how a single restaurant inventory management platform holds multiple brands, and if you want a quick baseline on where each concept sits before you begin, our free food cost calculator gives you a starting number.
