ERP for food manufacturers: what matters for allergens and batches

The right ERP system for a food manufacturer is one that carries batch traceability in both directions, allergen management under the FIC Regulation, recipe versioning with history and FEFO logic as standard – not as customisation. Three system classes meet this in different ways. An industry ERP for food brings recipe, batch, allergen and best-before date as master data and is the shortest route to audit readiness; the price is a smaller vendor and partner market. A standard ERP with an industry add-on combines a broad base system with a partner's industry logic; the price is two release cycles and dependence on that one partner. A generalist ERP with no industry focus leaves the most freedom, but shifts the batch chain, allergen inheritance and FEFO into custom development. Which class works is decided by four numbers: how many recipes you run, how often they change, how many sites share master data, and your certification profile (IFS, BRCGS, organic, hay milk). A plant with twenty stable recipes and one site needs a different system from a dairy with 180 suppliers, a maturing store and three sales channels. A ranking without these four numbers isn't a recommendation; it's advertising.

The Food Information to Consumers Regulation (EU) No 1169/2011 requires the 14 allergens that must be declared to be shown correctly on every label – for every batch that leaves the plant, and in the form in which they are actually present. The regulation doesn't prescribe an ERP, but it defines what the system must do for the label to be right. First, allergens are maintained on the raw material, not on the finished item. If a raw material's supplier changes and the new supplier brings a trace of celery, that information has to arrive on the raw material. Second, allergens are passed down through the recipe to the finished product – every ingredient carries its allergens into the product, including intermediates across several recipe levels. Third, with every recipe change the allergen declaration is re-derived and the label template versioned accordingly. A free-text "allergens" field on the item meets none of these three requirements, because it never registers a change of raw material or recipe. It is correct on the day it is entered and goes quietly out of date. To emphasise allergens in the ingredients list under Article 21 and to handle "may contain" statements, the system also needs to distinguish between an ingredient and possible cross-contact from the production line.

Not by law – but depending on your certification, yes. Article 18 of Regulation (EC) No 178/2002 requires traceability one step forward and one step back: you must be able to show who supplied a raw material and to whom you delivered a product. That is the minimum, and a delivery note in a binder formally meets it. Private standards go further. IFS Food and BRCGS require batch-level traceability across all stages with a mass balance, and a traceability test that must be completed within four hours at most. Organic schemes and regional origin schemes such as hay milk require an unbroken chain back to the agricultural producer, because certification depends on origin, not on the processor. If you hold or are aiming for one of these schemes, you need the chain back to the farmer in the system – with supplier batch, goods-receipt date, mass balance and a link to the production batch. If you only have to meet the law and aren't pursuing certification, you don't need it and shouldn't pay for it: full genealogy costs maintenance effort at every goods receipt. So this isn't an ERP question; it's a question about your certification profile over the next five years.

IFS Food and BRCGS Food Safety don't name ERP functions, but they require records that can't be kept without certain functions. First, batch traceability with mass balance: for every finished batch it must be clear which raw-material batches went in and in what quantity, and for every raw-material batch, which finished batches it went into. That calls for batch genealogy that handles partial and mixed batches. Second, recipe and specification management with version history: for every batch, the recipe and specification valid at the time of production must be retrievable, even years later. Third, blocking and release logic: goods in quarantine, maturing, or with an open lab result must not be picked – the system has to know and enforce the status, not just display it. Fourth, supplier approval with certificate management, because both standards tie supplier approval to valid certificates. Fifth, allergen management as described under the FIC Regulation, extended to cross-contamination across production lines. Sixth, documentation of corrective actions linked to the batch. A system that covers these six points only through Excel attachments or free text may pass the audit – but every year with the same manual effort.

Maturing goods and blocked stock need their own stock status in the ERP, not their own warehouse. The difference is fundamental. A dummy warehouse called "maturing" only pretends to solve it: the goods are physically there, but the system doesn't know when they become saleable, can't pick them by degree of maturity, and values them in current assets like finished stock. Planning sees 40 tonnes of cheese but can only deliver 12 of them. The correct approach is a status "maturing" with a release date per batch, derived from production date and recipe – and adjustable when the lab result or sensory testing requires it. The quantity available to planning is then the stock whose release date falls on or before the delivery date. The same principle applies to blocked stock: a status "blocked" with a reason (open lab result, complaint, recall) and a person responsible for release. The system has to enforce that status: a blocked batch must not be picked, transferred or booked into a follow-on recipe. For matured products there is also valuation – maturing losses through weight loss must be bookable as a partial issue, otherwise the mass balance won't match in the audit. A system that only knows "available" and "reserved" can't do any of this.

A recall is decided in hours, and in that time the system has to answer three questions: Which raw-material batches are in the affected finished batch? Which other finished batches did the same raw-material batches go into? And to which customers were all these finished batches delivered, in what quantity, on what day? IFS allows four hours for the traceability test; in practice, retailers expect the answer sooner. That requires a data model with unbroken batch genealogy across all stages – goods receipt, intermediate, finished goods, repacking, picking, delivery – with no break where a batch was split or merged with another. That is exactly where the chain breaks in many systems: the sub-batch gets a new number, and the link to the original batch survives only on a piece of paper. The system must also store the delivery with its batch at line level, not just at document level, and be able to output customer contacts for the recall directly from the delivery history. What the system doesn't have to do is run the recall itself. Crisis communication, notifying the authorities and deciding the scope stay with people. The system has to deliver the data – complete, in minutes, without Excel.

Often, yes – and in many cases it is the more economical route. A standard ERP with an industry add-on is enough if the add-on carries the four core requirements as standard and the partner keeps it up to date with every release of the base system. For a business with one site, a few dozen stable recipes and a certification profile without a full chain of origin, it is often the right choice: the broad base system brings finance, staff available on the market and a large ecosystem, while the add-on brings the industry logic. In that situation we wouldn't recommend a specialised industry ERP just because it "does more" – the extra depth goes unused but costs switching risk and a smaller partner market. The price of the add-on sits in three places: two release cycles that can drift apart; dependence on that one partner, because nobody else maintains the add-on; and industry depth that varies widely between partners. That is why you test the add-on's depth against your own recipes – with a real multi-level recipe, a recipe change involving an allergen switch, and a batch split – not in the partner's demo. If you change many recipes frequently or run maturing stores with valuation, you are more likely to hit the add-on's limits.

For most mid-sized food businesses this question matters less than it seems in vendor meetings – the industry logic decides, not the deployment model. Three points are still industry-specific. First, proximity to production: scales, label printers, lab equipment and the MES link on the line need a stable, low-latency connection; a cloud ERP needs a local edge concept for this, otherwise the line stops when the connection does. Second, operating hours: many plants produce at night or at weekends, when cloud vendors schedule maintenance windows – the contracts must rule that out. Third, audit readiness: IFS and BRCGS require access control and data integrity, which both models can provide, but in the cloud the vendor has to prove them (ISO 27001, SOC 2), not your IT. What speaks for the cloud: no in-house server infrastructure, no staff for operations and security, releases as standard. What speaks for on-premise: full control over customisations and release timing, which matters with extensive custom development. If you choose an industry ERP today, the vendor often answers the question for you – many specialist systems are only available in one deployment model. Then the industry logic decides, and the deployment model follows.

In our projects, a structured ERP selection in food manufacturing typically takes four to six months from process analysis to the signed decision. The time doesn't go into comparing systems, but into process analysis and the requirements specification – at a Tyrolean dairy that meant 47 individual processes in six areas and 156 weighted requirements before any vendor was contacted. The reason: in a proof of concept, a vendor can only show what you give them as a test case. Without clean recipes, allergen data and a real batch history, the proof of concept tests the vendor's demo data, not your business. Where it takes longer: several sites with different master data, recipes that exist only in people's heads or in Excel, and a certification profile that is currently being extended. Where it can be faster: one site, documented processes and a clear prior decision for a system class. We work in stages with a fixed scope – process analysis, requirements specification, market analysis, selection – and you see the result of each stage before the next one starts. A selection finished in six weeks has skipped the process analysis; the implementation makes up for it later, at higher cost.

The effort depends on the number of processes, sites and recipes – not on company size alone. A dairy with ten employees, 180 suppliers and a maturing store has more ERP-relevant processes than a bottling plant with fifty employees and three products. That is why we price each stage separately – process analysis, requirements specification, market analysis, selection with proof of concept – and fix its scope before it starts. After each stage you can stop, continue or adjust the scope. Our fee is the same whichever system you choose in the end: we don't sell licences and receive no vendor commission. That isn't a side note; it is the reason the recommendation holds up. When independent consulting isn't the right route: if you have one site, a simple range with no certification pressure and already a clear preference for a system class, a short plausibility check of your requirements specification is often enough instead of a full selection project. We say so in the first conversation – a selection project you don't need isn't a good project. As a rough guide: in our projects, consulting costs are well below the cost of a single failed implementation that has to adapt an unsuitable system after the fact.