Ghost Kitchen Software: Why Back-of-House Cost Control Fails When You Run Multiple Brands

The Shared Ingredient Problem: When Multiple Brands Pull from One Kitchen, Stock Attribution Breaks

A ghost kitchen running 3 brands typically shares a majority of its ingredient base across menus. Chicken, olive oil, sauces, and packaging materials appear across multiple virtual brand recipes. Each delivery order triggers depletion of specific ingredients - but without recipe-level inventory links, the system records only that items left the kitchen, not which brand's order caused the depletion.

The consequence is that end-of-period stock counts reveal a variance the operator cannot explain. Chicken is short. Is it Brand A's high-velocity burger menu, Brand B's wrap range, or Brand C's rice bowl that drove the discrepancy? Without per-brand recipe depletion tracking, there is no answer.

This is not an edge case. Ghost kitchens sharing 4 or more virtual brand menus drawing from the same core ingredient list face this problem every service period. The variance accumulates and is typically discovered only during the monthly stock count, at which point corrective action is weeks late.

The software question to ask: does the platform link each delivery order to a recipe, and does that recipe depletion update live stock-on-hand per ingredient in real time - not in a batch at end of day?

Delivery Platform Commissions and Food Cost: Why the Number on Your Dashboard Is Probably Wrong

Delivery platforms report gross revenue. Inventory software calculates food cost as a percentage of revenue. When the two systems are not reconciled against net retained revenue, the food cost figure is systematically understated.

A 28% food cost calculated against gross order value at a 30% platform commission rate is actually 40% food cost on the revenue the operator retains. A business operating at what it believes is a 28% food cost is running at a food cost that would be considered loss-making in a traditional restaurant context.

This calculation error persists because delivery platform settlement data and inventory software run in separate silos. Operators reconcile them manually in a spreadsheet, monthly at best, by which time the damage to margins has been absorbed for weeks.

What corrects this is a procurement and inventory platform that either integrates with delivery aggregator data or, at minimum, allows the operator to configure the revenue base against which food cost percentages are calculated - using net revenue figures rather than gross.

The question to ask when evaluating ghost kitchen software: can the platform calculate food cost against net retained revenue per virtual brand, or does it default to gross delivery revenue?

Recipe Cost Drift: How Supplier Price Changes Turn a Profitable Brand Loss-Making Within Weeks

Recipe costs are set at launch. Ingredient prices change. In most ghost kitchen operations, the gap between those two events is not tracked.

A fresh chicken breast priced at $4.20 per kilogram at launch may cost $4.72 per kilogram 8 weeks later - a 12% increase. If the recipe cost model is not updated, every analysis of that brand's margin is calculated against the original cost. For ghost kitchens operating on already-thin margins, a 12% ingredient cost increase left untracked for 8 weeks can eliminate most of what remained of the brand's gross margin.

Manual recipe cost updates happen quarterly in most operations. More commonly, they are triggered by a significant price shock that is impossible to ignore rather than by regular review. This means up to 8 weeks of margin erosion can accumulate before any corrective action is taken.

Inventory software that links purchase order prices to recipe costs closes this gap without requiring manual review cycles. The question for a ghost kitchen software evaluation: when a supplier delivers chicken at a price 12% higher than the previous order, does the platform surface the price discrepancy for review and update the recipe cost of every dish containing chicken, or does it require a manual update?

Multi-Supplier Procurement: Why Formal PO Workflows Fail When Half Your Vendors Use Messaging Apps

Ghost kitchen procurement is frequently split between formal distributors - who operate via purchase orders, confirmed pricing, and structured invoices - and smaller local suppliers who operate via messaging apps, handwritten receipts, and prices that change with market availability.

Procurement software designed for formal supplier relationships does not accommodate the second category. An operator cannot raise a purchase order to a supplier who does not have an email address and delivers on a handshake agreement. When the informal side of procurement represents a material portion of the ingredient cost base, that cost is invisible to the inventory system.

The outcome is a food cost calculation that accounts for only 70% of actual ingredient spend. The remainder - the informal supplier spend - lives in a separate cash ledger or is reconstructed from receipts at month-end. This creates a structural blind spot in the cost model that no reporting tool can fix if the data is not captured upstream.

The requirement is software that supports both a structured PO and GRN flow for formal suppliers and a lightweight goods receipt mechanism for informal suppliers that captures cost and updates inventory without requiring a formal purchase order to exist first.

Ask in a ghost kitchen software evaluation: can the platform receive stock and record cost from a delivery that has no associated purchase order, and does that receipt update both inventory levels and food cost in the same workflow?

Central Kitchen Architecture: What Ghost Kitchens Actually Need from Back-of-House Software

Ghost kitchens operating multiple brands from one facility are, structurally, a central kitchen with virtual branches. The physical kitchen produces for Brand A, Brand B, and Brand C. Each brand is operationally equivalent to a branch. The economics of the operation require visibility into what each branch costs to supply.

Standard multi-location restaurant software treats each branch as a physical site with its own purchasing infrastructure. Ghost kitchen brands do not have their own purchasing; they draw from a shared production facility. The software architecture that maps to this model is a central kitchen module that can treat each virtual brand as a customer receiving production from a central supplier.

With a central kitchen model in the software, each brand can receive production orders from the kitchen with full cost attribution. The kitchen can consolidate ingredient demand across all brands into a single purchasing view, generating supplier orders for the combined volume while maintaining per-brand cost assignment. Internal billing between the kitchen and each brand becomes traceable.

Without this architecture, a ghost kitchen managing 3 brands is effectively running 3 separate inventory databases - one per brand - or managing all brands as a single undifferentiated cost centre.

Ask in an evaluation: does the software have a central kitchen module that can treat virtual brands as internal customers, with consolidated purchasing from the kitchen and per-brand cost attribution?

What to Evaluate When Choosing Ghost Kitchen Software: Five Back-of-House Capabilities

The delivery aggregation problem is largely solved. The back-of-house cost problem for multi-brand ghost kitchens is not. When evaluating ghost kitchen software, these five capabilities are the ones that separate platforms built for this operating model from generic restaurant tools:

Recipe-level depletion per brand in real time. Each delivery order should trigger an immediate stock deduction for every ingredient in the recipe, attributed to the specific brand. End-of-day batch updates are insufficient for multi-brand operations where a single ingredient is shared across menus.

Net revenue food cost calculation. The platform must support food cost calculation against net retained revenue, not gross order value. Without this, commission costs make every multi-brand food cost figure an understatement.

Automatic recipe cost updates from invoices. When a GRN is received at a different price from the purchase order, the platform should surface the discrepancy and update every recipe containing that ingredient. Manual recipe cost review cycles leave too large a window for margin erosion.

Mixed supplier workflows. The procurement module must handle both formal PO-invoice suppliers and informal goods receipt scenarios where no purchase order precedes delivery. Informal supplier spend that cannot be recorded is invisible cost.

Central kitchen or virtual branch architecture. The software must be able to model the ghost kitchen as a central production unit supplying multiple virtual brands, with consolidated purchasing and per-brand cost attribution. This is the structural feature that makes multi-brand unit economics visible.

Supy is built for multi-location and multi-brand food operations. The platform's central kitchen module allows ghost kitchen operators to treat each virtual brand as an internal customer, consolidating procurement across all brands while maintaining per-brand cost and production visibility. The Received Items page surfaces every price discrepancy for review when a GRN arrives at a different price from the purchase order, giving operators a systematic process for keeping ingredient costs current rather than relying on quarterly manual updates. With 75+ integrations covering POS, delivery aggregators, and accounting systems, and AI Predictive Ordering that builds purchase orders from the AI sales forecast run through recipes minus current stock, Supy addresses the back-of-house complexity that generic restaurant software and delivery middleware leave unaddressed.