Central Production Kitchen Software: A UK & Ireland Multi-Site Guide (2026)

What is a central production kitchen, and what should the software actually do?

A central production kitchen — a central production unit (CPU) in most UK and Irish operations, a commissary in North American writing — is one site that preps in bulk for several others. Sauces, stocks, marinades, doughs, bakery, sous-vide proteins and prepped veg get made once, by skilled hands, then distributed to the outlets that finish and serve them.

The software has one job, and it is narrower than most vendor pages suggest: keep an accurate, ingredient-level chain of custody from a delivery note at the CPU to a plate at an outlet. Everything operators actually want — true food cost, allergen labelling, waste control, fair franchise billing — falls out of that chain being unbroken. Every failure mode below is the same chain snapping somewhere.

If you're earlier in the journey and still deciding whether to centralise at all, start with the operator's guide to central kitchen management. This piece assumes the CPU exists and covers what UK and Ireland multi-site operators hit next.

Why do spreadsheets break at the second site, not the first?

One CPU feeding one outlet is a conversation. The head chef knows what went out because they watched it go. A spreadsheet works because a single person holds the whole picture in their head and the sheet is just a record.

The second outlet breaks it, and specifically it breaks these three things at once:

• Ordering becomes contested. With one outlet, "we need more gravy" is a fact. With two, it's a claim against a shared, finite production capacity — and now someone has to decide who gets it and prove why.
• Cost stops being observable. With one outlet, CPU cost is outlet cost. With two, you need to apportion a 40-litre batch across two sites that took 25 and 15 litres, on a day when the onion price moved.
• Nobody is watching the same number. The CPU counts what it made. The outlets count what they received. Those two numbers diverge quietly, and the gap is invisible until stocktake.

That's why the honest trigger for buying software is not turnover or headcount. It's the second receiving site, or the first franchised one — whichever lands first.

How do you calculate the true cost of a made item?

This is where most multi-site operators are flying blind, and it's the highest-value thing to fix.

The cost of a litre of your house curry base is not the sum of today's ingredient prices. It's a weighted average that has to absorb four things:

1. The actual ingredient cost of that batch, at the prices you actually paid — not list prices, not last month's.
2. Yield loss. 10 kg of onions is not 10 kg of prepped onion. If your recipe says 10 kg and your true yield is 78%, every costing built on the raw figure is wrong by a fifth on that line.
3. Nested inputs. If the curry base goes into a finished sauce, which goes into a retail jar, you have three levels of made item and the cost has to roll up through all of them.
4. Production labour and overhead, if you want the number to survive contact with an accountant.

Do this in a spreadsheet and it is correct on the day it is built and drifting by the end of the week, because supplier prices move and nobody rebuilds the sheet. The reason to put it in software is not elegance — it's that the roll-up has to happen automatically on every goods-in, or it doesn't happen at all.

The practical test when you're evaluating a system: when a supplier's onion price changes, how many made items silently re-cost, and does the finished dish margin on your menu move with it? If the answer is "you re-enter it," it's a spreadsheet with a login.

What about allergens and labelling when food moves between sites?

This is the compliance point that catches UK and Ireland operators out, and it's worth getting straight because the answer is counter-intuitive.

Prepacked for Direct Sale (PPDS) rules — introduced by what most people call Natasha's Law — apply to food packed on the same premises from which it is sold. Food that is packed at your CPU and then transported to a different site to be sold is generally not PPDS. It falls under the fuller prepacked food labelling requirements instead, which are more demanding: name of the food, full ingredients list with allergens emphasised, quantitative ingredient declarations, net quantity, durability date, storage conditions, and the food business name and address.

Operators routinely assume moving production to a CPU simplifies labelling. For food that arrives at the outlet already packed, it usually does the opposite.

Two things follow for your systems:

• Labels must be generated from the recipe, not typed. If an ingredient substitution at the CPU doesn't propagate to the label, you have a compliance failure with a paper trail pointing straight at you.
• You need batch-level traceability in both directions — from a batch code back to the goods-in records, and forward to every site that received it. That is what makes a withdrawal a phone call instead of a crisis.

This is an operational summary, not legal advice, and the detail varies by what you pack, where, and how it's sold. Confirm your specific setup with the FSA (or the FSAI in Ireland) and your local environmental health officer before you finalise a labelling process.

Should stock move between sites as a transfer or a sale?

It depends entirely on whether the sites share a legal entity, and getting it wrong is expensive in both directions.

Arrangement	How stock should move	What the system must produce
Company-owned sites, one entity	Internal transfer at cost	Stock ledger both sides, no invoice, no VAT event
Company-owned, separate entities	Inter-company sale at an agreed transfer price	Inter-company invoice, VAT treated correctly, both ledgers
Franchised sites	Sale at cost-plus or price-list	Real invoice, VAT, credit terms, statement, dispute trail

The common failure is running franchise supply as if it were an internal transfer — moving stock on a delivery note and reconciling to an invoice manually at month end. That works until a franchisee disputes a line. Then you're reconstructing three weeks of deliveries from WhatsApp messages, and you will usually concede the point because you can't prove it.

If any part of your estate is franchised or separately incorporated, inter-company invoicing is not a nice-to-have — it's the thing that keeps the relationship civil.

Do you actually need multi-echelon production?

Often, no. Be honest about this before paying for it.

You need multi-echelon (nested) production when a made item is an ingredient of another made item — stock becomes sauce becomes finished dish — and especially when those steps happen at different sites. Bakery, patisserie, sous-vide and ready-meal operations hit this early.

You do not need it if your CPU makes finished components that go straight out. A single production level with good costing beats a complicated system nobody updates.

The related capability worth more than it sounds is production feasibility — "can I actually make 200 portions of this tomorrow?" Answering it means exploding the recipe through every level, checking free stock at each, and telling you the shortfall. Without it, production planning is a chef's memory, and the failure mode is discovering the gap on the morning of.

How do you stop over-production and waste?

Three mechanisms, in order of how much they pay back:

Batch and expiry tracking with FEFO. First-Expired-First-Out, not first-in-first-out. Pick lists that surface the batch closest to expiry are the single highest-return control in a CPU, because production waste is overwhelmingly a picking problem, not a forecasting problem.

Indent deadlines. Outlets raise requisitions against a cut-off; the CPU produces against confirmed demand rather than an estimate. This converts guesswork into a number someone signed off, which also settles the "we never ordered that" argument.

Variance visibility. Compare what the recipe says you should have used against what stock says you did. Persistent variance on one line is a yield problem, a portioning problem, or a shrinkage problem — and the size of it tells you which is worth a manager's afternoon.

Spreadsheet, bolt-on, or integrated?

	Spreadsheets	Standalone production system	Integrated with EPOS & stock
Cost to start	Nothing	Moderate	Moderate
True made-item cost	Manual, drifts	Yes	Yes
Recipe-driven labels	No	Usually	Usually
Re-costs on price change	No	Sometimes	Yes
Sales pull through to demand	No	Via integration	Native
Inter-company invoicing	Manual	Sometimes	Yes
Breaks when	2nd site	Integration lapses	—

The case for integration isn't tidiness. It's that demand comes from sales. If the production system can't see what the outlets actually sold, indents stay manual forecasts and you've automated the paperwork while leaving the guesswork. That's also the argument against adding yet another subscription to a stack that already has five — we've written about what a fragmented restaurant software stack actually costs.

Where should you start?

A rollout that works, in order:

1. Item master and real supplier prices first. Every downstream number inherits these errors. Do not skip to recipes.
2. Recipes with honest yields. Weigh things. Measured yields, not the numbers on the supplier spec sheet.
3. One product line end to end — goods-in, production, batch, transfer, receipt at the outlet — before widening. Find the breakages on one line, not forty.
4. Indents with a real cut-off time, enforced.
5. Inter-company invoicing last, and only if you have separate entities or franchisees.

Most failed implementations invert this and start with the exciting part. The item master is boring and it decides whether any of it works.

What this won't fix

Worth saying plainly, because comparison content in this category rarely does.

Software will not tell you whether centralising was the right call — that's a question about your menu, your estate's geography and your delivery costs. It won't fix a CPU that lacks capacity, and it will make an under-invested kitchen's constraints more visible, not less. It won't resolve a franchise relationship that's already adversarial; it will only make the facts harder to argue about, which helps only if you were right. And it won't survive staff who route around it — if the real ordering channel stays WhatsApp, the system holds fiction.

The bottom line

For UK and Ireland multi-site operators, central production kitchen software earns its place when it does four things: costs made items accurately as prices move, generates labels from recipes, moves stock between sites with the right paperwork for the right legal structure, and answers "can we make this" before the morning of.

If your CPU feeds more than one site, or any site you don't wholly own, the spreadsheet has probably already stopped telling you the truth — the stocktake just hasn't caught up with it yet.

FullGuest runs central production, recipe costing, stock, EPOS and multi-site reporting on one platform, so production demand comes from actual sales rather than a forecast typed into a sheet. See how the commissary module works, or compare it against running separate systems.