“Demand meters do more than measure electricity consumption. They reveal the customer’s peak burden on the electrical system, allowing utilities to bill fairly, plan capacity intelligently, and manage infrastructure with confidence.” – MJ Martin
Introduction
Electricity meters are often understood as simple devices that measure how much energy a customer uses. For many residential customers, that is mostly true. A standard electric meter records kilowatt-hours, or kWh, and the utility uses that value to calculate the energy portion of the monthly bill. Demand electricity meters, however, are more sophisticated. They do not only measure how much energy was consumed. They also measure how quickly that energy was consumed during the highest-use interval of the billing period. This makes them essential for commercial, industrial, institutional, and larger municipal customers whose electrical load can place significant short-term stress on the distribution system.
Energy Versus Demand
The basic difference between energy and demand is important. Energy, measured in kWh, is the total amount of electricity consumed over time. Demand, measured in kilowatts, or kW, is the rate at which electricity is used during a defined period. A customer that uses a large motor, pump, compressor, heater, or production process may create a high peak load even if the equipment only operates for a short time. From the utility’s perspective, that short period still matters because the distribution system must be sized to serve the highest expected load safely and reliably.
A Practical Analogy
A useful analogy is water flowing through a pipe. Energy is like the total number of litres consumed in a month. Demand is like the maximum flow rate required at any one moment. A customer may not consume the most total water, but if they require a very high flow rate, the pipe, pump, and service connection must still be designed to handle that peak. The same principle applies to electricity. Transformers, conductors, switches, protection equipment, and upstream capacity must be capable of serving peak demand, not just average consumption.
How Demand Meters Communicate Data
Demand meters, such as those commonly supplied by Itron and other major meter manufacturers, are designed to capture these billing determinants. In many AMR or AMI environments, a demand meter may expose multiple meter reading channels, sometimes described in the field as three ERTs or three radio channels. These are not necessarily three independent radios doing the same job. More commonly, they are three logical endpoints or channels used to transmit separate register values to the meter reading system.
Channel One: Total Energy
The first channel is typically total delivered energy, measured in kWh. This is the core consumption value and is usually the most familiar quantity on the bill. It tells the utility how much electrical energy the customer used during the billing period. For accounts without demand billing, this may be the only value required. For demand-billed accounts, it remains essential, but it is only one part of the billing calculation.
Channel Two: Peak Demand
The second channel is typically peak demand, measured in kW. This value represents the highest average load recorded during a defined interval. Depending on the utility’s tariff and meter programming, the interval may be 15, 30, or 60 minutes. The meter calculates demand by measuring energy used during that interval and converting it into a rate of use. The highest interval value becomes the peak demand for the billing period. This is the value that helps the utility recover the cost of providing system capacity.
Channel Three: The Utility-Specific Register
The third channel varies depending on the account type, meter programming, and utility billing requirements. In some cases, it may represent reactive energy, measured in kvarh, or apparent demand, measured in kVA. These values are important for customers with poor power factor, often caused by motors, pumps, compressors, or other inductive loads. In other cases, the third channel may be used for received energy, net energy, time-of-use information, cumulative demand, previous demand, or another billing-related register. This is why utilities must be careful not to assume that every three-channel demand meter is configured the same way.
Why Channel Mapping Matters
Correct channel mapping is therefore critical. A meter reading system must know which channel represents kWh, which channel represents kW demand, and which channel represents the third billing determinant. If these values are collected manually, interpreted from display scrolls, or transferred into billing software using spreadsheets, the risk of error increases. A demand meter is only useful if its data is captured accurately, validated properly, and transferred into the customer information or ERP system with the correct register codes.
Automation and Billing Integration
This is especially important for municipal utilities that are modernizing from manual reading or legacy AMR practices toward systems such as Itron Temetra, MC4Core, or other automated meter reading platforms. Automation should not simply replace a manual read with an electronic read. It should create an end-to-end data process where each register is collected discretely, associated with the correct service account, validated against expected values, and transmitted to billing without unnecessary manual handling.
Summary
Demand electricity meters tell a more complete story than standard energy meters. They measure not only how much electricity was used, but also how intensely the customer used the electrical system. This distinction supports fairer billing, better infrastructure planning, and more accurate cost recovery. For utilities, the key is not just installing sophisticated meters. The key is understanding what each register means, configuring the reading system correctly, and ensuring that every demand-related value flows cleanly into the billing process.
About the Author:
Michael Martin is the Vice President of Technology with Metercor Inc., a Smart Meter, IoT, and Smart City systems integrator based in Canada. He has more than 40 years of experience in systems design for applications that use broadband networks, optical fibre, wireless, and digital communications technologies. He is a business and technology consultant. He was a senior executive consultant for 15 years with IBM, where he worked in the GBS Global Center of Competency for Energy and Utilities and the GTS Global Center of Excellence for Energy and Utilities. He is a founding partner and President of MICAN Communications and before that was President of Comlink Systems Limited and Ensat Broadcast Services, Inc., both divisions of Cygnal Technologies Corporation (CYN: TSX).
Martin served on the Board of Directors for TeraGo Inc (TGO: TSX) and on the Board of Directors for Avante Logixx Inc. (XX: TSX.V). He has served as a Member, SCC ISO-IEC JTC 1/SC-41 – Internet of Things and related technologies, ISO – International Organization for Standardization, and as a member of the NIST SP 500-325 Fog Computing Conceptual Model, National Institute of Standards and Technology. He served on the Board of Governors of the University of Ontario Institute of Technology (UOIT) [now Ontario Tech University] and on the Board of Advisers of five different Colleges in Ontario – Centennial College, Humber College, George Brown College, Durham College, Ryerson Polytechnic University [now Toronto Metropolitan University]. For 16 years he served on the Board of the Society of Motion Picture and Television Engineers (SMPTE), Toronto Section.
He holds three master’s degrees – in business (MBA), communication (MA), and education (MEd). As well, he has three undergraduate diplomas and seven major certifications in business, computer programming, internetworking, project management, media, photography, and communication technology. He has completed over 80 next generation MOOC (Massive Open Online Courses) [aka Micro Learning] continuous education programs in a wide variety of topics, including: Economics, Python Programming, Internet of Things, Cloud, Artificial Intelligence and Cognitive systems, Blockchain, Agile, Power BI, Big Data, Design Thinking, Security, Indigenous Canada awareness, and more.
Martin in a volunteer, a photographer, a learner, a technologist, a philosophizer, and a romantic optimist.