Meter data management (MDM) is the prerequisite infrastructure that makes time-of-use billing operationally possible for utilities. MDM collects sub-hourly interval reads from Advanced Metering Infrastructure, validates them through a VEE (Validation, Estimation, and Editing) process, and delivers billing-ready interval records to the billing system. Without a correctly configured MDM layer, a utility cannot calculate or invoice a time-of-use rate — regardless of what billing software it uses.
Time-of-use billing charges customers at different rates depending on when they consume peak-period rates during high-demand windows, off-peak rates during low-demand periods, and in some rate designs, a critical peak rate during grid stress events. For the end customer, this looks like a billing change. For the utility, it is a data infrastructure problem that starts at the meter, not at the billing software.
A ToU rate program has four non-negotiable metering requirements:
• Sub-hourly reads from every participating meter - typically 15-minute or 30-minute interval cycles
• Reliable, consistent data collection across the service territory - gaps in AMI communication mean gaps in billable interval data
• Validated, gap-free interval records delivered to billing before each billing run closes
• Correct rate period mapping - every interval must be associated with the rate tier that was in effect during that specific time window
State utility commissions and NARUC have actively encouraged municipal utilities to evaluate time-of-use and demand response rate structures as part of grid management planning frameworks.
The question most Utility Directors ask at this point is whether this is primarily a billing software problem to solve. It is not. The gating constraint is almost always the metering and MDM infrastructure. A billing platform can only apply a ToU rate schedule to data that exists and has been validated. No billing software configuration can compensate for a metering infrastructure that collects one daily read.
For utilities already evaluating how usage-based billing for utilities works in practice, ToU billing represents the interval-data-dependent end of the usage-based spectrum — the rate design that requires the most from metering infrastructure.
AMR (Automatic Meter Reading) systems collect one data point per meter per day, typically a single accumulated consumption read collected during a fixed overnight communication window. That daily total tells a utility how much a customer used across 24 hours. It cannot, by design, tell the utility when within those 24 hours the consumption occurred.
Time-of-use billing needs to know when. A commercial customer that draws 200 kWh between 2 p.m. and 7 p.m. on a summer weekday represents a materially different demand event than a customer drawing the same 200 kWh between 11 p.m. and 4 a.m. The first customer is contributing to peak demand; the second is not. ToU billing prices that difference. AMR cannot capture it.
The data volume implications of moving from AMR to AMI-based interval collection are significant:
• AMR: approximately 365 reads per meter per year (one accumulated read per day)
• AMI on a 15-minute cycle: approximately 35,040 reads per meter per year
That is a 96-fold increase in data volume per meter. Every one of those reads must be collected, validated, stored, and handed off to billing. MDM platforms designed for the AMI environment handle this data volume by architecture. Systems adapted from daily-read origins often face storage and processing constraints at this scale that their original design did not anticipate.
For a detailed look at how AMI infrastructure connects to MDM and what the data flow architecture looks like between the meter and the billing system, see AMI-MDM integration.
For utilities that are partially or fully on AMR, the ToU billing implementation path is sequential: AMI deployment first, MDM configuration for interval data second, billing system validation third. Attempting to implement ToU rate changes before the metering infrastructure is in place produces a rate program the billing system is technically unable to execute.
VEE (Validation, Estimation, and Editing) is the core processing function that MDM applies to every interval read before it is passed to the billing system. VEE is defined as the set of automated rules and manual processes that determine whether each meter read is accurate, complete, and suitable for billing. In a monthly billing cycle on AMR, VEE is a relatively low-frequency process. In a ToU environment on AMI, VEE runs continuously against a data stream that can generate tens of thousands of reads per day across a utility's service territory.
The three stages of VEE for interval data:
1. Validation: Each 15-minute read is evaluated against configurable rules, expected consumption range for that meter type, comparison to the same interval in prior billing periods, physical meter maximum limits, and communication integrity checks. Reads that fall outside validation thresholds are automatically flagged as exceptions and removed from the billing-ready dataset.
2. Estimation: When a read is missing due to a communication failure between the meter and the head-end system, or has been flagged invalid by the validation rules, MDM estimates the missing interval using load profile data from the same account and comparable accounts in the same rate class. The estimation methodology must meet the documentation standards your state utility commission applies to ToU billing data.
3. Editing: Where estimation alone is insufficient — extended outages or meter malfunctions, for example — a billing manager can review flagged intervals and apply manual corrections. Every manual edit is recorded with the editor's identity, timestamp, reason code, and the resulting VEE status, creating the audit trail that state regulators require when reviewing ToU billing accuracy.
The critical distinction for ToU billing is that VEE must be configured specifically for interval-level thresholds — not the monthly consumption thresholds used for AMR billing. A monthly consumption check looks for a 200% spike versus the prior period average. An interval check for ToU must detect whether a specific 15-minute read is inconsistent with the expected load profile for that time window — a fundamentally different detection logic that requires its own configuration and testing separate from existing VEE rules.
Once MDM has validated the interval data for a billing period, it passes those records to the billing system for rate application. This handoff is technically straightforward when both systems are designed for interval billing. It fails — silently and expensively — when either system was not built with interval data in mind.
A billing-ready interval record must carry five fields for ToU processing to work correctly:
• The meter identifier
• The specific interval start and end timestamp
• The validated consumption value for that interval
• The VEE status - actual, estimated, or edited
• The rate period designation - peak, off-peak, or critical peak for that interval
If any element arrives incorrectly or is absent, the billing engine cannot apply the ToU rate schedule accurately. Common failures include interval timestamps that do not align with the rate period boundaries defined in the billing system — which causes intervals at rate-tier transitions to be allocated to the wrong tier — VEE status fields that are not passed through (meaning billing cannot distinguish actual reads from estimated reads for regulatory reporting purposes), and daily-total records delivered instead of interval records, which renders the rate schedule entirely inapplicable.
The utility billing software that receives MDM interval data must be natively capable of consuming interval-level records, applying rate period rules, and generating a line-item ToU bill without requiring a data translation layer between the two systems.
A test cycle — running a complete interval data collection, VEE processing, and billing calculation pass on a small subset of accounts — is the only way to confirm this handoff is functioning correctly before it affects live customer bills. This test should be completed and documented before a ToU program launch date is communicated to customers or the state PUC.
The following four MDM configuration or infrastructure gaps account for the majority of ToU billing failures at utilities that have attempted to launch time-of-use programs before confirming their data infrastructure was ready:
Work through these six checks before communicating a ToU rate program launch date to customers or submitting a rate filing to the state PUC.
1. Confirm AMI coverage across all accounts targeted for ToU billing. Any account still on AMR cannot participate in a ToU program until its meter is upgraded. Identify the proportion of your service territory that is AMI-enabled and whether this covers the customer classes included in the proposed ToU rate design.
2. Verify that your MDM platform is designed for sub-hourly interval data volume — not adapted from a daily-read architecture. A system built to handle 365 reads per meter per year operates on fundamentally different storage and processing assumptions than one handling 35,040. Ask your MDM vendor directly whether the platform was architected for AMI interval data from inception.
3. Test VEE rule configuration against interval-specific thresholds. The validation rules configured for monthly or daily reads do not apply to 15-minute interval data. Interval-specific rules for spike detection, gap tolerance, and estimation methodology need to be separately configured, tested against historical interval data, and approved by billing operations before going live.
4. Validate MDM-to-billing data format compatibility. Confirm that your billing system can receive and rate interval-level records — not just daily accumulated totals. Run a test billing cycle with interval data from a sample of accounts before announcing a ToU program launch date.
5. Establish audit trail standards for edited and estimated intervals. Determine what documentation your state PUC requires for intervals that appear in ToU bills as estimated or edited. Confirm your MDM captures editor identity, timestamp, reason code, and VEE status for every non-actual read used in billing.
6. Map your rate period boundaries to your MDM interval collection clock. If your MDM collects on a 15-minute cycle and your peak period begins at 4:00 p.m., the interval from 3:45 to 4:00 p.m. straddles the rate boundary. Decide and document how your system handles boundary intervals before they appear on a disputed customer bill.
For utilities building the infrastructure to support a ToU rate program, SMART360's meter data management module is designed from the ground up for AMI-scale interval data — not adapted from a daily-read platform. This distinction matters when a utility is choosing between MDM systems, because the data volume and VEE processing requirements for ToU billing are categorically different from those of a monthly billing cycle.
SMART360 MDM provides:
• Native AMI integration with 25+ pre-built connectors covering major meter manufacturers including Sensus, Itron, and Landis+Gyr. Interval data flows from the meter head-end directly into SMART360's MDM processing layer without custom integration development — significantly reducing the time and technical risk of AMI deployment for utilities with lean IT teams.
• Interval-level VEE processing with configurable rules by meter type, rate class, and time window. Estimation methodology is documented at the interval level, supporting the audit trail requirements that state PUC ToU billing compliance reviews require.
• Direct integration with SMART360's billing module, which is built to receive interval records and apply ToU rate schedules natively. The MDM-to-billing handoff does not require a data translation layer — both modules share the same data model, which eliminates the timestamp alignment and field-mapping failures that commonly break ToU billing implementations.
• Cloud-native architecture that scales interval data storage without on-premise infrastructure investment — directly relevant for small and mid-sized municipal utilities that operate with two- or three-person IT teams and no server room expansion budget.
SMART360's implementation timeline for a utility transitioning from a legacy metering environment to AMI-enabled ToU billing is typically 12 to 24 weeks, covering AMI integration configuration, VEE rule setup for interval data, billing system rate schedule configuration, and staff training for the interval-level billing cycle.
The Island Water Authority implemented SMART360 and achieved a 47% reduction in operational costs — a result driven in part by consolidating MDM, billing, and customer operations onto a single integrated platform rather than managing separate point solutions.
SMART360 is priced on a pay-per-meter model. For a small or mid-sized municipal utility evaluating whether ToU billing infrastructure investment is financially viable, this means the MDM platform cost scales with actual meter count — not an enterprise licence structure designed for utilities significantly larger than your service territory. For details on the MDM module capabilities, see meter data management software.
Time-of-use billing requires Advanced Metering Infrastructure (AMI) capable of collecting sub-hourly reads — typically 15-minute or 30-minute intervals. AMR systems that deliver one daily accumulated read cannot support ToU billing because they cannot capture when within the day consumption occurs. AMI deployment is the prerequisite hardware step; meter data management (MDM) is the software layer that validates and processes the resulting interval data before it reaches billing. Without both in place, a ToU rate schedule cannot be applied.
VEE — Validation, Estimation, and Editing — is the process MDM applies to every interval read. Validation checks each read against expected consumption ranges and historical patterns for that meter; reads outside thresholds are flagged as exceptions. Estimation fills missing intervals using load profile data from comparable accounts in the same rate class. Editing allows billing staff to review and correct flagged intervals, with every change logged by editor identity, timestamp, and reason code for regulatory audit trail purposes.
A single meter on a 15-minute read cycle generates approximately 35,040 reads per year. For a utility with 20,000 meters, that is approximately 700 million interval records annually that must be collected, validated, stored, and handed off to billing before each billing cycle closes. MDM platforms built for AMI handle this volume by design. Systems adapted from daily-read architectures often face storage and processing constraints at this scale that require significant re-engineering.
Yes. MDM platforms that support multiple rate classes allow a utility to apply ToU billing to AMI-equipped accounts while maintaining flat-rate monthly billing on AMR or manual-read accounts within the same system. The billing platform must also support simultaneous rate types and generate line-item bills differently for each class. This mixed-rate scenario is standard during the AMI rollout phase, when utilities are incrementally upgrading metering infrastructure while managing a phased transition to time-differentiated rates.
Bynry Inc.
111 Galestown Cir
Chesterfield, NJ 08515
+1 732-630-0285
Bynry Inc.
Serene Tower, Pakharbaug
Pune, Maharashtra 411021
+91 93252-51217
