Guidance for Utilities on Providing Whole-Building Energy Data to Enable Benchmarking in ENERGY STAR® Portfolio Manager®

Table of Contents

• Introduction
  • Key Recommendations
• Discussion of Key Recommendations
  • 1. Implement a data aggregation threshold and corresponding data aggregation methodology
    • Recommendation 1
    • Recommendation 2
    • Recommendation 3
  • 2. Provide complete, accurate, and timely aggregate whole-building data to requestors
    • Recommendation 4
    • Recommendation 5
    • Recommendation 6
    • Recommendation 7
  • 3. Use the Portfolio Manager API to deliver the data
    • Recommendation 8

Introduction

As utilities have developed solutions to provide commercial and multifamily customers with aggregate energy consumption data to benchmark in the Portfolio Manager tool, NRCan has observed several best practices that maximize customer experience, benefit the utility, and improve data accuracy. These best practices have been grouped into the set of recommendations described in this guidance document.

Key Recommendations

NRCan offers eight key recommendations grouped into three different categories:

1. Implement a data aggregation threshold and corresponding data aggregation methodology

• Recommendation 1: Establish an aggregation threshold (if not already established by policymakers) to enable delivery of aggregate consumption data to a building owner/requestor
• Recommendation 2: Ensure that the data access solution can support requests at varying levels of granularity
• Recommendation 3: Implement a utility-led process to identify all meters/accounts at a property that will be included in aggregate consumption

2. Provide complete, accurate, and timely aggregate whole-building data to requestors

• Recommendation 4: Provide aggregate whole-building data to requestors monthly
• Recommendation 5: Provide an “itemized receipt” for meter-to-building mapping and ensure it can be updated over time
• Recommendation 6: Proactively communicate any corrections or updates to aggregate consumption data to the building owner/data requestor
• Recommendation 7: Ensure that aggregate consumption captures total (gross) grid electricity consumption, rather than net (or net-metered) consumption

3. Use the Portfolio Manager application programming interface (API) to deliver the data

• Recommendation 8: Larger utilities should use the Portfolio Manager web services API to deliver data to requestors

The remainder of this document explores each recommendation in greater depth.

Discussion of Key Recommendations

One of the main barriers to benchmarking multi-tenant and multifamily residential properties is that building owners or operators (or their agent) responsible for benchmarking may not have access to complete consumption data for tenants/residents that are directly billed by the utility. From a utility’s perspective, each individual tenant/resident is a “customer of record,” and the building owner is therefore considered a third party with respect to tenant/resident-level consumption data. Without this consumption data, building owners cannot account for the total energy consumption required to operate their building.

Most, if not all, utilities have an established process by which customers can authorize the release of their consumption data to a designated recipient. However, when a property contains tens or even hundreds of tenants/residents, using this process creates a significant burden for the building owner—who may still end up with incomplete data for the whole property if certain individual tenants/residents refuse to release their data or fail to complete the appropriate authorization. For this reason, obtaining complete consumption data for the entire building may be functionally impossible for owners of large multi-tenant or multifamily residential properties—leaving them unable to benchmark their property (whether voluntarily or in response to a provincial, territorial, or municipal policy or program requirement). And, while it may be possible for building owners to install a “shadow” master meter, this solution is likely to introduce significant expense, which many building owners will not be able to afford. Therefore, this is not expected to be a common practice for resolving data access issues.

The provision of aggregate whole-building energy consumption data by a utility to a building owner has become an established approach for balancing considerations of data access (for the building owner) and data privacy (for tenants/residents). Across Canada, more and more utility providers are deploying data access solutions to facilitate customer benchmarking. A growing number of utility providers are delivering aggregate data to building owners through solutions that use the Portfolio Manager web services application programming interface (API), allowing the utility to transfer consumption data directly into the customer’s Portfolio Manager property record(s).

Although utilities may initially consider developing aggregate data access solutions because of provincial, territorial, and municipal requirements, they should strive to make solutions available to all customers in commercial, institutional, or multifamily residential buildings, and not just those required to meet policy or program requirements.

1. Implement a data aggregation threshold and corresponding data aggregation methodology

Why this is important

Data privacy is of critical importance to utilities and their customers. Building tenants/residents need to know that their consumption data is not being released without their permission unless specific criteria are met that will prevent re-identification of their individual consumption history. Furthermore, building owners need to know that they are not at risk of liability for the use of any data provided to them by the utility for benchmarking purposes. Finally, the utility needs to be confident that it has upheld the legal requirements for customer data privacy enshrined within federal, provincial, or territorial privacy legislation or other regulatory bodies. An aggregation threshold is a mechanism for balancing privacy concerns with the needs of building owners to obtain the data required for accurate benchmarking.

A primary consideration in the establishment of an aggregation threshold is to define the point at which (once individual tenant/resident consumption data has been combined into the aggregate total) the risk of re-identifying the consumption of any individual tenant/resident is considered eliminated or else appropriately mitigated. The threshold is typically defined in terms of the number of distinct customers/tenants located within a given property.^{Footnote 1} If a given property meets or exceeds this threshold, the utility will release aggregate whole-building consumption data to a qualified requestor (for example, building owner, operator, or designated agent) without any requirement for tenant/resident-level authorization. If the aggregation threshold is not met, the utility will only provide aggregate consumption data to the qualified requestor after tenant/resident-level authorization has been received.

Key details

In Canada, utilities providing aggregate data to building owners are applying a threshold in the range of 10 customers/tenants or more, which is generally understood to provide an appropriate balance of data access and data privacy. Some utilities also apply a secondary criterion that addresses disproportionate use by a single customer or tenant. The criteria are expressed in an “X/YY” format (for example, 4/50, which means that a property must have four or more customers/tenants and that no single customer/tenant accounts for more 50% or more of the total consumption of the energy type being aggregated). In Canadian examples to date, the aggregation threshold has been determined directly by a utility, in consultation with their legal and regulatory departments. However, aggregation thresholds may be established through provincial, territorial, or municipal policies or programs.

It is worth noting that some utilities (and/or their regulators) may have already established aggregation thresholds for other data access use cases (for example, aggregation of consumption data or other customer information at the postal code or census block level). However, the provision of aggregate consumption data to commercial, institutional, and multifamily residential building owners to support energy performance benchmarking is a discrete use case. The deliberations on aggregation thresholds should reflect this, rather than treating pre-existing aggregation thresholds for unrelated use cases as precedent.

When selecting the aggregation threshold that will be used, the correct unit of measurement is the number of unique customers/tenants currently located at the property, and not simply the number of meters. This is based on the following considerations:

• The goal of an aggregation threshold is to mitigate the risk of connecting energy consumption data to any individual customer/tenant within a multi-tenant or multifamily residential property
• It is possible that a single customer/tenant’s utility account could include more than one meter
• Therefore, a focus on number of meters, on its own, may not offer the intended level of data protection. For instance, if a property has two customers/tenants with 3 meters apiece, an aggregation threshold of 4 meters would be met, while an aggregation threshold of 4 tenants would not be achieved

In the case of properties for which the building owner/manager is the only customer/tenant, and therefore the property does not meet the established aggregation threshold, utilities should establish an exception whereby the building owner can request and receive aggregate consumption data without the submission of additional authorization. In such cases, the streamlined provision of aggregate data may be a matter of convenience rather than necessity (since the building owner should have access to the utility bills from which consumption data can be entered manually into Portfolio Manager, absent any other solution). Nevertheless, observed best practice suggests that utilities should specifically recognize this scenario and ensure that there are no unnecessary barriers to building owners requesting and receiving aggregate data for properties where they are the sole customer/tenant.

As discussed above, the ability to obtain whole-building aggregate energy consumption data is of primary importance for building owners seeking to benchmark. As such, the provision of aggregate data should be the main priority for utilities as they design and develop their systems. There may also be opportunities to provide additional value to a subset of requestors who desire tenant-level data and are willing to pursue and complete the tenant data release authorization process. It is recommended that utilities consider building this flexibility into their data access solutions.

Why this is important

Any type of commercial property can be benchmarked in Portfolio Manager. While many property types function as individual buildings, a number of them frequently operate as multi-building campuses (for example, multifamily residential, K to 12 schools, hospitals, hotels, and senior living facilities). For this reason, Portfolio Manager has the capability that allows the performance of each building within a campus to be tracked individually and then combined to create a record for which property-level performance metrics (including the ENERGY STAR 1 to 100 score, where available) can be generated. Owners of campus-type properties may seek to track both property-level and building-level metrics. In fact, some provincial, territorial, and municipal policies or programs may require that performance metrics be reported at one level versus the other.

Since Portfolio Manager offers this flexibility, utilities should ensure that their data access solutions support data requests regardless of whether they are submitted at the individual building level or at the campus level. It is important that building owners are able to request and receive aggregate data consistent with the level of granularity at which they choose (or are required) to benchmark their properties, provided the established aggregation threshold is met.

Key details

As part of the process by which a utility identifies/locates the meters or accounts that will be used to calculate aggregate consumption data (see Recommendation 3 below), a property owner/data requestor is typically prompted to provide one or more addresses associated with the building or property. The utility can use these addresses to identify the relevant meters/accounts associated with the building or property, from which it will calculate and deliver the corresponding aggregate consumption data. If the number of customers/tenants associated with the address or combination of addresses submitted by the requestor meets the aggregation threshold, the utility solution should be capable of providing data at the level of granularity specified by the requestor (for example, a single property-level request aligned with a set of addresses versus multiple distinct building-level requests, each pertaining to an individual address).

There may be cases where building-level data is requested for a campus-style property consisting of some individual buildings that meet the aggregation threshold and others that do not. In these cases, the utility has a few options for responding to the request for building-level aggregate data, including:

• requiring data release authorizations from all customers/tenants in the buildings that don’t meet the aggregation threshold
• allowing the building owner to request a combined aggregate total for the buildings not meeting the threshold, and/or
• suggesting that the building owner requests aggregate consumption data at the property level only

Finally, there may be scenarios in which the owner of a multi-tenant or multifamily residential property would like to separate a property’s consumption data into two “bins,” one reflecting the total, aggregate consumption for all tenants/units at the property, and the other reflecting the consumption paid for by the property owner. This can be especially valuable if an owner is seeking to calculate Scope 2 versus Scope 3 greenhouse gas emissions and therefore needs to differentiate between owner and tenant/unit-controlled energy consumption. Utilities should consider including request and fulfillment pathways within their data access solutions that allow a building owner to specify this scenario so that they can maintain separate owner-paid versus tenant-paid meter consumption data in their Portfolio Manager accounts.

Why this is important

The correct and complete identification of the meters and/or accounts that comprise whole-building energy consumption is a critical step in ensuring the accuracy of the resulting aggregate data.

Incomplete or inaccurate aggregate consumption data may result in incorrect benchmarking metrics, diminishing the value of benchmarking because building owners, as well as those who request or require benchmarking data from building owners, will not have a complete understanding of performance. This may result in:

• Suboptimal prioritization of resources for building improvement (for example, focusing on low- and no-cost operational improvements when capital expenditure is warranted, or vice versa, or incorrectly focusing on one property over another when allocating funding for capital expenditures)
• Incorrect determination of compliance versus non-compliance by provincial, territorial, and municipal jurisdictions
• Other downstream impacts related to investor and shareholder reporting, green building certification programs, and specialized financing opportunities

Key details

The initial and ongoing identification of the meters and/or accounts that collectively comprise the total energy consumption of a given property (referred to below as “meter-to-building mapping”) continues to be the most difficult (and arguably the most important) aspect of a utility data access solution. In the absence of a single, unambiguous “key” that maps meters/accounts to a property, utilities have adopted various approaches to ensure that the aggregate consumption data provided to requestors is complete and accurate.

The recommended approach is for the utility to initiate the identification of all relevant meters/accounts, using a limited number of required inputs from the requestor (for example, primary building address; any secondary addresses associated with the property; account IDs for any building owner/manager-paid accounts). While some utilities have required that requestors provide a complete list of meter IDs that will be used to generate the aggregate consumption data, this is a less common approach that can result in missing data points, place an additional burden on requestors, and ultimately lead to a less positive customer experience.

This best practice emphasizes the development of a clear process by which the utility presents the initial meter/account mapping to the requestor and subsequently facilitates back-and-forth communication to fine-tune this information. Regardless of the exact mechanism used to initiate the data request and the corresponding meter-to-building mapping process (for example, web-based form; interactive web portal), it is critical that the utility presents the data requestor with a list of the identified meters/accounts (or a list of the tenant names associated with these meters/accounts) that will be rolled up into aggregate whole-building data.^{Footnote 2} With this list, the data requestor can review the meters/accounts identified by the utility and can provide feedback regarding any missing or unnecessary elements. Upon confirmation of the meter-to-building mapping, the utility can use this information to process the initial delivery of historical data to the requestor (typically, no less than 12 months of aggregate consumption data, and frequently as many as 36 or even 48 months), as well as the ongoing delivery of aggregate consumption data following the initial transfer (see Recommendation 4 below). This best practice is relevant regardless of how the utility ultimately chooses to transfer the aggregate consumption data to the requestor (see Recommendation 8 below).

2. Provide complete, accurate, and timely aggregate whole-building data to requestors

Why this is important

The monthly provision of data can be critical if building owners/managers are reporting their properties’ energy performance to third parties, whether on a voluntary basis or in response to provincial, territorial, or municipal policy or program requirements. For example, building owners whose properties have attained superior energy performance (designated by an ENERGY STAR score of 75 or higher) can seek ENERGY STAR certification for their properties through NRCan. NRCan requires that a property’s application be received within 120 days of the period end date for which certification is being sought. If aggregate whole-building consumption data is not available monthly, building owners/managers may miss out on the opportunity for certification of otherwise eligible properties, resulting in a significant lost opportunity for recognition and promotion of successful energy management efforts.

Similarly, jurisdictions requiring annual benchmarking for the prior calendar year typically set a compliance deadline in the first half of the subsequent calendar year (for example, benchmarking for calendar year 2022 must be completed by April 1, 2023). Utilities offering whole-building aggregate data once per year may not be able to compile and provide this information until well into the first quarter of each calendar year, at which point the building owners required to benchmark may not have sufficient time to ensure that this data has been correctly entered into Portfolio Manager, and that any issues regarding data accuracy have been addressed and resolved with the utility.

Regular and ongoing delivery of aggregate whole-building consumption data also ensures that owners/operators can keep their properties’ benchmarking records up to date and allows any concerns regarding data completeness or accuracy to be more readily identified and addressed. Less frequent delivery of the data (for example, quarterly or annually) makes it more difficult to identify and resolve any data issues that may exist, and more importantly, prevents building owners from using the data for its primary purpose—to actively monitor the energy performance of their buildings and make informed operational decisions based on this information. Data delivered in monthly increments also benefits building owners by allowing them to calculate weather-normalized performance metrics, which allow them to focus on performance changes over time that are attributable to building operations rather than weather impacts.

Key details

The monthly provision of whole-building energy consumption data is most critical for electricity, natural gas, and district energy (for example, fuels that are continuously delivered and metered).

Utilities leveraging the Portfolio Manager web services API (see Recommendation 8 below) should design their systems to automatically compile and deliver aggregate consumption data to customers on a monthly basis following the initial provision of historical data.^{Footnote 3} The connection between the utility’s and the customer’s Portfolio Manager accounts remains in place after the initial data delivery via API; there is no further request needed from the property owner/manager to receive ongoing data. This remains true unless the number of customers/tenants located at the building has fallen below the aggregation threshold. In this case, the utility may choose to require tenant-level authorization to continue the flow of aggregate data to the building owner/data requestor.

Utilities that are delivering aggregate whole-building data to customers via spreadsheet are encouraged to treat data requests as ongoing until cancelled by the requestor (or until the number of customers/tenants falls below the aggregation threshold). As part of this approach, the utility would need to develop a process to proactively calculate and push the latest month’s aggregate consumption data to the requestor (likely, as a spreadsheet accessible via a data request portal), so that the requestor can update their consumption in Portfolio Manager.

Finally, it is important to note that some customers/tenants may be billed on different schedules than others. However, entering aggregate consumption values into Portfolio Manager requires a designated start date and end date associated with each aggregate consumption record. In these circumstances, the calendarization of individual tenant data is a necessary part of the aggregation process (to be performed by the utility system, prior to calculating and delivering the aggregate consumption data to the requestor). Where calendarization is necessary, NRCan recommends that utilities follow the time-weighting protocol used in Portfolio Manager for this calendarization.^{Footnote 4}

Why this is important

A building owner may require documentation for the meters/accounts used to compile the aggregate energy consumption that is ultimately entered in Portfolio Manager. Examples include when a building’s benchmarking record is selected for review/audit/validation by a provincial, territorial, or municipal government entity, or when requested by a licensed professional conducting a site visit as part of the ENERGY STAR certification process. The information included in such documentation (known as an “itemized receipt”) results from the back-and-forth communication between the utility and data requestor needed to establish an initial meter-to-building mapping (see Recommendation 3 above). Utilities should store and keep the confirmed meter-to-building mapping details up to date and make them available to the data requestor on demand.

Key details

This “itemized receipt” should be provided to and/or made available to the requestor on demand, so that no additional customer request is required to obtain confirmation of the meters/accounts that feed into the aggregate consumption value for any given period. This can be managed in various ways, including:

• Use of the Portfolio Manager “Aggregate Meter” designation, which allows users to track the meters or other data points that comprise the aggregate data (utilities leveraging the Portfolio Manager web services API as described in Recommendation 8 can transfer this mapping information to the requestor’s Portfolio Manager account using web service calls)
• A dedicated view or report within the online portal that the utility has developed to handle aggregate data requests, and/or
• Documentation accompanying any aggregate data provided via spreadsheet

Utilities should also establish a process for maintaining and updating meter-to-building mapping over time. This will be required if meters are swapped out, added to, or removed from a property for any number of reasons. Maintaining updated mappings assures the data requestor that all consumption sources have been correctly identified and are being properly used to calculate aggregate consumption for a given consumption period. The functionality for tracking and documenting mapping details over time is built into the Portfolio Manager “Aggregate Meter” functionality described above, allowing a utility to use the Portfolio Manager web services API to indicate which of the meters are currently in use (and if not, when a given meter’s contribution to the aggregate consumption total stopped). Updated mappings will also need to be provided by utilities delivering data by spreadsheet, although it will be the responsibility of the building owner/data requestor to transfer this information into Portfolio Manager.

Why this is important

Reported utility consumption data values may change after initial billing. For example, it is common for utilities to bill based on estimated consumption, with subsequent meter reads being used to “true-up” a prior invoice. Alternatively, utilities may use a “cancel/re-bill” process to update historical consumption data. Therefore, it is important that revisions to historical consumption data are identified by the utility, factored into recalculations of aggregate consumption data for the period(s) affected, and proactively communicated to the building owner. Building owners should be aware of changes made that would impact energy performance metrics used for multiple purposes (including compliance with provinces, territories, and municipalities) that hinge on accurate performance. Since accurate metrics are key to making benchmarking meaningful, creating an efficient process for data corrections and updates will enable building owners to respond with confidence on their benchmarking results and understand how these actions impact performance over time.

Key details

The way consumption updates are communicated to the building owner/data requestor will depend on the mechanism that the utility has selected to deliver aggregate whole-building consumption data. Utilities delivering aggregate data via the Portfolio Manager web services API (see Recommendation 8 below) should directly update the aggregate meter consumption record(s). In addition, it will be critical to alert the building owner/data requestor that changes have been made to historical consumption data, so that the requestor can review these changes to ensure accuracy and assess the impact on calculated metrics.

Utilities delivering aggregate data to requestors via spreadsheet will need to institute a process for proactively informing customers if a prior aggregate consumption value has changed, and for delivering the updated data to the customer. This could entail providing a spreadsheet with just the updated values, or else the utility could provide the original spreadsheet with the updated values clearly noted. In either case, it will be the responsibility of the building owner/data requestor receiving a spreadsheet from its utility to enter the updated consumption values into their property record in Portfolio Manager.

Special consideration should be given to situations in which a temporary consumption value of “0” was initially populated by the utility and later replaced with a non-zero consumption quantity, and/or where the updated consumption value differs from the initially provided value by more than a set percentage (to be determined by the utility). Such changes should be noted to the building owner/data requestor (as they may impact energy performance and/or greenhouse has metrics for the property), and the utility should institute appropriate processes to ensure that significant changes to historical consumption data have been validated before providing updates to the requestor.

Finally, if the utility has been using the “Estimation” flag in Portfolio Manager to indicate that a given aggregate consumption record comprises incomplete or estimated data, this flag should be removed when the consumption record is updated to a final state.

Where the utility is transferring consumption data via API, they can deselect this flag when they update the consumption record in question. If data updates are being provided via spreadsheet, then the requestor will be responsible for managing the “Estimation” flag in Portfolio Manager.

Why this is important

To correctly calculate energy performance and greenhouse gas emission metrics for buildings with onsite renewable electricity generation, Portfolio Manager requires users to input specific data points for each consumption period. These data points include:

• Gross grid electricity consumption (for example, all electricity delivered from the grid to the building, regardless of any excess electricity that was generated onsite and sold back to the grid), and
• The quantity of any surplus renewable energy that was generated onsite and exported back to the grid^{Footnote 5}

Combining these into a single “net consumption” value prevents Portfolio Manager from differentiating between the amount of grid electricity versus onsite renewable electricity that was used in the operation of the property, and therefore may prevent the calculation of accurate metrics. Without the required data, building owners will not have an accurate and complete accounting of their energy and emissions performance.

Key details

If aggregate whole-building consumption data is requested for a property that generates and consumes onsite renewable energy, the utility must address the following to ensure complete and accurate data:

• The grid electricity consumption provided to the requestor as part of the aggregate whole-building value (whether via API or via spreadsheet; see Recommendation 8 below) must be a “gross” quantity, even if the billing system is configured to present net consumption
  • If the meter technology installed at a given property does not allow the delineation of gross versus net consumption (or cannot distinguish the energy flowing from the grid to the building versus energy flowing from the building to the grid), the utility should ensure that the data requestor is made aware of this
• The total amount of electricity generated onsite that was exported back to the grid for a given period must be provided to the data requestor, assuming that this information can be tracked by the meters installed at the property

3. Use the Portfolio Manager API to deliver the data

Why this is important

The Portfolio Manager web services API is the most complete and effective mechanism for delivering aggregate whole-building energy consumption data to commercial, institutional, and multifamily residential building owners. It has the benefit of streamlining the benchmarking process for building owners, who will see updated results monthly. This is especially valuable for building owners with fewer resources available for benchmarking, as without the use of the API, the owner will need to manually enter all data monthly.

The use of the API is also a more streamlined option for the utility, eliminating the need to handle individual spreadsheet files and ensure they are matched with the correct building owner/data requestor. Using web services creates a two-way flow of information that allows the utility to obtain data and metrics from Portfolio Manager including building characteristics, energy performance, and greenhouse gas emissions. All utilities should evaluate whether the use of the API is the best option for their customers. However, smaller utilities with limited resources that do not anticipate receiving many requests for aggregate data may determine that an API integration is not cost-effective.

Key details

For utilities that anticipate receiving a significant volume of requests for whole-building consumption data (for example, hundreds or thousands of properties, as opposed to tens of properties), the aggregate data should be uploaded directly to the requestor’s Portfolio Manager property record via the Portfolio Manager API. While the development of an API integration may require additional time and resources for the initial build-out of a data access solution, compared to a spreadsheet-based solution, it is expected that the efficiencies of a streamlined and automated process will result in ongoing savings of time, effort, and financial resources. Furthermore, a notable benefit of the API pathway is that it provides the utility with the ability to obtain value-added metrics regarding the performance of the properties with which it is exchanging data. Moving beyond addressing the immediate customer need for benchmarking data, API integration may therefore facilitate the programmatic use of benchmarking data by the utility, to design, promote, and assess the impact of energy efficiency or demand-side management offerings.

Utilities that determine that use of the Portfolio Manager web service API is not a cost-effective approach (and are not otherwise required to use the API) may provide aggregate whole-building consumption data via spreadsheet. In such cases, the utility solution should still include measures to facilitate ongoing benchmarking by the building owner/manager, such as mechanisms for delivering data on an ongoing basis (see Recommendation 4 above), as well as mechanisms for updating historical consumption data (see Recommendation 6 above).