Food, labour and last night's till,in one number by morning.
marql reads your POS, your supplier invoices and your payroll lines, and gives every venue its prime cost — with the shift, the channel and the category the number came from.
Prime cost · demo group
last 7 days
| venue | revenue | food | labour | prime cost |
|---|---|---|---|---|
| City Center | 31 200 € | 9 700 €31.1% | 8 400 €26.9% | 58.0% |
| Westside | 24 800 € | 8 900 €35.9% | 7 600 €30.6% | 66.5% |
| North Park | 19 400 € | 5 900 €30.4% | 5 200 €26.8% | 57.2% |
| Harbour | 16 900 € | 5 400 €32.0% | payroll not connected | not computed |
food cost 5 400 € · 32.0% — the labour half is missing, so no prime cost is printed
prime cost = (food + labour) ÷ revenue · labour is read from the payroll lines in your ledger
How the number gets built
Four steps, and the kitchen changes nothing.
Every venue keeps its till and its supplier. What marql has no source for, it leaves empty and says so.
Every venue connects as it is
The till over its own API, the delivery platforms over theirs, the accounting or the 1C that carries your invoices. Read-only: no price, no menu and no stock is written back.
The night becomes numbers
Sales, covers and voids land per venue and per hour, supplier invoices become cost of goods, and the payroll lines in your ledger become labour.
No payroll source — the venue keeps its food cost and prime cost is not computed
The morning brief ranks what is at stake
A venue off its own normal for that weekday, a category whose cost has been drifting for weeks, a channel that stopped paying for itself — ranked by the money behind them, not by how recently they happened. In beta, and labelled that way in the product.
What you act on gets measured
Commit to a change and its baseline freezes; when the window closes the ledger writes what it was worth, with the comparison the number rests on.
Task never completed — inconclusive, and no money is written
The question a dine-in P&L cannot answer
What the delivery channel is worth.
Channels · demo group
one venue, last 7 days
| channel | revenue | platform fee | food | left over |
|---|---|---|---|---|
| Dine-in | 19 900 € | — | 6 100 €30.7% | 13 800 €69.3% |
| Delivery | 8 300 € | 2 240 €27.0% | 2 740 €33.0% | 3 320 €40.0% |
| Takeaway | 3 000 € | — | 860 €28.7% | 2 140 €71.3% |
| the venue | 31 200 € | 2 240 € | 9 700 € | 19 260 € |
the platform fee is what the delivery connector reports · labour is never split by channel, so this line stops at contribution, not profit
What a group gets out of it
The numbers a service week is actually run on.
Which venue, which shift, which channel, which category — and what it costs to leave any of them alone for another week.
Prime cost per venue
Cost of goods plus labour against revenue, daily, per venue and for the group — the arithmetic drawn in the figure above rather than described.
The one F&B number, without waiting for the accountant.
Food cost where the invoices are
Cost of goods by venue, category and supplier, read from the ledger and the supplier invoices rather than typed into a sheet.
A supplier's price move shows up as a cost line, not as a surprise at close.
Every channel in one view
Dine-in, takeaway and the delivery platforms, with the orders and the commission the platform reports, in the same model as the till.
You can price the delivery channel instead of guessing at it.
The shift, not just the day
Covers, average check and voids by hour and by shift, each compared with that venue's own normal for the same weekday — drawn below.
A soft Friday evening stops hiding inside a good week.
Anomalies, and problems that repeat
Robust statistics flag a venue or a category that has broken its own pattern, and separately flag the ones that have been broken for weeks, with the cost accumulated so far.
The slow drift gets found, not only the bad night.
Everyone sees their own venue
Owner, COO, analyst and venue manager each get their own scope; a manager's view is their venue, not the group's books.
This can go on the pass, not just in the office.
Last night, by shift
City Center| shift | revenue | covers | avg. check | voids | vs its own normal |
|---|---|---|---|---|---|
| Lunch11:00–16:00 | 1 640 € | 118 | 13.90 € | 4 | +3% |
| Evening16:00–22:00 | 2 380 € | 143 | 16.64 € | 11 | −9% |
| Late22:00–00:00 | 440 € | 24 | 18.33 € | 2 | +1% |
compared with this venue's own normal for the same weekday and shift, not with the group average
Where the line is
What marql will not do in your kitchen.
A group runs on the till, the supplier and the rota it already has. The useful version of this product sits on top of them and is plain about what it cannot see.
- Read-only by default. marql does not change a price, a menu item or a stock level in your POS.
- It is not a recipe or tech-card system. Food cost is tracked at venue, category and supplier level; the copilot can price a basket of ingredients from stock and recent prices, which is not per-dish costing from a technological card.
- Labour needs a source. Prime cost includes labour only where payroll lines are in the ledger, and sales per hour worked only where staff hours are recorded — otherwise the number stays food cost and says so.
- Comparison is against your own venues and your own history. External industry benchmarks for prime cost, food cost and labour ratios are documented as a next step and are not built.
- A few tills — Toast, Fudo, Toteat and Lightspeed among them — connect at account level today, with a seven-day history window, so for those systems per-venue history starts when you connect.
- The Decision Inbox and the Impact Ledger are in beta and labelled as such inside the product.
HoReCa FAQ
What operators pin down before they connect a venue.
iiko, Poster, r_keeper, the 1C and ecorg tills, and Square, each per venue. Toast, Fudo, Toteat and Lightspeed connect at account level with a seven-day history window. Anything else with a REST API or a scheduled CSV export is mapped without custom code — 150 connectors are live today across POS, accounting, delivery, e-commerce, payments and invoicing.
Not from a technological card — marql is not a recipe system and will not pretend to be one. Food cost is tracked per venue, per category and per supplier from the till and the purchase invoices, and prime cost puts it next to labour. The copilot can price a basket of ingredients from what is in stock and what it recently cost, which answers "what would this dish cost me today" without claiming to be your tech cards.
Yes, where the platform reports it. Glovo, Bolt Food, Wolt, Tazz, Uber Eats, Deliveroo, Just Eat, Foodpanda and Deliverect are connectors, and orders and commissions land alongside the till so a channel can be read after the fee rather than before it. Labour is never split by channel, so a channel line stops at contribution, not profit.
Payroll or staff-cost lines in whatever ledger you already keep — that is what prime cost reads. If you also record staff hours, sales per hour worked becomes available and can be compared between comparable venues. Without either, the venue keeps its food cost and the page tells you the rest is missing instead of quietly halving your costs.
It is the normal case. Products, categories, VAT rates and currencies are mapped into one model, so two spellings of the same dish are one item and two countries are rows in one table. Mixed estates are the first-day scenario, not the exception.
Yes. Access is by role: the owner sees everything including billing, a COO everything except billing, an analyst has read-only access to the whole picture, and a venue manager sees their own venue. It is configured once, not per report.
Per venue, on a graduated ladder: €200 a month for each of the first nine, €185 for venues 10 to 29 and €160 for 30 to 49. Each rate applies only to the venues inside its band, so six venues are €1,200 a month. From 50 we map the stack first and then quote. The calculator is on /pricing.
Talk to us
Tell us about your business. We'll call you.
Tell us a bit about your business and your data sources. We'll tailor the walkthrough, then you pick a time that works for you.