Most business software assumes stock sits still, demand is reasonably steady, and margin is set by the difference between purchase price and sale price.
Hospitality violates all three. Ingredients perish on a timeline. Demand arrives in bursts that are only partly predictable. And margin is not decided at the till — it is decided by what goes into the dish, which is measured in grams by someone under pressure.
These are genuinely structural differences, not vocabulary. Which makes hospitality one of the clearer cases where sector-specific requirements are real — the distinction drawn in choosing technology for your sector.
Recipe costing is where the margin actually lives
In retail, the cost of goods is what you paid for the item. In a kitchen, the cost of a dish is the sum of its components at current prices — and both the components and the prices move.
Three consequences most operators feel but few measure:
Ingredient prices change constantly, and a dish priced against last season's costs may be barely profitable now. Without recipe costing linked to actual purchase prices, nobody notices until the month looks wrong.
Portioning is a margin decision made by hand. A dish costed at a specific weight, served consistently heavier, loses the difference on every plate. Multiplied across a service, this is frequently larger than any theft.
Waste is part of the recipe. Trim, peel and prep loss are real costs. A costing that uses purchased weight rather than usable yield understates every dish.
The practical requirement: recipes defined with quantities, linked to current purchase prices, so the true cost of a dish is visible and updates when input costs change.
Wastage has to be effortless to record
Every kitchen wastes. Spoilage, over-prep, mistakes, returns. It is a normal cost of operating.
The problem is that recording it takes effort at exactly the moment someone is busy and slightly embarrassed — which means it goes unrecorded, and then reappears in the numbers as unexplained variance indistinguishable from theft.
This is the general stock problem from what actually prevents stock variance, sharpened by perishability: in hospitality, unlogged wastage is a much larger share of total variance than in most sectors.
The design requirement is unusual and specific: recording waste has to be faster than not recording it, and it must not feel like an accusation. If a chef has to navigate three screens to log a dropped tray, it will not be logged.
The service window is the constraint
Hospitality demand is not steady. It concentrates into service periods, and everything about the systems has to survive that concentration.
Order entry has to be fast. Counted in taps. Modifications, splits and course timing are normal, not exceptions, and if they are slow the staff will work around them — which is the peak-hour failure described in what breaks a billing system at peak hour.
Bills split many ways. A table of eight paying separately, partly by card and partly in cash, is routine. Systems that handle this badly generate queues at the worst moment.
Order modifications are constant. Something is added after ordering, something is sent back, a dietary requirement changes a dish. These must be as fast as the original order.
Offline must work. A restaurant mid-service cannot stop because connectivity dropped. If billing halts, the service continues on paper and the day's record is reconstructed afterwards — which is when the numbers stop being trustworthy.
Stock that expires
Standard inventory asks how much. Perishable inventory also asks how old.
That requires rotation to be enforced rather than hoped for. If first-expiry-first-out depends on a busy person reading dates on a shelf, it will not hold consistently — and the cost appears as spoilage nobody can attribute.
It also changes purchasing. Ordering to a reorder point works for goods that keep. For perishables, ordering has to account for expected demand over a short window, which means purchasing decisions depend on forecasting rather than on stock level alone.
Multi-venue adds a specific problem
Operators running several venues face everything above, plus transfers.
Stock moved between venues to cover a shortage is a common, sensible practice and a reliable source of discrepancy — because it is usually informal. Something is taken, and it is either recorded at one end, both ends, or neither.
The requirement is that a transfer is one linked transaction with a dispatch and a receipt, with in-transit stock visible. Otherwise the shortfall appears at one venue and the surplus at another, and both look like errors.
What we build for this
SPEXA is built for multi-outlet operations including bars, cafés and restaurants, and it treats billing, inventory, purchasing and accounting as views of one record rather than connected systems.
The relevance to hospitality specifically is that a sale in a kitchen operation should decrement ingredients, not just a menu item. Where the till and the stock system are separate, someone reconciles between them — and in a perishable, high-volume environment, that reconciliation is never current enough to act on.
Our three build principles apply with unusual force here: the counter comes first, screens show only what a decision needs, and every day must close clean. In hospitality the daily close is not administrative hygiene — it is the only point at which the day's wastage, voids and cash are still knowable. The method is in how Truffaire builds software.
Frequently asked questions
Do we need hospitality-specific software?
Frequently yes for the kitchen side — recipe costing, portion control and expiry handling are genuinely structural. The common weakness of specialist products is everything else: purchasing, accounting and multi-venue reporting. Check the parts you use daily, not just the specialist ones.
How do we control food cost properly?
Recipes costed against actual purchase prices, portioning measured rather than assumed, and wastage recorded at the moment it happens. Without the third, the first two produce a theoretical cost that never matches reality.
What about integrating delivery platforms?
Worth doing if delivery is a meaningful share of revenue, because orders arriving outside your system are orders that do not decrement stock. The reconciliation burden of unintegrated platforms grows with volume.
Should each venue have its own system?
No. Separate systems per venue reproduce the multi-location problem — where multi-outlet businesses lose money covers why one record matters more than more reporting.
How long does implementation take?
Weeks rather than months in our experience. The longest task is usually building the recipe database, which most operations have never formally documented.
Where to start
Cost three dishes properly — actual current ingredient prices, actual portion weights, including prep loss. Compare against what you charge.
Then record wastage honestly for two weeks, without consequences attached, purely to see the number.
Those two exercises usually reveal more about where margin is going than any system will, and they tell you which capability you actually need to buy.
If you want a read on which parts of your operation would benefit, get in touch.