A bakery group outside Klang makes its custard base once a day. Forty kilos come out of one kitchen and go to six outlets, where it fills buns that are sold, rung up, and deducted from stock.
Ask that group what a bun costs and you will get a number. Ask them to defend it and the room goes quiet, because nothing in their software ever costed the custard. The base was never sold. It was produced, and then it was moved. Their point-of-sale system has an opinion about the first event and no concept of the other two.
This is the boundary almost every Southeast Asian F&B chain hits somewhere around outlet five, and it is not a gap in any particular product. It is structural. A POS fires on a sale. Every inventory feature bundled into a POS hangs off that trigger. A central kitchen exists precisely to make things that are never sold to anybody, which means there is no event for the deduction to hang from.
Two different jobs share one name
"Recipe costing" in Southeast Asian F&B software almost always means depletion, and depletion runs backwards from a sale. A customer buys a bubble tea, the system looks up the recipe, and boba, milk, sugar and a cup leave inventory. It is a good feature. Every serious regional platform has it.
Production runs the other way. It starts with an instruction to make something, consumes raw materials against that instruction, and creates a new stock item that did not exist before. That item has a cost derived from its inputs and its yield, it sits in a store, and it gets moved to outlets where it finally depletes against sales.
Depletion needs a recipe. Production needs a recipe, a batch record, a yield figure, a transfer with a cost attached, and a receiving location that accepts the cost rather than re-deriving it. Systems that do the first are common here. Systems that do the second are rare, expensive, or both.
The distinction sounds academic until month-end, when six outlets each report a food cost percentage and the custard sitting inside those percentages was valued by whoever last typed a number into a spreadsheet.
What the regional platforms put in writing
The evidence is in what vendors document, not what they could probably do.
FoodStory is the Thai reference point, with the vendor stating more than 60,000 restaurants on the platform. Its inventory story is explicit and it is a depletion story: เชื่อมสูตรอาหาร (BOM) พร้อมตัดสต๊อกอัตโนมัติ on the homepage, and on the POS page ผูกสูตรเข้ากับวัตถุดิบ พร้อมตัดคลังได้ทันที -- link the recipe to the raw material, deduct the store immediately. Multi-branch groups are handled through FoodStory Master Data. Across the homepage, the POS product page and the software page, no central kitchen (ครัวกลาง), production, or inter-branch ingredient transfer module is named.
StoreHub goes a step further and is worth reading carefully, because it is the one that gets closest. Its Malaysian inventory page documents recipes managed with composite tracking, tracking exact ingredient costs for every dish or product, and transferring stock across outlets. That third item is real and it matters. But transferring a sack of flour between two shops is a different operation from producing a semi-finished good that never existed as a purchased item. Composite tracking and outlet transfers are documented; batch production is not.
ESB is the Indonesian case, and the largest F&B line in the region by product count -- twelve of them, from ESB POS through a Kitchen Management System to ESB Capital. The one aimed at this problem is ESB Goods, labelled a Supply Chain Management System and sold on managing the restaurant supply chain "efficiently & anti-fraud". Procurement fraud, stated that plainly on a product tile, tells you what Indonesian multi-outlet operators are losing sleep over. What the public pages do not describe is recipe bills of materials, batch production, or costed transfers.
FeedMe in Malaysia states more than 10,000 merchants and names an inventory product, described in a single line about optimal stock levels, waste and cost management. Its detailed features page did not render, so nothing further can be claimed either way.
The global answer, and the price that keeps it out
There is a mature category that does all of this properly. It is bought separately from the POS, and MarketMan is its clearest published example.
MarketMan sells a commissary product, and the way it is priced is more instructive than any feature list. Standalone is USD 499 a month, described as a central kitchen producing for your own multi-unit operation. External Unlimited is USD 749 a month, for a central kitchen selling to third-party restaurants, catering businesses or ghost kitchens. Those are add-ons. The base plans are USD 249, USD 299 and from USD 449 a month.
So a chain that wants central kitchen production handled the way a US operator handles it starts at roughly USD 748 a month before anything else. StoreHub's top Malaysian tier, Pro, is RM 471 a month, with Starter at RM 122 and Advanced at RM 235.
The second reason it stays out is simpler. MarketMan publishes support numbers for North America, the United Kingdom and Germany. None for Asia-Pacific. This is the same shape we found when looking at the SEA POS stack, where the global names had either retreated from the region or priced themselves out of it.
In Southeast Asia, the door marked "central kitchen" opens onto an ERP
The regional software that does model production is not restaurant software. It is enterprise resource planning with an F&B skin, and HashMicro is the one that markets a dedicated central kitchen system.
Its feature list reads like a genuine production system rather than a POS module: Forecast-Driven Batch Planning, Smart Recipe Yield Scaling, Multi-Outlet Production Allocation, Real-Time Ingredient Variance, Production Records, Kitchen Stock Control, Shelf-Life Risk Detection, Waste Pattern Analytics, Station Load Balancing, Prep Task Automation, Quality Check Alerts, and Costing & Reports. That is the correct vocabulary. It also publishes no price.
Which leaves a SEA chain with three real options rather than a shortlist: keep depletion in the POS and run production in a spreadsheet, buy an ERP and accept an ERP implementation, or import a USD-priced tool with no local support. Our F&B operations stack guide put inventory and recipe costing in Google Sheets "until you cross 10 outlets" and that is an honest description of where most groups sit. The point of this piece is what the tenth outlet costs you if you never resolved it.
Yield is the number that breaks the spreadsheet
The reason production costing resists a spreadsheet is not volume. It is that yield varies and depletion assumes it does not.
Forty kilos of input does not produce forty kilos of custard, and it does not produce the same amount twice. Trim, evaporation, spillage, a batch held too long, a new cook. A depletion model applies a fixed ratio and reports a theoretical cost that quietly drifts from the real one. A production model records what was planned against what came out, which is exactly what HashMicro is naming with Smart Recipe Yield Scaling and Real-Time Ingredient Variance.
If your system cannot record that you planned 200 portions and got 187, you do not have a food cost figure. You have an assumption, compounding daily across every outlet the central kitchen feeds.
Where each option stands
| System | Market | Central kitchen production | Published price |
|---|---|---|---|
| MarketMan | North America, UK, Germany | Yes, commissary sold as an add-on | USD 249 / 299 / from 449 a month, plus commissary at USD 499 or 749 |
| HashMicro | SEA | Yes, dedicated central kitchen system | None published |
| StoreHub | Malaysia and region | Composite recipes and outlet stock transfers; batch production not documented | RM 122 / 235 / 471 a month |
| FoodStory | Thailand | Not documented | None as text; the price table is an image |
| ESB | Indonesia | Not documented on public pages | None published |
| FeedMe | Malaysia | Not documented on reachable pages | None published |
Every figure and feature above was checked against the vendor's own pages on 2026-08-18.
What we could not verify
Stating this matters more than filling the table.
Nimbly's site returned HTTP 403 to us, so nothing about its current features or pricing could be confirmed this session and it is deliberately absent from the table above. FeedMe's detailed inventory features page did not render, so its recipe and production capabilities remain unknown rather than absent. FoodStory publishes its price table as an image and its /pricing/ path returns a 404, so no THB figure is verifiable from the site. ESB's /en/harga path also returns a 404 and no product page carries an IDR figure. HashMicro's central kitchen page publishes no price at all. MarketMan's homepage and its pricing page showed different Starter and Growth figures when we checked; the pricing page figures are the ones used here.
None of that means those products are weak. It means a buyer cannot compare them from the outside, which is itself a finding about this category.
How to run the evaluation
- Establish whether you have production at all. One question does it: is there any item your outlets consume that you never purchased and never sold? A sauce, a dough, a marinade, a par-baked shell. If yes, you have production, whatever your POS thinks.
- Make the vendor produce a batch in the demo. Not deduct a recipe -- produce. Watch them create 40 units of a semi-finished item, move 8 to an outlet, and then show the receiving outlet's cost per portion. A vendor whose system only depletes will show you a stock adjustment and a manual cost field.
- Ask what happens when the batch misses. Planned 200, got 187. If the answer is that someone edits the quantity, the cost of the shortfall lands nowhere and your variance is invisible.
- Price it against the spreadsheet you are running now, not against your POS bill. The comparison is the ERP quote versus the cost of a wrong food cost percentage across every outlet the kitchen feeds, and below about five outlets the spreadsheet often still wins.
Step 1 is the one that gets skipped. Groups buy on outlet count, and outlet count is the wrong trigger. A twelve-outlet chain where every kitchen cooks from raw ingredients has no production problem at all. A three-outlet chain with one commissary has had one since the day it opened the commissary, and has probably been reporting food cost from a spreadsheet ever since.