Energy, utilities, and sustainability software

Energy Monitoring Software Requirements Checklist

A practical requirements framework for organizations turning meter, utility, building, and operational data into trustworthy energy decisions and accountable action.

Published by · Fact-checked by OpenAI Codex research review · Published · 2141 words

Define the operating decision before requesting a dashboard

Energy monitoring software should begin with decisions people need to make. A property team may need to find overnight consumption, a manufacturer may need to relate energy to production, and a portfolio owner may need consistent benchmarking and project verification. Name the user, decision, required evidence, response time, current obstacle, and measurable result. “See all energy data in one place” is a direction, but it is not yet a testable outcome.

The U.S. Department of Energy describes energy management information systems as tools that can monitor, analyze, and sometimes control building energy use and performance. DOE also emphasizes the companion management process and operating team. That distinction matters: software can expose an anomaly, but an accountable person still needs authority, context, a safe action, and a way to verify the result. Define the first release around a small number of valuable decisions rather than every chart a vendor can demonstrate.

Set the boundary between monitoring and operational control

Document whether the proposed system is read-only analytics, advisory optimization, fault detection, a work-management trigger, or supervisory control. These boundaries carry very different safety, cybersecurity, availability, testing, and change-management responsibilities. A reporting application that reads yesterday's utility data should not quietly gain the ability to change equipment schedules because the same vendor offers a control connector. Separate data acquisition, analysis, recommendation, approval, and command execution in the architecture and interface.

Identify facilities, campuses, equipment, utility accounts, on-site generation, storage, charging, and external services within scope. Name systems that remain authoritative: a building automation system, meter-data platform, utility portal, maintenance system, billing system, or regulatory reporting application. When control is included, qualified facility, electrical, safety, cybersecurity, and engineering professionals must define permitted actions and interlocks. A general software developer should not invent operating limits or bypass equipment protections.

Create a durable asset, site, and meter hierarchy

Model organization, portfolio, site, building, space, process, system, equipment, utility account, meter, submeter, channel, sensor, data stream, tariff, and reporting boundary separately. Preserve parent-child and supply relationships with effective dates. One physical meter may feed several analytical allocations; one utility account may cover several buildings; a building may change tenant or owner without changing its historical measurements. Stable identifiers prevent names and dashboard folders from becoming the data model.

Record meter type, commodity, measured quantity, unit, multiplier, direction, interval, timezone, location, source, communication method, commissioning date, calibration or verification evidence where applicable, and lifecycle state. Distinguish utility revenue data, building meters, temporary loggers, calculated virtual meters, estimates, and manually entered bills. Users need to know what a number represents and how it was produced before they can compare it with another number or act on an apparent difference.

Define interval data, time, and unit semantics precisely

For every stream, specify sampling interval, aggregation interval, timestamp meaning, timezone, daylight-saving treatment, missing periods, duplicate readings, rollover, reset, and late arrival. A timestamp may identify the start of an interval, end of an interval, or observation time. A fifteen-minute demand value is not interchangeable with fifteen-minute energy consumption. Store original values and provenance, then create governed normalized representations rather than overwriting evidence during transformation.

Use explicit units and conversion rules. Electricity, gas, steam, water, temperature, pressure, flow, weather, production, occupancy, and cost require different dimensions and context. Record whether a reading is instantaneous, cumulative, interval total, average, maximum, or calculated. Test negative flow, exported electricity, meter replacement, multiplier changes, leap days, daylight-saving transitions, and mixed unit systems. A graph can look smooth while combining values that are mathematically or operationally incompatible.

Make data quality visible instead of silently filling gaps

Define validation for impossible values, frozen sensors, unexpected zeros, spikes, gaps, duplicate timestamps, clock drift, counter resets, out-of-order delivery, and disagreement between parent and child meters. Each rule needs scope, threshold, owner, severity, and review path. Preserve raw observations, validation results, corrections, and the algorithm or person responsible. Do not convert an uncertain reading into a normal-looking line without marking its quality.

Estimation may be appropriate for some analyses, but it must be distinguishable from measured data. Record method, inputs, confidence or quality class, affected period, approval, and later replacement by actual data. Reports should reveal how much of a period is missing or estimated. Create queues for failed feeds, stale meters, unresolved anomalies, and recurring source problems. Data quality is operational work with ownership; it is not a one-time cleanup performed before the dashboard launches.

Design ingestion and reconciliation for unreliable sources

Inventory utility APIs, Green Button or other authorized exchange, file delivery, bills, building automation protocols, gateways, historians, IoT platforms, weather services, production systems, and manual uploads. For each source, define authentication, identifier mapping, schema, interval, latency, rate limits, pagination, retries, versioning, backfill, deletion behavior, vendor maintenance, support contact, and recurring cost. Keep ingestion asynchronous where provider speed should not block the user experience.

Use idempotent processing so retries do not duplicate readings or bills. Track source checkpoints, batch identity, received time, record counts, validation outcomes, rejection reasons, and reconciliation. Compare interval totals with trusted billing periods while respecting meter changes and adjustments. If the source revises historical data, decide whether calculations are recomputed, how prior reports are identified, and who is notified. Operators need a visible exception when a feed is incomplete—not a stale chart that still looks current.

Establish baselines, normalization, and comparison rules

Define the question behind every baseline: budget planning, project measurement, anomaly detection, portfolio comparison, or organizational reporting. Specify period, included meters, weather data, occupancy, production, operating schedule, exclusions, model method, training data, adjustment rules, version, owner, and acceptance evidence. Preserve historical models and results so a later methodology change does not silently rewrite the decision record.

Normalization can improve comparison, but it can also hide operational change. A weather-adjusted value, energy-use intensity, production-normalized measure, and raw consumption answer different questions. Display inputs, units, coverage, and quality alongside results. Test facility openings, shutdowns, renovations, tenant changes, partial months, missing weather, unusual production, and equipment replacement. A benchmark should help someone investigate; it should not be presented as a universal score without explaining the boundary and assumptions.

Represent tariffs, bills, demand, and cost separately

Cost calculations require more than multiplying consumption by a single rate. Model provider, account, service period, rate schedule, energy charges, demand charges, time periods, tiers, fixed charges, taxes, riders, credits, export compensation, currency, and effective dates according to the actual bill and approved business rules. Preserve the source bill and reconciliation. A calculated estimate should remain labeled as an estimate until compared with authoritative billing data.

Peak demand may depend on interval length, billing window, ratchet, season, and utility method. Define those rules rather than using the maximum point shown on a chart. Test a tariff change during a billing period, corrected bill, meter multiplier change, missing interval near the peak, on-site generation, storage dispatch, and exported energy. Financial or regulatory conclusions should be reviewed by qualified professionals; software can make assumptions visible and reproducible but should not manufacture rate policy.

Turn anomalies into owned investigation and action

An alert needs condition, scope, comparison period, persistence, severity, suppression, recipient, escalation, acknowledgement, investigation, resolution, and verification. Provide enough context to decide whether the event is a sensor problem, schedule exception, weather response, production change, equipment fault, or expected operation. Avoid sending a message for every threshold crossing. Alert fatigue turns a technically functioning feature into an ignored system.

Connect important findings to a work item with site, equipment or meter, evidence window, suspected cause, owner, priority, due date, safety context, notes, and outcome. Preserve the link from detection through action and measured result. Track false positives, repeated conditions, time to acknowledgement, completed investigation, and verified savings carefully. The system should not claim that an alert “saved” energy merely because it was closed; savings require a defined and defensible comparison.

Design portfolios, reports, and drill-down as one evidence path

Executive summaries, energy-manager analysis, and technician investigation need different views of the same governed data. Define each metric's numerator, denominator, units, timezone, coverage, refresh time, quality rule, and owner. Make portfolio totals traceable to sites, meters, intervals, transformations, and exclusions. A downloadable number should reconcile with the displayed number and retain the report's parameters and generation time.

Useful measures may include consumption, demand, cost, intensity, baseline variance, data completeness, estimated-data share, anomaly backlog, project performance, and integration health. Avoid ranking sites without comparable boundaries and operating context. Provide accessible tables behind visualizations, clear legends, non-color status, keyboard navigation, and explanations of uncertainty. WCAG 2.2 supplies testable accessibility criteria, but representative users must still complete real filtering, comparison, investigation, and export tasks.

Separate energy data from greenhouse-gas accounting decisions

Energy activity data can support an emissions inventory, but the two are not interchangeable. Define organizational and reporting boundaries, energy source, period, location, supplier or contractual instrument where relevant, emission factor source, factor version, units, method, exclusions, recalculation policy, and reviewer. The U.S. EPA explains scope 1 and scope 2 inventory concepts and points to the Greenhouse Gas Protocol's accounting guidance. Qualified sustainability, accounting, legal, and assurance professionals should select the applicable method.

Preserve activity data, factors, calculations, evidence, and approval separately so an updated factor does not erase a previously issued inventory. Label estimated data, renewable instruments, avoided-emission scenarios, market-based or location-based results, and operational energy reductions precisely. Do not translate a real-time electricity chart into a verified carbon claim without the required boundary and method. Software should make the calculation reproducible and reviewable rather than using sustainability language as decoration.

Integrate benchmarking and external reporting deliberately

If ENERGY STAR Portfolio Manager is part of the workflow, confirm current web-service documentation, account connections, property and meter identifiers, sharing permissions, test and live environments, release changes, maintenance windows, schemas, error codes, and terms. EPA's services support exchange of property, meter, water, waste, and performance information, but the organization remains responsible for mapping, data quality, authorization, retries, and reconciliation in its own integration.

Treat every reporting destination as a versioned contract. Record what was submitted, when, under which account, with which identifiers, and whether the destination accepted or later revised it. Keep a queue for rejected records, permission changes, unmatched meters, schema changes, and unavailable services. Do not couple the primary data store to one external metric or provider response. The organization should retain usable source data and an export path if a benchmarking or reporting relationship changes.

Protect building, operational, and utility information by risk

Classify the system by what it can reveal and change. Site schedules, occupancy patterns, equipment states, utility accounts, network details, facility maps, and control capability may create security or privacy risk. Define access by organization, site, role, assignment, purpose, and action. Enforce it on trusted services for dashboards, APIs, queries, exports, files, alerts, configuration, and administrative tools. Search suggestions and aggregate reports must not leak restricted sites.

When the system touches operational technology or grid-facing processes, use risk guidance appropriate to that environment. NIST's Smart Grid Profile frames cybersecurity around business objectives, reliability, resilience, safety, and changing grid architecture. Segment networks and responsibilities, minimize privileges, protect credentials and gateways, validate commands, monitor changes, and preserve safe local operation. A cloud dashboard should never become an undocumented path around facility controls or established operating procedures.

Specify resilience, offline behavior, and recovery evidence

Classify workflows by consequence and time sensitivity. Monthly portfolio reporting, next-day anomaly review, demand response, and direct supervisory control do not share the same availability requirement. Define maximum acceptable data loss, downtime, ingestion backlog, stale-data warning, manual fallback, and recovery owner. Display last successful reading and source health so users know whether a current-looking screen is actually current.

Test gateway disconnection, provider outage, duplicate delivery, clock error, partial backfill, corrupted batch, exhausted storage, certificate expiration, and restoration from backup. Queue data safely where appropriate and reconcile after reconnection. Backups need encryption, access control, monitoring, retention, and rehearsed restoration. Recovery testing should prove that meter identity, raw data, transformations, baselines, alerts, configuration, and audit evidence remain coherent—not only that database files can be opened.

Plan migration, validation, and long-term ownership

Profile utility bills, spreadsheets, meter platforms, building systems, historians, weather feeds, asset registers, and prior reports before estimating migration. Measure duplicate meters, missing intervals, changing identifiers, unexplained multipliers, inconsistent units, timezone errors, orphaned sites, and calculated values without provenance. Define mapping, transformation, rejection, sample comparison, period reconciliation, rehearsal, cutover, rollback, and read-only legacy access.

Require ownership or transferability for repositories, cloud accounts, domains, gateways, certificates, integration credentials, device configurations, source data, calculation definitions, exports, backups, documentation, and deployment pipelines. Assign operators for data quality, meters, tariffs, baselines, alerts, security, integrations, reporting, incidents, and support. Review the cloud application architecture checklist and maintenance management software checklist for adjacent system boundaries.

Evaluate the solution with a difficult operating scenario

Ask a vendor or developer to trace one demanding scenario: a site changes timezone, a meter is replaced with a new multiplier, the gateway goes offline over a daylight-saving transition, the utility revises prior data, the apparent peak falls in a missing interval, a tariff changes, an alert creates duplicate work orders, a user loses site access, and an external reporting API rejects the resubmission. A strong design explains identity, state, units, provenance, authority, quality, reconciliation, and recovery throughout.

Then compare an established EMIS, specialist analytics, integration around existing building tools, and focused custom development against those scenarios. The business intelligence dashboard requirements checklist covers broader analytical design, while the custom software development service explains a discovery-to-delivery approach. Share sites, meters, intervals, decisions, systems, reporting needs, operating boundaries, security constraints, and current failures through the project questionnaire, or use quick contact for a focused question.

Authoritative references

Related software planning guides

Explore custom software development