Restaurant Legal Entity Change: The Checks to Run First

If your restaurant group is changing its legal entity, the person who decides whether that goes smoothly is not your lawyer. It is you. The filing itself is routine. Go-live morning is not: that is when the POS integration comes up empty under the new company, finance cannot pull a single record from before the switch, and four requirements nobody raised in the design phase suddenly have to be built in a week. Get the operational side wrong and a restructure that should take one quarter takes three, with your finance team flying blind through every month in between. Get it right and the switch is a non-event: the outlets keep trading, the numbers keep reconciling, and nothing goes offline while it happens. This article is the difference between those two mornings, and it comes down to five pre-checks you run before the cutover date is agreed.

What separates the clean switch from the three-quarter scramble is not the paperwork. It is whether your inventory and operations platform holds each brand's data at the outlet level or bolts it onto the legal entity above it. This is where a platform like Supy changes the outcome. Every brand entity runs on a fully isolated inventory ledger, so stock balances, recipes, wastage, inter-branch transfers and count templates are entity-scoped and carry across a restructure without any manual migration. Multi-brand isolation is enforced at every access point, so a two-entity transition never risks one brand's records bleeding into another, and staff on the incoming entity see only the outlets their profile is assigned to. Each entity configures its own tax rates independently, and a consistent audit history drawer runs across all 17 entity types in the platform, so the trail stays intact through the change. Only the entity-level configuration (named tax rates, cost-centre mapping, supplier payment details) is rebuilt under the new entity; the operational history underneath it is preserved as it stands.

The paperwork side of an entity change is what a lawyer runs. The operational side is what you run, and it comes down to a specific list of pre-checks that lands the switch cleanly. Here is that list, and what each check protects.

Confirm Menu Item Stability with the POS Vendor First

Before anything else, confirm in writing with the POS vendor that menu items and their identifiers are entity-invariant, and that the existing POS-to-operator-platform integration will re-authenticate cleanly against the new entity without requiring the item catalogue to be rebuilt. This is a five-minute question that avoids a five-day rebuild. Operators who have run a legal entity change and asked this pre-check up front carried their POS integration across cleanly on the switch day; operators who did not found out on the day.

The specific thing you are confirming is that the vendor treats menu items as belonging to the outlet or location, not to the legal entity wrapper above it. The right answer is "menu item data is unchanged under the new entity." Any hedged version of that answer needs a written follow-up before the migration date is fixed.

Set Up Toggle Access Between the Old and New Accounts

During the transition window (from the day the new entity is provisioned to the day the old entity is retired), key users need to work in both entities from a single login. Reconciliation, month-end close, and answering audit questions all require reading the outgoing entity's records while operating in the incoming one.

Provision the new entity's account with the same operator-side identities that ran the old one, using a role that carries read on the outgoing entity's historical data and full write on the incoming entity's live data. The old entity's account is not deleted on cutover, only retired: kept read-only for the audit period, then closed. Skipping this step is what forces a scramble on the first Monday after go-live, when finance can suddenly see nothing before the switch date.

Consolidate Finance Requirements Before the Wider Meeting

Finance requirements around an entity change (chart of accounts changes, cost-centre remapping, tax registration timing, cross-period reporting) show up piecemeal if they are collected in the group stakeholder meeting itself. The wider room ends up rehashing the same debate every fortnight until the requirements land as a written list.

The fix is procedural, not technical: hold a 1:1 with the head of purchasing (or the finance controller if there is one) two weeks before the wider stakeholder meeting, walk through the operational systems together, and produce the consolidated ask as a written document that the group meeting reviews rather than generates. Groups that have done this move from design phase to cutover in one quarter; groups that have not have taken three.

Know What Survives the Change Without Migration

The default assumption in a legal entity change is that everything gets rebuilt under the new entity. That is true for the legal and tax setup. It is not true for the operational data if the operator platform treats each brand entity as self-contained rather than as a subordinate view under a shared legal wrapper.

Each brand entity's inventory data (stock balances, recipes, wastage records, inter-branch transfers, and stock count templates) is self-contained and entity-scoped. If the group restructures its legal entities or re-registers a brand, the operational history for each outlet is preserved without any manual data migration. Multi-brand isolation is enforced at every access point in the platform, which means the incoming entity's staff automatically see only the outlets their profile is assigned to, and cross-brand contamination during a two-entity transition is not something the operator has to guard against manually.

Rebuild What Genuinely Has to Be Reconfigured

Some things do need to be set up fresh under the incoming entity. These are the ones a pre-check misses most often, because they feel like they should carry across automatically and do not.

Each entity configures its own named tax rates (including any VAT-exempt flag for qualifying items) independently, so the incoming entity's tax setup is a fresh configuration, not an inherited one. The same applies to cost-centre mapping into the accounting provider and to entity-specific supplier bank details on the payments side. What survives is the operational history; what needs rebuilding is the entity-level configuration wrapper around it.

Run the Full Pre-Check List

Work through these five checks in the order below. Any answer that comes back "we'll figure that out later" is the one that will push your cutover date.

Five checks, in order, before the cutover date is agreed:

1. POS vendor confirmation, in writing Menu items are entity-invariant, and the existing integration will re-authenticate.
2. Cross-account toggle access provisioned Same identities on both entities from day one, with read access on the old entity's history.
3. A 1:1 with purchasing, two weeks out Produce the consolidated finance ask as a written document before the group meeting.
4. Operational data continuity confirmed Stock, recipes, wastage, transfers and count templates are preserved. Only the entity wrapper changes.
5. Fresh entity configuration list agreed Tax rates, cost centres and supplier payment details are build items, not carry-overs.

Any "we will figure it out later" on this list is the one that pushes your cutover date.

1. POS vendor confirmation. Menu item data is entity-invariant; existing integration will re-authenticate against the new entity cleanly. Get this in writing.
2. Cross-account access. Same operator identities provisioned on the new entity from day one, with read on the old entity's history for the audit period.
3. Finance requirements pre-consolidated. A 1:1 with purchasing or the finance controller two weeks before the group stakeholder meeting, producing a written consolidated ask.
4. Operational data continuity confirmed. Stock balances, recipes, wastage, transfers, and count templates preserved without manual migration; only the entity wrapper changes.
5. Fresh configuration list agreed. Tax rates, cost-centre mapping, supplier payment details, and any other entity-level settings identified up front as build items under the new entity, not carry-overs.

Supy's multi-tenant architecture keeps each brand entity's operational data self-contained and entity-scoped, so a restructure preserves the outlet-level history automatically while the tax and cost-centre setup is rebuilt cleanly under the new entity. Our guide on restaurant chart of accounts covers the finance-side reconfiguration in depth, and the free ROI calculator can help scope the operational cost of migrating without these pre-checks in place.