How manufacturers are cutting their energy bill without guessing

It's very likely that your factory already has some form of energy monitoring in place. There's a meter at the grid connection, maybe a dashboard that shows total power draw, and a utility invoice that lands once a month. That used to be enough. It isn't anymore.

Energy prices have risen. So have the input costs of heating, refrigeration, steam, compressed air tied to them. The margin on a batch of frozen potato products or a fermentation run now depends, in part, on how efficiently that process uses energy. And plant-wide totals don't tell you which line is the problem, which product is the culprit, or which shift is running the heating longer than it needs to.

This post walks through how food manufacturers are moving from total-consumption monitoring to production-context energy management, and what that actually requires to set up.

Why your energy bill doesn't tell you enough

The monthly invoice gives you the cost. It doesn't give you the cause.

Heating, cooling, mixing, and CIP cycles all run at different efficiencies, on different lines, for different products. A high bill could mean one line is running inefficiently, one product is disproportionately energy-intensive, or the plant is consuming a significant share of its total energy during idle and standby periods.

Without visibility below the site level, you can't tell which of these is happening. Every batch looks the same on the invoice.

The shift that changes this is called energy attribution: breaking down consumption by line, machine, batch, and product. Once you can see energy at that granularity, the cost becomes actionable. You can compare Monday's fermentation run to Friday's. You can see that Product A costs 40% more energy per tonne than Product B. You can see that the fryer on Line 2 uses significantly more power during startups than Line 1. And you can start investigating why that was.

None of that is visible from a single site-level meter.

The case for sub-metering: start at the machine level

Before you can optimize, you need to measure. That means sub-metering: energy meters installed at the line or machine level, rather than just at the grid connection.

In practice, this means pulse counters or smart meters on your major utility feeds (electricity, gas, water, compressed air, steam) feeding data into your control infrastructure via standard protocols: Modbus, MQTT, OPC-UA. The meters themselves are not expensive. The value comes from what you do with the data once it's collected.

A practical starting point is the Pareto principle: don't instrument everything at once. Identify your three or four highest-consumption assets first. Typically, these are heating systems, refrigeration compressors, and bulk transport pumps. Start there. Once those are metered and feeding data, you've covered the majority of your consumption and can build from that foundation.

The key discipline at this stage is not to skip ahead to dashboards. Map your processes and utilities in detail before investing in software. Know what you're measuring before you build anything on top of it.

Connect energy data to your process data

Raw meter readings tell you how much energy was used. They don't tell you what was happening at the time.

A spike in power draw at 03:00 could be a scheduled CIP cycle, an unplanned restart, a recipe changeover, or a piece of equipment running inefficiently. Without production context, you can't distinguish between them.

This is where connecting energy data to a process historian changes the picture. A historian like Factry Historian collects all your sensor data, including your energy meters, alongside process events: batch starts and stops, recipe changes, stoppages, alarms, downtime. When you overlay these, energy patterns become explainable.

The basic architecture is three steps:

1. Capture and structure. Energy meters feed into the historian alongside process sensors. All data is timestamped and tagged to the right asset in the hierarchy.

2. Translate to the right metrics. Raw kWh values become KPIs: kWh per batch, kWh per tonne of output, energy cost per SKU. These calculations are run inside the historian and written back as new measurements — so they're available in dashboards just like any other sensor reading.

3. Add production context. Energy data is linked to the events happening at the same time: which batch was running, which recipe, which line. Now you can slice energy consumption by product, by shift, by line — and compare.

Agristo, a Belgian producer of frozen potato products operating across four sites, uses this approach to track water and energy consumption per production stage. Operators and engineers can now build their own dashboards querying oil or water usage for a specific time window in minutes, without IT involvement. The data sits in one place, structured, accessible to anyone who needs it.

The dashboards and KPIs worth building first

Once your energy data is in the historian and linked to production context, the question becomes: what should you actually monitor?

Here are the KPIs worth prioritising, in roughly the order they deliver value:

kWh per batch. The single most actionable number for process manufacturers. Compare batches of the same product across lines, shifts, or time periods. Deviations here almost always point to something fixable.

kWh per tonne of output. Normalizes for batch size differences, making comparisons between product types meaningful. If Product A consistently runs at 40 kWh/tonne and Product B at 28 kWh/tonne, that's a product costing KPI.

Energy during idle and standby. Equipment that's not producing is still consuming. This is often the highest-impact reduction opportunity and the least visible one without sub-metering. Set a baseline and track it as a percentage of total consumption.

Peak demand vs production rate. High power draw during low-output periods usually indicates equipment running at inefficient load points. This is particularly relevant for compressors and heating systems.

Energy per CIP cycle. In food and beverage, CIP is one of the biggest combined consumers of heat and water. Tracking CIP energy separately and comparing across lines or products often surfaces the fastest wins.

Utility cost per SKU. This is the number that connects energy to the P&L. It requires linking energy data to your production records, but once it's there, it changes the conversation from "our energy bill is high" to "this product costs X cents per unit more to make than it should."

‍

Related: Reducing Energy & Water Consumption in Industry 4.0 with Grafana

Catching energy spikes before they become budget problems

The next level beyond monitoring is alerting: getting notified when something is wrong before it shows up on the invoice.

In Factry Historian, this means two types of alerts:

Threshold alerts on raw power draw per asset. If the fryer on Line 2 draws more than X kW outside a production window, that's an alert. If a pump exceeds its normal operating range, that's an alert. These are simple to configure and often catch equipment degradation early. For example, a heating element drawing more current than normal is usually a sign it's failing.

Ratio-based alerts on energy-to-output relationships. If kWh per batch on Line 1 exceeds your baseline by more than 10%, something has changed eg. recipe, setpoints, operator behaviour, or equipment health. This is harder to configure but more powerful, because it catches problems that don't show up as raw consumption anomalies.

Common causes of energy spikes worth setting alerts for:

• Pumps running dry or cavitating (higher power draw, lower output)
• Heating elements degrading (longer heating times, more energy per cycle)
• Changeovers that weren't optimized for the new product's energy profile
• CIP cycles running longer than scheduled — heat and water together

The practical approach: one threshold alert per major asset, one ratio alert per line. Start simple. As your baseline data matures, your alerting logic can get more sophisticated.

Three things manufacturers who get this right have in common

Looking across the food manufacturers that have moved from site-level energy monitoring to production-context energy management, three patterns stand out.

They built the data foundation first. Sub-meters in place, historian collecting, asset hierarchy structured — before touching dashboards or trying to optimize anything. The temptation is to build dashboards immediately. The ones who succeed spend more time on data quality upfront and less time reworking things later.

They worked iteratively. One line, one product, one KPI at a time. Pareto drove the sequence: start with the biggest consumers, get clean data there, build confidence, then expand. The factories that tried to instrument and optimize everything at once typically stalled.

They chose open software. Not because "open source" is a philosophy, but because it's practical. When the system is open — technically and for people — any engineer can explore the data themselves. They can build a dashboard to answer a question they had at 14:00 and have an answer before the end of the shift. That kind of self-service is what turns an energy monitoring project into a continuous improvement habit. Point solutions that lock data behind proprietary interfaces don't create that habit. They create dependency.

Where to start

The path from a monthly utility invoice to batch-level energy intelligence is straightforward in principle, even if it takes time to execute well:

1. Sub-meter your top three or four energy consumers
2. Connect those meters to a historian alongside your process data
3. Build three KPIs: kWh per batch, energy during idle, and one ratio alert per line
4. From there, expand based on what you find

The first use case is achievable in weeks. The compounding value comes from what you build on that foundation over the following months.

For a closer look at how Factry Historian handles energy data collection, structuring, and dashboard building: docs.factry.io

For the full picture of how Agristo built a culture of data-driven operations across four sites including energy and water monitoring, read this.

‍