A bakery that opens a second, then a fifth shop changes business without always noticing. The founder’s bakehouse becomes a central production lab, the shop counters become internal customers, and the question is no longer “how many loaves this morning” but “how many of each product, for which shop, at what delivery time, with what use-by date.” That is the point where the spreadsheet, the production notebook and the stand-alone till stop being enough.
This article is written for owners and finance directors of bakery-pastry chains, central bakehouses and industrial caterers at SME or mid-market scale. It explains what a bakery ERP must really do, in what order to roll it out, and how to choose between a food-industry ERP, a vertical bakery solution and an adapted general-purpose ERP.
What makes the trade different: daily production, fresh goods, thin margins, strong seasonality
Four characteristics drive the requirements, and none of them is well served by a generic manufacturing ERP.
Daily production with no buffer stock. Most products (bread, viennoiserie, sandwiches, fresh pastries) are made the same day or the day before for the next morning. The production plan is not a monthly exercise: it is a 24-hour cycle in which oven times, cooling times and van loading times are hard constraints.
Fresh products with short lives. A baguette sold the same day, a cream pastry with a few days of shelf life and a raw frozen croissant follow different expiry rules. The ERP must handle several shelf-life regimes on a single item master.
Thin margins, highly sensitive to input costs. Flour, butter, eggs, chocolate and baking energy weigh heavily in product cost, and their prices move. A “theoretical” margin computed once a year on a frozen material price says nothing about the real profitability of a product in November.
Strong, layered seasonality. Christmas logs, Easter, back-to-school, summer holidays: each peak disrupts volumes, recipes, staff rotas and oven capacity. On top of that comes weekly seasonality (Sunday morning looks nothing like Tuesday afternoon) and location seasonality (railway station, city centre, office district, tourist site).
These four factors explain why projects that fail are often those treated as an ERP for trading finished goods. Here, the core of the system is sales forecasting by outlet, tied to a planned production run.
Planning production from outlet-level sales forecasts
The principle: from the counter back to the lab
The logic is the reverse of a classic factory. You do not produce to replenish stock; you produce to serve a sales forecast by shop and by time slot. The flow runs like this:
- Each outlet submits (or receives) a sales forecast by product for the next day, derived from till history.
- The ERP adjusts the forecast for calendar and environmental factors: day of the week, public holidays and bridge days, school holidays, local events, weather.
- The shop manager confirms or corrects it, taking the previous day’s unsold goods into account.
- The ERP consolidates the needs of all shops and generates the lab production plan: quantities to make, production orders, oven and proofing-chamber schedules.
- It derives the raw material requirements and proposes supplier orders.
What the forecast must include
- History by outlet and by product, never only at chain level: a railway station and a residential neighbourhood do not buy the same things.
- The calendar: public holidays, bridge days, the eve of festivals. A Wednesday that is also a public holiday does not behave like an ordinary Wednesday.
- Weather: it affects some categories (ice cream, sandwiches, tarts, drinks). It is better handled as a guided manual adjustment than by an opaque algorithm. An advanced forecasting module is only useful if it can be explained to shop managers.
- Previous-day stock-outs: a product sold out at 3 pm has real demand above recorded sales. The ERP must be able to tell sales from demand.
- Firm orders: catering, meetings, party orders, which add to the counter forecast.
A fictional worked example
Purely illustrative example, unrelated to any real company.
Take a fictional chain of 6 outlets supplied by one central lab. For the same product (a butter croissant), the raw forecast for tomorrow is 120 pieces for the station shop and 60 for the residential shop. Tomorrow is a bridge day: the model lowers the station forecast by 25%, to 90 pieces, and raises the residential one by 10%, to 66. The lab therefore plans 156 croissants for these two sites instead of 180, which is 24 fewer pieces to make, and its oven load drops accordingly. If the residential shop manager knows a local market has been cancelled, they correct the figure by hand, and the correction is logged so the rule can be refined later.
The point of the example is not the numbers but the mechanism: an explicit rule, a visible adjustment, a traced correction.
Detailed lab scheduling
Beyond volume, the ERP (or its planning module) must handle capacity constraints: number of ovens, proofing windows, dough resting times, night-shift labour, and a production sequence that avoids cross-contamination between allergen products. Many labs gain more from sequencing bakes properly (from mildest to most strongly flavoured, from allergen-free to tree nuts) than from refining the forecast.
Recipes, specifications, allergens and labelling
The recipe specification, pivot of the system
The recipe specification (or recipe bill of materials) links three dimensions that the ERP must use at once:
- Production: ingredients, quantities, yields, baking losses, proofing times.
- Cost: material prices, energy, labour, packaging.
- Consumer information: allergens, composition, nutrition values where required.
Practical points to watch:
- Yield and production losses: a 10 kg dough recipe does not give 10 kg of baked product. The ERP must manage loss coefficients (evaporation, trimmings, rejects) rather than bury them in cost.
- Semi-finished goods: raw dough, pastry cream and tart bases are items in their own right, with their own shelf life. A multi-level bill of materials is essential.
- Variants and substitutions: a butter supplier changes, an alternative flour is used during a shortage. Each substitution must carry through its allergen and cost impact.
- Versioning: every recipe change is dated and approved, so you can retrieve what was sold on a given date in case of a complaint.
Allergens and labelling
The EU Food Information to Consumers Regulation (EU) No 1169/2011 requires the substances causing allergies or intolerances listed in its Annex II to be indicated, and provides that allergen information must also be available for non-prepacked food. Under it, 14 allergens are covered. In the UK, the rules for food prepacked for direct sale (so-called Natasha’s Law, in force since October 2021) go further by requiring a full ingredient list with allergens emphasised on such products. Check the exact obligations that apply in each country where you trade, as national rules vary.
For a bakery-pastry business this is a daily issue: the counter changes every day, and one loaf can contain gluten, sesame seeds or traces of tree nuts. The ERP brings three things:
- Automatic allergen calculation for a finished product from its bill of materials, including semi-finished goods. A recipe change updates the information without rekeying.
- Label and shelf-card printing by outlet, in a controlled format with the date of last update.
- Cross-contamination risk management: marking of shared lines and ovens, and cleaning plans between runs.
The critical point is data freshness. A record that is current in the ERP but an outdated card on the counter is a real risk. The process must force the printing of new displays whenever a recipe changes.
Shelf life, traceability and reducing waste and unsold goods
Use-by, best-before and batch traceability
Two notions are often confused: the use-by date (mandatory for highly perishable foods) and the best-before date (minimum durability). In bakery-pastry, use-by dates mainly concern products made with cream, eggs or meat (sandwiches, quiches, fresh desserts), while the day’s bread is sold the same day and some viennoiserie or biscuits carry a best-before date.
For each batch produced, the ERP must:
- calculate the date according to the item’s own rule (production day plus shelf life, or end of day);
- link the finished-goods batch to the raw material batches used (flour, eggs, butter, cream, fillings);
- follow the batch through to the outlets delivered;
- allow a forward and backward trace in minutes when an alert occurs: which material batch went into which products, delivered to which shops.
To go further on traceability and FEFO logic (first expired, first out), see our guide to ERP for cold chain, HACCP and temperature monitoring and our food industry ERP guide to traceability, batch management and HACCP.
Reducing waste and unsold goods
Losses come from three places, and the ERP must separate them, otherwise no action is targeted:
- Production losses: rejects, baking losses, non-conforming products, measured at the lab.
- Transport and delivery losses: damaged goods, loading errors.
- Unsold goods in outlets: counter losses, entered at close of day by product and by reason (unsold, breakage, return, donation).
The levers are well known: refine the forecast (see above), stagger bakes through the day instead of making everything in the morning, apply end-of-day markdowns driven by the ERP, direct surpluses to donation or reprocessing (bread pudding, breadcrumbs, reused desserts within hygiene rules), and measure waste in value and as a percentage of product made, shop by shop.
Regulatory context: food waste rules
Food waste is increasingly regulated in Europe. France, for instance, has its anti-waste law for a circular economy of 10 February 2020, which sets waste-reduction objectives for food distribution and catering and extends donation obligations to other players. At EU level, food waste reduction targets are part of the revised waste framework. Obligations depend on company size and activity (sales area, turnover, number of meals): a bakery chain or industrial caterer should check with its national authority and trade federation whether it falls within scope. In every case, an ERP that records unsold goods by reason and by shop provides the evidence to demonstrate the actions taken, whether mandatory or voluntary.
POS links, inter-site deliveries and margin by product
POS integration, the source of truth for demand
The till is the most valuable data source: it gives sales by product, by hour and by shop. Three levels of integration exist:
- Daily sales upload (file or API): the minimum to feed the forecast and the accounts.
- Real-time or per-slot upload: allows intra-day adjustments (re-bake a batch, trigger a markdown).
- Two-way flow: the ERP pushes items, prices, allergens and promotions to the till, and retrieves sales, returns and takings.
POS vendors in the sector are numerous and more or less open. Before signing, check the documented integration method (public API, existing connector, standard export) rather than trusting a sales promise. Also ask for a demonstration on a day of real data. Our guide to omnichannel retail ERP and real-time inventory describes till-to-ERP architectures in multi-store environments.
On the accounting side, the breakdown of takings (cash, cards, meal vouchers) and VAT by rate (takeaway versus eat-in) must flow cleanly, by outlet and by day, into management accounting.
Inter-site deliveries
The central lab supplies the outlets in rounds. The ERP must handle:
- delivery notes by shop, generated from the production plan, with batches and use-by dates;
- slots and rounds (several shops per van, delivery cut-off before opening);
- controlled goods receipt in the shop: quantity discrepancies and rejected goods, recorded the same morning;
- transfers between shops to rebalance a surplus before close of day.
Internal flows are valued at an internal transfer price, which makes it possible to measure lab and shop performance separately.
Margin by product: the calculation that actually matters
Useful margin is calculated by product, by shop and by period, not as a chain average. A product’s cost is made up of:
- raw materials, valued at last purchase price or weighted average cost, with frequent revision for volatile inputs (butter, cocoa, flour, eggs);
- baking and refrigeration energy, allocated to the product by oven or chamber time. This item has become significant and must be attached to production orders, for example pro rata to oven hours used, otherwise it disappears into overheads;
- lab labour, at standard time;
- losses (production, transport, unsold), charged to the product that generated them;
- packaging and delivery logistics.
When the price of butter rises, the ERP must answer three questions within minutes: which products see their margin fall below threshold, which recipes are affected, and which price or recipe adjustment is feasible. That is what separates an ERP that records from an ERP that steers.
Choosing: food-industry ERP, vertical solution or adapted Odoo/Business Central
Three families of solutions are on offer. The vendors mentioned are examples of categories; their scope changes and should be checked on their official websites.
- Food-industry ERP (the family of process-industry ERPs, such as those compared in our food and beverage ERP guide for SMEs, currently available in French): strong on batch traceability, recipe and yield management, and compliance. Heavier, suited when the lab is the centre of gravity.
- Vertical bakery-pastry or food-craft solution: already covers shop ordering, recipes and often the till. Quick to implement, but depth varies on accounting, multi-company consolidation and openness of interfaces.
- Adapted general-purpose ERP (Odoo, Dynamics 365 Business Central or equivalent, with manufacturing modules and industry extensions): flexible, good on finance and multi-site, but requires an integrator who understands the trade. The risk is building costly custom code for shelf life, yields and allergens.
Recommendation by size
| Profile | Main need | Recommended direction |
|---|---|---|
| A few outlets, one bakehouse | Simplicity, till, internal orders | Vertical food-craft solution, integrated with the till |
| Regional chain, central lab, 5 to 20 outlets | Planning, shelf life, margin by product, accounting | Advanced vertical solution or adapted general-purpose ERP with industry extension |
| Mid-market, several labs, industrial caterer, customer audits | Full traceability, certification, consolidation | Food-industry ERP with till and accounting interfaces |
The thresholds shown are orientation guides, not sourced figures: the right choice depends first on the complexity of the lab and the level of traceability your customers demand, before the number of shops.
Questions to ask any vendor
- How is the use-by date calculated, and for which item types?
- Can the forward and backward batch trace be demonstrated live, on a simulated recall?
- Are allergens recalculated automatically when a recipe changes?
- What is the documented integration method with our till and our accounting system?
- How do energy and volatile materials enter product cost?
A four-phase rollout plan and common mistakes
The four phases
Phase 1: scoping and master data (1 to 2 months). Inventory of products, clean-up of the item master, entry of specifications for the main products, definition of shelf-life rules, mapping of lab-to-shop flows. Choice of pilot scope.
Phase 2: lab and traceability. Go-live of production orders, batch management, raw material receipts and labels. The lab goes first because it is the most critical and the most exposed to audits.
Phase 3: outlets, till and deliveries. Connection of the till, delivery notes, goods receipt in shops, entry of losses by reason. Shop-by-shop rollout, starting with a representative pilot.
Phase 4: forecasting, margin and steering. Once sales and loss data are reliable, activate outlet-level forecasting, up-to-date product costing and margin dashboards. This is not the first phase: a forecast built on incomplete till data produces bad decisions with great confidence.
Common mistakes
- Starting with the forecast before having a reliable item master and till.
- Neglecting loss entry in shops: if it takes too long at close of day, it will be rushed. Design entry to take a few taps.
- Underestimating till integration, discovered late in the project as a workstream in its own right.
- Freezing product cost without revising material and energy prices.
- Forgetting change management in the bakehouse: night teams adopt a tool that saves them time, not a tool that polices them.
- Choosing a tool too heavy for the size of the business, or too light for its traceability requirements.
To frame your selection, download our ERP evaluation grid and adapt the criteria to the issues in your lab (shelf life, allergens, till). To keep reading, see also our food and beverage ERP comparison for SMEs and our guide to formulation and traceability ERPs in cosmetics, whose recipe and batch logic is close to that of a pastry lab (both currently in French).
