.png)
Multi Site Energy Monitoring for Consistent Facility Reports
Comparing electricity bills across several facilities can look simple until the numbers start to disagree. One site may use more power because it runs longer shifts. Another may look efficient because part of its load sits on a landlord supply. A smaller facility may have the highest energy intensity in the group, even when its total bill is low.
That is why useful reporting starts before the dashboard. It starts with definitions.
For multi site energy monitoring to produce reports people can trust, each facility needs comparable meter boundaries, asset names, timestamps, units and operating measures. Without that groundwork, a report can show neat charts while still comparing unlike things.
Comparable reports need agreed measures
A good multi-facility report should answer a small number of repeated questions. It should not try to explain every circuit on every page.
Start by agreeing what the business actually wants to compare. Common measures include:
Daily energy use
Total kWh over a defined reporting day.
Peak demand
The highest demand value in the interval data for the reporting period.
Out-of-hours load
Energy used when the site is expected to be idle or in setback mode.
Energy per production unit
kWh divided by tonnes, items, batches, pallet movements or another agreed operating measure.
Energy per occupied area
kWh per square metre, often useful where production units do not apply.
Energy by major load type
Lighting, HVAC, refrigeration, compressed air, process equipment or tenant supply where these are separately metered.
The best set depends on the facilities. A cold storage group will care about refrigeration load and temperature-related baseload. A manufacturing group may focus on production lines, compressed air and shift patterns. A mixed property portfolio may need tenant, landlord and common-area separation.
Keep the first version tight. A report with five trusted measures is more useful than a report with 40 half-defined graphs.
Meter boundaries affect every comparison
A meter boundary defines what is included in a number. Without that boundary, “site energy use” can mean different things at different facilities.
One site’s main meter may include office, production, refrigeration and electric vehicle charging. Another may exclude landlord services. A third may have solar generation behind the meter, which changes the relationship between grid import and actual consumption.
Before comparing facilities, document the boundary for each reported figure.
Reported figure | Boundary questions to settle |
Site total energy | Does it include all buildings, tenants, common areas and external plant? |
Production energy | Which switchboards, lines or process loads are included? |
Out-of-hours energy | What times count as out of hours for each site? |
Grid import | Is behind-the-meter solar separated from total building consumption? |
Energy intensity | Which production or occupancy measure matches the metered load? |
Refrigeration energy | Are compressors, condensers, evaporators and defrost loads all included? |
EV charging | Is it reported as site load, transport load or a separate category? |
This detail may feel administrative, but it prevents false conclusions.
A large facility that includes EV charging should not be judged against a similar site where vehicle charging is excluded. A warehouse operating 24 hours should not be compared directly with a single-shift site unless the report normalises for operating hours or production volume.
Acrel meters can form part of the field measurement layer where new metering is needed. Existing meters may also be reusable if they provide the required readings, accuracy, time intervals and communication interfaces. The key is not the brand alone. The key is whether the measurement boundary supports the reporting question.
Operating context belongs beside energy data
Electricity use rarely explains itself. A site can use more energy because it made more product, opened longer, cooled more stock or supported more people on site.
That is why energy data should sit beside operating data. The report does not need every business system integrated on day one, but it does need the right denominator for the comparison.
Useful operating measures may include:
Tonnes produced
Units packed
Batches completed
Occupied hours
Number of shifts
Square metres in use
Refrigerated volume
Degree days or outside temperature bands
Trading hours
Machine runtime
The right measure should match the load. Production output may explain process energy, but it may not explain office HVAC. Occupancy may explain lighting and ventilation, but not a fixed refrigeration baseload.
This matters most when facilities are different sizes. A small site with low total consumption can still have poor energy performance per unit. A large site can look wasteful in absolute kWh while performing well when measured against output.
The aim is not to excuse high use. The aim is to compare fairly enough that exceptions are credible.
Naming needs to work for people who are not on site
A reading labelled `Meter 4` might make sense to the person who installed it. It will not help someone reviewing 12 facilities from another state.
Every site should use a repeatable naming structure for sites, boards, meters and assets. This makes reports easier to read, fault-find and maintain.
A practical naming pattern may include:
Site code
Building or area
Switchboard name
Circuit or asset
Meter type
Direction of measurement where needed
For example, `MEL-PRD-DB2-CompressedAir-01` is much clearer than `Meter 4`. It tells the reader the site, area, board and load without needing to open a separate drawing.
Good naming also helps when meters are replaced, moved or added. If a new production line is installed, the naming method should already show where the new readings belong.
Record the details that affect interpretation:
Physical circuit measured
Meter serial number
Current transformer ratio
Voltage reference
Units reported
Pulse value if pulse metering is used
Scaling applied in software
Installation date
Commissioning checks
Communications path
Data interval
This information should live somewhere controlled, not in one person’s notebook. A meter register, asset database or maintained commissioning sheet can all work if the information stays current.
Data quality should remain visible
Reports can become dangerous when they hide data gaps. A site with a failed meter must not appear to have achieved exceptional energy savings. A communications outage should not quietly turn into a performance improvement.
Good reports show the quality of the data as well as the result.
Include data quality checks such as:
Missing intervals
Repeated values
Zero readings during expected operating periods
Extreme spikes
Estimated values
Communications outages
Meter changes
Time synchronisation issues
A monthly report might include a simple completeness measure for each site. For example, it can show whether the report is based on complete interval data, partial data or estimated data. If a facility has only 70 per cent valid readings for a month, the report should make that clear.
This is especially important when data comes from different systems. One site may provide five-minute interval data. Another may provide 15-minute readings. Another may only have daily totals until more metering is installed. These can still support useful reporting, but the report should not pretend they are identical.
ProSense can assess communications, gateways and a suitable reporting platform for the project. That assessment should include how data will be validated, stored, time-stamped and recovered after outages.
Time rules need to be settled early
Time handling sounds minor until a national report crosses state borders.
Australia has different daylight saving arrangements across states and territories. Reporting cutoffs also vary by business. One facility may treat the reporting day as midnight to midnight. Another may need 6 am to 6 am because production runs overnight. Retail sites may want trading-day logic instead of calendar-day logic.
Decide the time rules before the reports go live.
The report should define:
Local time handling
Daylight saving treatment
Reporting day start and end
Weekly and monthly cutoff rules
Public holiday treatment where relevant
Shift calendars
Interval length
How late data is handled after cut-off
If a monthly report is issued on the second business day, will it include late-arriving data received after that point? Will the previous month be restated when missing readings arrive? Who approves any restatement?
These rules prevent arguments later. They also help explain why a number in the dashboard may differ from a number in a bill, production system or finance report.
Exceptions should lead to an owner and a next step
Monthly energy reporting should do more than rank sites from best to worst. It should identify exceptions that someone can investigate.
A useful exception has three parts:
What changed
Why it matters
Who owns it
The report points to a measurable difference, such as a higher baseload or a demand spike.
The report links the change to cost, emissions, equipment operation or business performance.
The report names a site, role or maintenance path responsible for checking the cause.
For example, a production building with sustained overnight demand may need a check of compressed air leaks, HVAC scheduling, freezers, pumps or process equipment left running after shutdown. A warehouse with weekend load may need a review of lighting controls or battery charging. A site with a new peak demand may need to confirm whether a large motor start, cooling event or operational change caused the spike.
Avoid treating every exception as a failure. Some changes have valid explanations. A demand increase may match a planned production increase. Higher refrigeration load may follow warmer weather or stock profile changes. The report should help separate expected changes from avoidable waste.
The owner matters because reports without ownership become archives. If an exception is worth showing, it should be clear who can confirm it, correct it or explain it.
Dashboards should follow the reporting design
Many projects start with dashboard design because it feels tangible. Screens, charts and colours are easy to discuss. But dashboard graphics cannot fix weak definitions.
Set the reporting design first.
A practical order is:
Define the reporting questions
Agree what decisions the report should support.
Map the measurement boundaries
Confirm what each meter includes and excludes.
Build the naming standard
Make site, meter and asset labels readable across the portfolio.
Check the data paths
Confirm meters, gateways, networks and platforms can supply the readings.
Set time and quality rules
Keep timestamps, missing data and estimates visible.
Design the report
Build charts and tables around agreed measures.
Review exceptions monthly
Assign owners and track whether issues were resolved.
This order keeps the project grounded. It also reduces the chance of rebuilding reports after people realise the same chart means different things at different sites.
A practical reporting pack for multiple facilities
A consistent monthly pack does not need to be complex. It should be repeatable enough that people trust it, while still allowing local notes.
A useful pack might include:
Portfolio summary for the month
Site ranking by agreed intensity measure
Total kWh by site
Peak demand by site
Out-of-hours load by site
Energy per operating measure
Major exceptions
Data quality summary
Meter and communications issues
Notes on production, occupancy or weather impacts
Actions carried over from the previous month
For senior review, keep the first pages simple. Show whether the portfolio is changing, which sites need attention and which actions remain open.
For technical review, include enough detail to trace the number back to the meter. This may include interval charts, load profiles, circuit-level detail and meter health information.
The most useful reports serve both needs without mixing them on every page. A summary page should not look like a commissioning record. A technical appendix should not be reduced to a traffic-light score.
What a consistent report makes possible
Once definitions are stable, the report becomes more than a monthly record. It becomes a way to manage facilities with evidence.
Teams can compare sites with more confidence. Maintenance can focus on recurring after-hours load instead of broad guesses. Capital planning can use measured demand and load profiles. Energy projects can be checked against a known baseline. New sites can be added without reinventing the report each time.
The work starts with plain decisions:
What are we comparing?
What does each meter include?
What operating measure makes the comparison fair?
How do we name assets so people can understand them remotely?
How do we show missing or estimated data?
Who owns each exception?
Acrel meters, existing field devices, gateways and reporting platforms can all play a role. The lasting value comes from connecting those parts to clear reporting rules.
Consistent facility reports do not need more decoration. They need agreed boundaries, repeatable data structures and visible data quality. Build those foundations first, and the charts will start to mean something.
