One central plant, two markets: how a bakery chain keeps recipes and Dynamics 365 in sync

A Croissant Crosses a Border Every Morning

Every morning, vans loaded with viennoiserie, sandwich bread and cakes leave a manufacturing plant and cross a land border into a neighbouring market before the first customer walks into a store. The group behind this route is not unusual: a regional bakery and café brand with its own retail network, running the operating model common to chains that grew out of one country and expanded into a neighbouring one where real estate and labour costs make local baking harder to scale. One country manufactures; the other mostly sells.

That model works commercially. Operationally, it creates a problem that shows up quietly, months after the first truck crosses the border: the plant runs on recipes, and the group runs on Microsoft Dynamics 365. For a long time, those two systems did not agree with each other.

What Dynamics 365 knows, and what it doesn’t

Dynamics 365 is exactly what a food manufacturer needs for the things an ERP is built for: purchase orders to flour and butter suppliers, goods-received notes at the plant’s dock, intercompany invoicing between the manufacturing entity and the retail entity across the border, inventory valuation, and financial consolidation at group level. None of that is in question — the plant’s finance team runs Dynamics 365 well.

What Dynamics 365 does not know is what happens inside the mixer. It records that the plant bought 800 kilograms of butter at a given price. It does not know how much butter goes into a single croissant, what the yield is after proofing and baking, what the allergen declaration should say once that butter meets wheat flour and eggs, or how a formulation change for the neighbouring market — a lower sugar level to hit a better front-of-pack nutrition rating, for instance — changes the cost per unit. That gap between what finance sees and what the plant produces is exactly where two problems appear at once: cost drift that finance only notices at month-end, and allergen or nutrition labels that lag behind the actual recipe.

A recipe layer between the oven and the ledger

The fix is not to ask Dynamics 365 to become a bakery system — it was never built for that, and forcing it produces exactly the kind of workaround that erodes an ERP’s data integrity. The fix is to give the plant a recipe and production layer that speaks the plant’s language — formulations, yields, sub-recipes, batch sizes — and reconciles automatically with Dynamics 365’s language of purchase orders and stock movements.

In practice, that means the reference formulation for every product — the master recipe with its ingredients, baker’s percentages and process steps — lives in one place, shared across both markets. When a baker at the plant adjusts a recipe (a different fat blend, a reformulated filling), the system recalculates, in the same move: the allergen declaration, the nutritional values needed for the neighbouring market’s labelling requirements, and the real cost per unit based on ingredient prices already flowing in from Dynamics 365 purchase data. That costed output — the standard cost of a finished product — is what feeds back into Dynamics 365 as the basis for inventory valuation and intercompany transfer pricing, instead of a manually maintained estimate that quietly goes stale the moment a supplier changes its price.

Compliance travels with the recipe, not behind it

For a plant shipping into a second market, this matters twice over. Two neighbouring markets rarely share identical labelling and food-safety requirements, and a recipe change made for one of them — reducing sugar to improve a pastry’s front-of-pack nutrition rating, for example — has to be reflected everywhere the recipe is used: the label printed at the plant, the nutritional panel shown at point of sale, and the traceability record that ties a finished batch back to specific ingredient lots for both markets’ regulators.

Without a single recipe source of truth, this is exactly where things drift: the plant updates the formulation, but the label template, the point-of-sale nutrition data and the ERP’s cost record update on three different schedules, if at all. With production, labelling and costing reading from the same recipe, a single change propagates everywhere it needs to, the same day it is made.

Finance sees the plant, not just the invoice

The commercial upside is less about the software and more about what it makes visible. When the group’s finance team can see real, current cost per unit — not a rough allocation — for every product crossing the border, questions that used to take a month to answer become immediate: is a product still profitable after a supplier price increase? Does the intercompany transfer price between the plant and the stores across the border still reflect actual production cost? Which product line is quietly eating margin because its formulation changed months ago and nobody recalculated the standard cost?

This is the same principle that applies to any group running several sites from a central kitchen or plant: the ERP keeps its role as the system of record for money — purchasing, payments, consolidation — and a dedicated recipe and production system becomes the system of record for what the plant actually makes. Dynamics 365 and the recipe layer agree with each other instead of one silently drifting away from the other.

Ready to connect your plant?

If your group manufactures in one market and sells in another — or runs several plants feeding several countries — the same pattern applies regardless of which ERP sits at the centre. CalcMenu is built to sit alongside Dynamics 365 or any other ERP, never in its place, so your recipes, your costs and your compliance data stay in sync with the system your finance team already trusts.

Book a 15-minute call with Marc at https://calendly.com/marceng/15-min-call-calcmenu-marc to see how a connected recipe layer would work for your plant.