Skip to content

How to Integrate Utility Bill Pay Services With Sustainability Software

The decades old business of paying bills on behalf of someone else is widely referred to as “Bill Pay”. It’s an essential service for real estate owners and corporations who finds themselves managing thousands of utility accounts across a portfolio. This service is the backbone onto which owners can layer any number of services such as demand response, energy benchmarking, and sustainability reporting that require utility data.

Here’s the top 3 things to understand about integrating Bill Pay services into your overall stack of energy and sustainability solutions to optimize your tech stack.

  1. Bill Pay is not a sustainability solution. But it is an enabler of an overall sustainability program. Take CDP, DJSI, GRESB, or GRI, for example. The world’s dominant voluntary standards for sustainability reporting are 60%-80% qualitative in nature. Taken as a proxy for how well “sustainability” is addressed by Bill Pay, this means you’re only addressing a minority of sustainability with utility data. But even if you had all your utility data in one place, the real challenge is accurately formatting this data into the given reporting standard. GRESB is an extreme form of this problem because individual utility meters need to be allocated to specific parts of a building, and certain buildings included or excluded to faithfully accommodate GRESB’s guidelines. Similarly precise adjustments to data are required to respond to any of the other reporting standards, so if you participate in multiple standards you’ll find utility data is only a small part of your overall challenge. So when you think “sustainability”, think about how to compliment your Bill Pay provider’s core competency with an integrated software application that can handle the full gamut of “hard” and “soft” data points required for sustainability nirvana.
  2. ENERGY STAR benchmarking is not synonymous with bill pay. Capturing utility data is not the same as benchmarking it in Energy Star Portfolio Manager. That’s because sitting between your Bill Pay provider and Energy Star is an Application Programming Interface (API) which sets the arcane rules of transferring data between the two data platforms. Using the API requires sophistication often beyond the capabilities of those whose core competency is gathering data and paying bills. After all, as a benchmarking mechanism, Energy Star speaks a different language than utility companies. It requires a whole range of qualitative data points on building operations, age, occupancy and other “meta data” in order to produce a representative benchmark. Bill Pay providers are simply not set-up to manage this type of data. Energy Star also has procedures for how bill spend and usage should be tracked that are non-standard. Fail to properly manage this translation and you’ll end up with persistent and annoying alerts in Energy Star. To make matters more complicated, Energy Star’s API changes frequently, requiring constant engineering attention to function properly. The sum result is Bill Pay providers often apply a surcharge for benchmarking data in Energy Star, if they do it at all. This expense is related to the manual effort of triaging your data in Energy Star, and it’s a sign that the Bill Pay provider’s automation capabilities are immature.
  3. Complexity is anathema to quality. The race to the bottom on Bill Pay costs has led many providers to avoid writing proprietary software to solve problems. Instead, they plug holes with people, or acquire companies who have these capabilities. Unfortunately, those people are often off-shore, and those acquisitions create ever more unwieldy tech stacks. The inevitable consequence is deteriorating quality. But good, quality assured, timely utility data is a pre-requisite to a healthy sustainability program, so make sure to ask your Bill Pay provider what mix of on- and off-line approaches they use, and what their quality assurance procedures are. Since utility bills are unique to each provider, they’re tricky to read. If non-native English speakers are used for quality control you can expect more problems… The bottom line is this: be wary of too many software systems and people being inserted into the process – the more layers, the more likely the quality and timeliness of your data will take a nosedive. Conversely, the fuller the automation solution is (and this can be vetted in any product demo) the more likely it will reduce breakpoints and improve service quality.


Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest