The technical file — BOM (Bill of Materials) for short — describes what a finished product is made of: which ingredients go in, in what quantities and at what internal cost. You define it once, and the system uses it afterwards for every production ticket, for the production cost calculation, for margin per product and for production batches. The recipes are configured by us during onboarding, based on the ones you already use.
A recipe well defined in the system turns the questions "what does it actually cost me?" and "how much mozzarella do I still have for the evening shift?" from opinion into a number.
The system sums the current cost of each ingredient × the quantity in the recipe and shows you the production cost per unit. You no longer estimate "I think it costs about 20 lei" — you see the number, updated at every goods receipt.
Gross margin (sale price − production cost) appears directly in the catalog and in sales reports. You immediately see which products bring in money and which simply take up space on the menu.
At every production ticket, the quantities in the recipe are automatically subtracted from the ingredient stock. You see what you still have — and, when it is not enough, the system warns you before you start the batch.
Same recipe = same taste, same portion. When you hire a new cook, the technical BOM is their guide: 0.250 kg base, 0.080 kg sauce, 0.100 kg mozzarella — not "the way Maria does it".
Three blocks: the finished product, the ingredients with the quantities for one unit, and the calculated cost. Easy to read, easy to verify.
Product name, category, barcode (if applicable), photo for the menu. E.g. "Pizza Margherita — 320 g finished product, sale price 85 MDL".
Each ingredient with the quantity for one unit of finished product, expressed in the platform's units of measure (kg, l, buc, m², m³). E.g. 0.250 kg base, 0.080 kg tomato sauce, 0.100 kg mozzarella, 0.005 kg basil, 0.010 l olive oil.
The system multiplies the quantity by the current cost of each ingredient and displays the total production cost. The margin appears by comparing it with the configured sale price.
An illustrative example; actual figures vary per venue:
PIZZA MARGHERITA — 1 unit (0.320 kg finished product)
0.250 kg base (in-house semi-finished) cost: 4.20 MDL
0.080 kg tomato sauce cost: 1.50 MDL
0.100 kg mozzarella cost: 12.00 MDL
0.005 kg fresh basil cost: 0.80 MDL
0.010 l olive oil cost: 1.10 MDL
────────────────────────────────────
Production cost: 19.60 MDL
Sale price: 85.00 MDL
Gross margin: 65.40 MDL (77%)
Illustrative example — actual figures vary by supplier, venue and period. During onboarding, we go into the catalog with your real prices and the system does the rest.
A well-defined recipe means that a single action — "we produced 40 pizzas" or "we started a bakery batch" — triggers everything, correctly.
When you mark a unit as produced, the system "explodes" the recipe and automatically subtracts the exact quantities from each ingredient's stock. You no longer count manually how many grams of mozzarella went out.
When you create a batch (e.g. 80 loaves + 60 baguettes + 40 croissants), the system calculates the total ingredient requirement and warns you where stock falls short. You decide: order urgently or reduce the batch.
The production cost is calculated using ingredient prices at the moment of preparation, and the result feeds the report with margin per product. Input prices are updated from the ingredient catalog when you start the goods receipt.
In the shift / month report you see sales − production cost − loss cost for each product. You know which are the real winners on the menu, not just the ones that sell a lot.
An ingredient can itself be something you produce in-house: tomato sauce, pizza base, croissant dough, panna cotta base, cocktail syrup. You define its own technical BOM and use it in other recipes as if it were a purchased product.
When a recipe needs 0.080 kg of tomato sauce and the tomato-sauce stock is zero, the system can automatically explode the sauce sub-recipe and decrement the primary ingredients (peeled tomatoes, oil, garlic, basil, salt) proportionally.
When to use it: semi-finished items with a short shelf life, or ones made in small quantities on demand.
The alternative: the system does not auto-explode; instead it requires you to start a separate production ticket for the sauce (e.g. 5 kg in the morning for the whole day). Each sale then only decreases the "tomato sauce" stock.
When to use it: sauces, bases, doughs prepared in large volumes once a day — you want to know exactly when and who prepared them.
The "auto vs. explicit" choice is made per product. During onboarding we discuss your flow and configure what fits each semi-finished item best.
A technical BOM's recipe stays fixed and versioned — this guarantees taste consistency and correctness of the cost calculation. For variations (extra mozzarella, pepperoni slices, a separate drink), the customer orders add-ons as distinct menu products, with their own recipe and their own price.
Receipt for a typical order:
Pizza Margherita 1 unit 85.00 MDL (fixed recipe)
Extra mozzarella 1 unit 12.00 MDL (add-on product)
Garlic sauce 1 unit 8.00 MDL (add-on product)
Coca-Cola 0.33 l 1 unit 25.00 MDL (separate product)
───────────────────────────────────────────
TOTAL 130.00 MDL
Each add-on is a product with its own SKU, its own recipe (if it is a semi-finished item) and its own price — it appears as a separate line on the receipt. The waiter adds it to the order like any other product. Simple, transparent, each line with its own margin.
When a recipe is prepared, the system generates a production ticket that records exactly the ingredients and quantities used at that moment. This way, if you later change the recipe, past runs stay intact in the history — visible through the production tickets, with everything that was used at the time.
At every preparation of the recipe, a production ticket is issued with a snapshot of the consumed ingredients (quantity + cost at the moment of preparation). The ticket remains in the archive for inspection.
The auditor opens the production ticket from the relevant period and sees exactly which ingredients were consumed — with quantities, costs and the operator who validated them. In HoReCa the flow is direct and quick; in retail it requires a little navigation through the app to reach the relevant ticket.
When you adjust the recipe (e.g. increase the mozzarella quantity), the new runs use the updated recipe. Past runs remain unchanged in their production tickets — the history is honest, not retroactive.
The standard presets we configure during onboarding. Custom roles (e.g. head chef with the right to modify only certain recipes, or a read-only cost analyst) can be added at any time — we configure them after discovery, included in onboarding.
Can create new recipes, modify existing recipes (with a new version), configure semi-finished items and add-ons as distinct products. Sees the production cost and margin on all products in the operational reports.
Sees the active recipes — uses them as a guide when preparing — but does not modify them. Cannot change quantities, cannot add ingredients. Operational cleanliness, no surprises at audit.
Full read-only, including on version history. Sees exactly what was active on each date — for internal control, accounting verification or fiscal audit.
No. Recipe entry by our team is included in all production packages: Micro Producer — up to ~50 recipes configured at onboarding + one pilot batch; Extra Production — up to ~200 SKU recipes with advanced setup (divisions configured at onboarding according to your flow). Beyond the package limits or for recipes added later — paid support effort, priced in hours after evaluation. Alternatively, you can add recipes yourself by following the video + text documentation.
We do not have a dedicated bulk import in the UI. It can be done on request as paid support effort — we extract from your Excel, clean the data (inconsistent names, inconsistent units of measure, dependencies between recipes) and enter them into the system. We quote in support hours after evaluating the source file.
Not as a system feature. We do not have an automatic validity interval on the recipe. In practice, the company instructs its employees to use the active recipes during the relevant period — an administrative decision, not a technical one. If you want a recipe temporarily "hidden", you deactivate it in the menu at the end of the season and reactivate it when it starts again.
Nothing is rewritten retroactively. Every past preparation is stored in the production ticket from that moment, with the ingredients and quantities actually consumed. Changing the recipe only applies to future runs.
The starter package for micro production (up to 50 recipes configured by us + one pilot batch) is Micro Producer · 1,500 MDL/month. For workshops / central kitchens with advanced setup (up to 200 SKU recipes + divisions configured at onboarding) — Extra Production. In a 20-minute discovery call we tell you exactly which package fits you.
We will tell you exactly what your recipe setup looks like, how many technical BOMs are justified from the start and which ones stay for a second phase. Discovery included in onboarding — no technical task on your side.
SGAPPS LABS SRL · Chișinău, Moldova · Continuously in production since 2018 · POS · ERP · MEV fiscal register · Android fleet