Columbus energy benchmarking: prepare building utility data before you submit

The City of Columbus Energy and Water Benchmarking and Transparency Policy page explains that the ordinance, in Columbus City Code Chapter 4117, requires owners and managers of commercial and multifamily buildings of 50,000 square feet and larger to benchmark electricity, gas and water use and report it annually through the EPA's ENERGY STAR Portfolio Manager. The page describes looking up the building's CBUSID, adding it as a unique identifier on the Portfolio Manager property, entering monthly whole-building data for the calendar year, and submitting through the city's data request.

The same page notes that the city's receiving system runs data quality checks and emails the submitter when a report trips a flag. It also describes an exemption process for buildings that meet the ordinance's criteria. I would treat those checks as a final safety net, not the first time anyone looks at the data.

The workflow should start with a meter inventory for each building: utility, account number, meter number, fuel or water type, which spaces it serves, and who pays the bill. Whole-building data means tenant-paid meters count too, and those are usually the hardest to obtain.

I would store the inventory as structured records rather than a spreadsheet tab that someone updates by memory. Each meter needs one of four statuses: data available, data requested, data received, or not obtainable with a documented reason. A building cannot be marked ready while any meter sits in an unexplained state.

The city's page mentions that an automated aggregation tool with one gas utility was expected but not yet available at the time of writing. That is a reminder to check which utilities offer aggregated whole-building data before designing the collection step, because it changes how much tenant outreach is needed.

Utility bills arrive as PDFs, portal exports and spreadsheets. A model can help extract the billing period, usage, units and meter number from each document. Every extracted value should keep a link to its source file and page so a reviewer can confirm it quickly.

The extraction should not fill gaps. If a bill is missing for a month, the record should show a gap, not an estimate. If a period spans two calendar months, the workflow should keep the actual start and end dates. ENERGY STAR Portfolio Manager supports tracking water, waste and emissions as well as energy, and it compares performance to similar buildings normalized for weather and operating characteristics. Those comparisons are only as good as the dates and units entered.

Before a person reviews the year, the workflow can run plain checks. Are there twelve months of coverage for every meter? Do any billing periods overlap or leave gaps? Are units consistent with the meter type? Is any month far outside that meter's normal range? Did the building's gross floor area or use details change from last year?

None of these checks decide that data is wrong. They produce a short list of questions for the person who knows the building. A usage spike may be a real event, such as a chiller replacement, or a data entry error. The reviewer records which, and the explanation travels with the data.

Tenant outreach is often the slowest step. The workflow can track which tenants have been asked, when, what they provided, and what is still missing. It can draft reminder messages from approved templates for a property manager to send.

I would not let the system send requests to tenants on its own in the first release, and I would keep tenant utility data inside the property team's approved storage. Tenants share that information for a specific purpose, and the access rules should reflect that.

The workflow's output is a review package: a building summary, meter coverage, flagged anomalies with explanations, and the values ready to enter. The accountable person reviews it and then enters or uploads the data and submits the report.

Automated entry into Portfolio Manager can come later, once the team trusts the preparation step. Even then, I would keep a human confirmation before submission and store a copy of what was submitted, when, and by whom.

Most of the effort in a first benchmarking year is discovery: which meters exist, who holds the data, and which bills arrive late. A good implementation turns that discovery into records that carry forward, so the second year starts from a known inventory rather than from scratch.

The acceptance condition I would set is practical. For each building in the pilot, the review package shows complete coverage or a documented reason for every gap, every value links to its source, and the accountable person can submit without rebuilding the data by hand.

Bring your building list, the meters you know about and how bills arrive today.