One recipe, thousands of labels: keeping an ERP, CalcMenu, and ingredient declarations in sync

An order-driven production floor, not a fixed menu

A contract food manufacturer — a bakery producing store-brand pastries, a sandwich factory supplying retail and foodservice accounts, a ready-meal producer running for several private labels — doesn’t work from a fixed weekly menu the way a restaurant does. Production is driven by what customers actually ordered that day, and those orders typically land through an ERP — often something like Oracle — which owns purchase orders, order lines, and quantities. What gets made on the line tomorrow morning is whatever the ERP says was ordered, not what was planned last month.

That creates a specific integration problem most restaurant-facing recipe software never has to solve. A recipe management system like CalcMenu owns the food itself — the recipe, its costing, its nutrition, its allergens. A label system like BlazeIQ Labels owns what actually prints and goes on the pack. None of the three is wrong to own what it owns. The problem is that nobody, by default, owns the daily handoff between them — and without it, someone ends up re-typing today’s order quantities into the label system by hand, at exactly the moment of day when a mistake is most likely and least likely to be caught.

What has to travel from the ERP to the label — and why QUID is the hard part

The mechanical flow is simple to describe: an order line comes in from the ERP, CalcMenu resolves it to a recipe, and that recipe gets scaled to the batch quantity actually being produced that run — not a fixed reference yield from months ago. From there, three kinds of declaration data have to reach the label, correctly, every time:

The full ingredient list. Not just “what’s in it,” but QUID — the quantitative ingredient declaration that EU and Swiss food law requires for any ingredient that’s named or emphasized on the pack (the “Chicken (30%)” on a chicken sandwich label is a QUID declaration). QUID isn’t a fixed number per recipe; it has to be recalculated against whatever quantities actually went into that specific batch, which is exactly why a static, pre-printed label doesn’t work at order-driven volumes — the percentage genuinely can move from batch to batch, run to run.

Allergens. Because the recipe database is the single source of truth for what’s actually in a formulation, allergen data doesn’t need separate re-entry per SKU, per production run, or per market — it’s derived from the same recipe record that drove the QUID calculation a moment earlier.

The language. A contract manufacturer supplying accounts across more than one market needs the same recipe to produce labels in whichever language that market requires — French one week, German the next, without a separate translation pass per label, per SKU, per language. That only works if the ingredient names and allergen terms live as structured data on the recipe, not as free text someone writes into a label template by hand.

Why this only works if it’s built to be extended

This kind of pipeline runs unattended, early in the morning, against whatever volume the ERP handed over that day — which means it has to survive a lot of variation that a one-time export never has to face. Order volumes swing day to day. New recipe variants get added for new accounts. A discontinued product needs to stop generating labels without someone remembering to switch it off by hand. Printer and label-format changes happen on their own schedule, independent of the recipe side. An interface built as a single rigid script breaks at the first of these; one built with a clear mapping layer between the ERP’s order data and CalcMenu’s recipe data absorbs each change as a small, scoped update instead of a re-negotiated project.

The advantage, concretely

Done well, this removes a specific, recurring risk rather than adding a feature for its own sake:

1. No re-keying of ingredient or allergen data, per SKU, per production run, or per market — it exists once, on the recipe, and reaches the label automatically.
2. QUID percentages are recalculated against the batch actually produced, not a static reference recipe that quietly drifts out of date the first time a supplier’s specification changes.
3. Multi-language labels ship from one recipe record, not a separate translation project every time a new market comes online.
4. The pipeline survives daily volume swings and new recipe variants because it’s built to run unattended against whatever the ERP sends, not re-run by hand every time something changes upstream.

This isn’t hypothetical — it’s the shape of a pipeline we run daily for a contract sandwich manufacturer supplying retail and foodservice accounts.

This pattern isn’t specific to sandwiches — any contract manufacturer producing to order against retail or foodservice accounts hits the same fragmentation risk the moment an ERP, a recipe system, and a label printer all need to agree on the same facts, every single day. It’s a close cousin of the ERP/POS/CalcMenu pattern we describe for multi-outlet hospitality operations — same underlying problem, different systems on the other end. See our food manufacturer page for how this applies to recipe-driven manufacturing more broadly, and BlazeIQ Labels for the label side of the pipeline itself.

---

Running production against a daily stream of ERP orders, and tired of ingredient lists that don’t quite match what’s actually on the line today? Book a 15-minute call: Schedule here.

Explore CalcMenu's recipe management software for food manufacturers to see how it applies to your kitchen.