Usage-based billing is a rate model in which a utility customer's bill is calculated based on their actual metered consumption during the billing period, not a fixed monthly charge. For US water, electric, and gas utilities, this means the billing system must read, validate, and apply consumption data from smart meters or AMR devices in every billing cycle. The primary operational requirement is a complete data pipeline from meter to billing engine, and the primary software requirement is a billing platform capable of holding multiple rate tables simultaneously across different account classes.
If your utility has invested in AMI infrastructure but is still running flat rates, what revenue accuracy are you leaving in the meter?
Usage-based billing is a pricing structure where charges scale directly with the volume of service consumed: water in gallons, electricity in kilowatt-hours, or gas in therms or cubic feet, as recorded by the customer's meter. The shift from flat-rate to usage-based billing is not a recent trend. AWWA research shows that tiered pricing structures have been the most common rate design in US municipal water systems for over two decades. What has changed is the infrastructure required to support more sophisticated rate designs, specifically the proliferation of Advanced Metering Infrastructure (AMI) and the billing software for utilities capable of processing interval data at scale.
The practical question for a billing manager is not whether usage-based billing is better in principle. The practical question is: does your billing system have what it needs to run these rate structures accurately, every billing cycle, for every account?
Does your current billing system create more exceptions when it processes actual consumption data than when it runs fixed charges, and why?
The core difference between flat-rate and usage-based billing is the data requirement. Flat-rate billing needs a meter read only to confirm service delivery. Usage-based billing needs accurate, validated consumption data to calculate charges against a rate table that may have multiple tiers, blocks, or time windows. That data requirement is where most billing operational complexity originates.
| Dimension | Flat-Rate Billing | Usage-Based Billing |
|---|---|---|
| Billing basis | Fixed monthly charge | Actual metered consumption |
| AMI requirement | Not required | Required for accuracy at scale |
| Billing exception frequency | Lower: fixed charges rarely error | Higher initially; drops once validated AMI data flows cleanly |
| Revenue protection | Weak: over/under-collection built in | Strong: charges match actual consumption |
| Regulatory alignment | Declining: state PUCs increasingly require tiered structures | Strong: aligned with NARUC rate design principles and EPA conservation mandates |
The higher initial exception frequency under usage-based billing deserves a direct explanation. When a utility first switches from flat rates to tiered or TOU rates, exceptions increase because the billing system is now sensitive to data quality in a way it never was before. A missed read that produced the wrong flat-rate bill now produces a flagged exception. That is exactly what you want: problems that were invisible under flat-rate billing are now visible and fixable. Once the AMI-to-MDM-to-billing pipeline runs cleanly, exception frequency drops well below flat-rate levels.
Which rate structure does your utility run today, and does your billing platform handle the data requirements that rate structure actually creates?
Usage-based billing is an umbrella term. In practice, US utilities use three distinct rate structures, each with different data requirements and billing system implications.
Consumption is divided into blocks. The first block, typically aligned with basic household need, carries a lower unit rate per gallon. Each subsequent block charges a higher rate. This is the most common structure in US municipal water utilities. California's urban water suppliers are required by state law to implement tiered rate structures under SB 814 and associated Water Board guidance.
Charges vary by time of day or season rather than volume alone. Most common in electric utilities: the customer pays more during peak demand hours and less during off-peak windows. TOU rates require smart meters capable of recording 15-minute or hourly interval reads, plus an MDM platform that can process and time-stamp that interval data before it reaches the billing engine. Residential TOU rates have expanded across most US states, driven by FERC Order 2222 and state grid modernization requirements.
Applied primarily to commercial and industrial electric accounts. The customer is billed both for energy consumed (kWh) and for their peak demand during the billing period (kW). This rate structure requires 15-minute interval data from an AMI-enabled commercial meter to calculate accurately. Demand charges are among the most complex billing structures operationally: a single incorrect interval read can incorrectly set a customer's peak demand and produce a significant billing dispute.
What happens to a meter read between the moment the smart meter records it and the moment it becomes a charge on a customer's bill?
Usage-based billing only works if the consumption data is right. When that data is wrong, whether from an unvalidated read, a missed transmission, or an estimated read used instead of an actual, the resulting bill is wrong. Billing errors under usage-based rate structures are more expensive to resolve than under flat-rate models, because the dispute has a variable bill to question, not a fixed charge.
The data pathway from meter to bill runs through three stages:
SMART360's meter data management module integrates directly with AMI head-end systems from Sensus, Itron, and Landis+Gyr, part of SMART360's 25+ pre-built integrations, so validated meter data flows directly into the billing engine without manual import or reconciliation steps between platforms.
When this pipeline runs cleanly, billing exceptions drop. When it does not (when MDM is absent, when AMI coverage is incomplete, or when the billing system cannot ingest interval data) manual reconciliation fills the gap. So do billing disputes.
Before committing to a rate structure change, which specific software capabilities should you confirm your billing platform has?
Not all utility billing software is built to handle usage-based rate structures at the account level. Legacy flat-rate platforms can produce bills based on a meter read, but they typically cannot support multiple simultaneous rate tables, interval data ingestion, or exception flags triggered by consumption anomalies. Before committing to a rate structure change, confirm your billing system supports all of the following:
For a complete list of billing software capabilities to probe in a vendor demo, see the utility billing software evaluation checklist.
SMART360's pay-per-meter pricing means a 5,000-meter water utility and a 50,000-meter combined utility pay for exactly the capacity they use, with full multi-rate billing functionality at both scales.
Where does revenue leakage actually come from in a billing cycle, and which part of it does usage-based billing eliminate?
Revenue leakage in utility billing comes from two sources: physical losses (non-revenue water, unmetered consumption, meter tampering) and billing errors (estimated reads accepted without validation, rate table misapplications, exception accounts left unresolved cycle after cycle).
Flat-rate billing masks both. A customer paying a fixed monthly charge generates no consumption signal: no high-consumption anomaly, no zero-read flag, no tamper alert, because the bill does not depend on what the meter says. Usage-based billing, correctly implemented with validated AMI data, turns every billing cycle into a continuous audit of consumption against expected norms.
That accuracy improvement has direct revenue implications. For a 30,000-meter water utility billing an average of $45 per account per month, a 1% reduction in billing errors represents approximately $16,200 in monthly recovered revenue, or $194,400 annually, from accounts that were previously under-billed or unbilled entirely.
What are the three operational problems that derail a usage-based billing rollout, and how do you mitigate each before go-live?
Transitioning from flat-rate to usage-based billing is not a software configuration project. It is an operational change project with a software component. Utilities that manage it well plan for three specific challenges before go-live.
For a workflow-level view of what billing operations look like before and after making the switch, see Advanced Utility Billing Software: A Before and After Guide.
Usage-based billing requires an actual meter read, not an estimate. If 15-20% of your meters are not AMI-enabled, those accounts require manual reads or estimated reads, which defeats the revenue accuracy benefit for those customers. Most utilities implement usage-based billing for fully AMI-covered accounts first, then expand as AMI rollout progresses. Your billing system must be able to run flat-rate and usage-based billing simultaneously during this transition period.
Moving from one flat rate to a tiered or TOU rate structure requires configuring and testing every rate table before go-live. Errors in rate table configuration are among the most common sources of billing disputes in the first 90 days after a rate change. A billing system with a sandbox environment, one that runs new rate tables against real historical account data before live deployment, reduces this risk significantly. If your billing platform lacks this capability, build an extended parallel-testing period into your implementation timeline.
Customers who receive their first tiered-rate bill without prior notice are likely to call. A usage-based billing rollout requires a parallel customer communication plan: bill inserts, customer portal notifications, and a plain-language explanation of the rate structure, deployed 30 to 60 days before the first bill goes out under the new structure. Most US state PUCs require a formal customer notice period before rate changes take effect. Confirm your state's requirements before setting a go-live date, as non-compliance can trigger regulatory penalties.
Usage-based billing is a pricing structure where a utility customer's bill is calculated based on their actual metered consumption during the billing period, not a fixed monthly charge. For water, electric, and gas utilities, this means the billing system must read, validate, and apply metered data to a rate table on every billing run. Common usage-based structures include inclining block rates (tiered water rates), time-of-use rates (electric), and demand charges (commercial electric). Each requires validated AMI data and a billing platform capable of applying multiple rate schedules simultaneously across different account classes.
Time-of-use (TOU) billing for water utilities charges different rates depending on when consumption occurs, typically higher rates during peak demand periods (hot summer months or weekday morning hours) and lower rates during off-peak periods. TOU water billing is less common than tiered block rates but is being adopted by utilities in drought-prone regions as a conservation tool. It requires smart meters that record usage at 15-minute or hourly intervals, an MDM platform that time-stamps each interval read, and a billing engine capable of applying time-segmented rate tables to produce accurate monthly bills.
At minimum: smart meters or AMR devices that transmit reads electronically, a head-end system to collect those reads, and an MDM platform that runs a VEE (Validation, Estimation, and Editing) process before passing validated reads to the billing engine. Utilities without a complete AMI-to-MDM pipeline typically implement usage-based billing for fully covered accounts first, expanding as AMI deployment progresses. A billing platform without native MDM integration requires custom middleware to move data between the head-end and the billing engine, which introduces a manual reconciliation point and a recurring source of billing exceptions.
Yes, and this is a common requirement during AMI rollout transitions. A billing platform designed for usage-based billing must be able to hold multiple rate schedules and apply the correct one to each account class automatically. Residential accounts on tiered water rates, commercial accounts on flat service charges, and irrigation accounts on seasonal TOU rates should all be processed in the same billing run without manual assignment. Legacy flat-rate platforms that require a separate billing run or a manual rate table switch for each account class are not equipped to manage this simultaneously.
Usage-based billing is the revenue accuracy standard for utilities with AMI infrastructure. The gap between what a flat-rate billing system does with meter data and what usage-based billing requires is the same gap that produces disputed bills, manual exception queues, and unresolved accounts at the end of every billing cycle. The prerequisite is not a large account base: it is a billing platform built to ingest validated interval data and apply the correct rate table to every account, every cycle.
Bynry Inc.
111 Galestown Cir
Chesterfield, NJ 08515
+1 732-630-0285
Bynry Inc.
Serene Tower, Pakharbaug
Pune, Maharashtra 411021
+91 93252-51217
