Labour
Labour in CostingBrik is the hands-on time a recipe takes, costed at your hourly rate. It sits beside your gross profit, never inside it.
That distinction is the whole point. Gross profit is after ingredient and consumable cost and before labour, which is the standard your accountant, your landlord and every industry benchmark uses. Putting prep time inside food cost makes your GP% look far worse than it is and stops you comparing your menu with anyone else's. So Brikly costs labour on its own and shows it next door, along with a contribution after labour figure that tells you what is genuinely left per portion.
If you have been costing staff time as an ingredient or a consumable, nothing about your real costs changes when you move it into Labour. Your gross profit goes up, and a new after-labour figure appears beside it showing exactly what you saw before.
Setting your hourly rate
Go to CostingBrik > Settings > Labour.
- Owners and admins set and change the rate, and can remove superseded rates from the history. The rate in force cannot be removed: change it instead.
- Members and viewers see the rate but no controls. Where no rate is set they see "No labour rate set. Ask an owner or admin to set one."
Click Set rate, enter an hourly figure and choose a start date. One rate covers the whole account in this version: you do not set a rate per recipe or per person.
The rate is a ledger, not a single field. When you change it, the old row is closed and the new one starts on the date you pick. Past rates stay in the ledger for audit, and your recipes keep the labour figures they were last costed at until they are recalculated. Any recalculation uses the rate in force that day. Past rates are listed under the current one, and you can schedule a rise for a future date.
Base wage or true cost?
The wage you pay is not what an hour of work costs you. Employer National Insurance, pension contributions and holiday pay all sit on top, and how much they add depends on how many hours a week the person works.
When you enter a rate the modal shows a true cost calculator with three bands:
| Band | Hours per week |
|---|---|
| Casual, 1 to 2 days | 10 |
| Part-time | 20 |
| Full-time | 37.5 |
Each band shows what that base wage really costs per working hour. The figures include employer NI (category A), 3 percent pension and 5.6 weeks holiday at 2025/26 thresholds. Pick the band that best matches your kitchen team and Brikly stores the loaded figure.
If you have already saved a base wage, the Labour settings section says so, for example "This rate looks like a base rate. The true cost per working hour is between £16.50 and £17.98 depending on hours." Choose a band and click Use true cost to write the loaded rate in one step.
The calculator is an estimate built from one rate and one hours band. If you want the real cost of each employee, set your team up in StaffBrik.
Adding time to a recipe
Open a recipe in the builder and find the Labour section, below Consumables.
- Click Add labour.
- Name the step (for example "Prep", "Bake", "Portion").
- Enter the time.
- Choose per batch or per portion.
The Per selector only appears when the recipe yields more than one portion, because at a yield of one the two are the same number. Underneath each row Brikly shows what your entry means the other way round, so you can never mix the two up by accident:
30 min per batch of 28 is about 1 min per portion.
A min / hr toggle sits on each row. Flip it once and it stays flipped for you across every recipe, so a kitchen that thinks in hours can type 0.5 instead of 30. Minutes are what gets stored either way.
Up to eight labour lines per recipe. Past that Brikly says "Eight labour lines is the limit. Combine steps that share a rate."
No labour needed
Some things you buy in and serve as they are. Click No labour needed and the recipe records an explicit zero rather than an empty gap, which is how Brikly tells "no prep time" apart from "nobody has entered this yet". Click Undo to reverse it.
Time entered with no rate
If you add time before setting a rate, the minutes are kept and the money reads No rate set rather than £0.00, with a Labour incomplete chip on the card. Nothing is silently costed at zero. The sample cafe data Brikly can load for you behaves the same way: its labour line reads "No rate set" until you set a rate of your own.
Moving labour out of consumables
If you have been recording staff time as a consumable (a "1 HR Labour" item, or anything named for hours, wages or prep time), Brikly spots it on the recipe and shows a banner:
This looks like labour. Move it to the Labour section so your gross profit stays before labour.
Click Move to labour and Brikly reads the consumable quantity as hours, converts it to whole minutes, adds it as a Prep line per batch and removes the consumable row. A quantity of 0.1 becomes 6 minutes. Check the result before you save: if you were counting the quantity as something other than hours, edit the minutes.
The same banner appears on the review step after an AI recipe extraction, so a scanned recipe does not recreate the workaround.
Where labour shows up
| Surface | What you see |
|---|---|
| Recipe detail, Labour per Portion card | The money, plus {n} min at £14.00/hr. Where a recipe uses components, a Direct £1.40 · From components £0.71 line splits the two |
| Recipe detail, Cost per Portion after Labour | Ingredients, consumables and labour together |
| Recipe detail, Contribution after Labour | What is left per portion once labour is paid |
| GP % card | A muted After labour: 39.2% line underneath, so the honest figure is never separated from the headline one |
| Total Recipe Cost breakdown | A greyed Labour (not in gross profit) line, which adds nothing to the card total on purpose |
| Recipe list | Two optional columns, Labour / portion and After labour. Both are off by default: turn them on in the column picker. After labour is offered on Menu Items only, because a base recipe has no selling price to net off, while Labour / portion stays available on Base Recipes. Neither column shows on mobile |
| Recipe Profitability report | Labour / Portion and Contribution After Labour columns, both included in the CSV export |
| Version history | A Labour table with a Step column in any snapshot that recorded the recipe's own labour steps, so a recipe whose labour is entirely inherited from its components shows no table. A Labour moved entry marks where lines were migrated out of consumables |
| Recipe card (chef card) | A Hands-on column with the minutes for one batch, from the recipe's own labour steps only. No money reaches the kitchen |
Everything else stays where it was. Your cost per portion, gross profit and GP% are unchanged by adding labour.
Labour and sub-recipes
A component's labour rolls up into its parent as labour, never as ingredient cost. If your cheese sauce takes 30 minutes per batch of 16, a dish using one portion of it carries 1/16th of that time and that money in its own labour figure, not in its food cost.
That is what the Direct ... From components ... line on the Labour per Portion card is telling you: how much of a dish's prep time is its own final assembly and how much was already done upstream. See Sub-recipes.
Labour and takeaway
Labour has no dining scope. A dish takes the same hands-on time whether it is eaten in or taken away, so there is one labour figure and it applies to both. Only ingredients and consumables split dine-in from to-go. See Dine-in vs To-Go Costing.
Labour in what-if scenarios
The what-if simulator models ingredient cost. Labour is held constant in every scenario, and the results say so. If you want to see the effect of a rate change, change the rate in Settings and use Update N recipes now.
Labour in MenuBrik
Once a recipe carries labour, MenuBrik can see how much hands-on time each menu item takes and factors it into the kitchen load badge:
| Hands-on time per portion | Kitchen load |
|---|---|
| Under 4 minutes | Simple |
| 4 minutes or more | Moderate |
| 8 minutes or more | Complex |
Hands-on time is one input among several: a recipe with many components or lots of sub-recipes can read as complex on structure alone. This is new visibility, not a new cost. Nothing about the item's price or margin changes.
Changing your rate later
When you save a new rate, existing recipes keep the figures they were last costed at until they are recalculated. Brikly counts them for you and says "12 recipes still use the old rate", with an Update 12 recipes now button that re-costs them in the background. For a first rate the wording is "12 recipes are not costed at this rate yet."
If you schedule a rise for a future date, the message says when it takes effect instead of offering a count. The recount runs against whichever rate is in force on the day.
Re-costing at a new rate moves your labour and after-labour figures only. Cost per portion, gross profit and GP% are calculated before labour and stay exactly where they were.