A utility billing software evaluation checklist is a structured set of capability tests covering billing engine accuracy, meter data integration, compliance, and customer experience -- used to identify gaps in a vendor's platform before signing a contract. Most vendor demos are built around what the software does well, not around the exceptions and edge cases that drive real operational costs. This checklist covers 12 specific capabilities to probe in every demo, organized by the five areas where billing platforms most commonly fail.
Your current billing system ran the last rate increase fine. It processes reads, generates bills, and takes payments. From the outside, it looks like it works. But your exception queue runs to 300 items every billing cycle. Your team spends two days each month manually reconciling estimated reads. And the last AMI upgrade your utility deployed? The billing platform still cannot ingest the data natively, so someone exports a CSV and imports it by hand.
That is not a billing system problem. That is a billing platform capability problem. And it is exactly what a vendor demo will not show you, because demos are built around what the software does well, not around the specific gaps that are costing your utility revenue and staff hours every month.
Before you evaluate vendors, review what a modern utility billing software platform should handle natively: multi-rate billing, AMI/MDM integration, exception management, and compliance reporting. For a deeper look at the operational and financial consequences of running on a platform with capability gaps, see how outdated billing software creates risk and cost for utilities.
The 12 features below are organized into five capability areas. Work through them in order. The vendors who can answer every question specifically, with live demonstrations and reference customers at your meter count, are the ones worth shortlisting.
Does your billing engine handle rate complexity without requiring a vendor support ticket for every rate update?
The billing engine is where revenue is either captured correctly or lost to errors, estimates, and exceptions. For a structured framework on sequencing your evaluation and comparing platforms, see how to choose utility billing software.
What it must do: Handle tiered rates, time-of-use rates, seasonal rate structures, and inclining block rates without manual workarounds. Rate tables must be configurable by utility staff, not require a vendor change request.
Weak implementation looks like: The system supports flat-rate billing natively but treats tier structures as custom configurations requiring vendor intervention for every rate change.
Ask your vendor: "Show me how a staff member updates our tiered rate structure after a board-approved rate change. How long does it take? Does it require a support ticket?"
What it must do: Run the full billing cycle from meter read validation through bill generation automatically, with an exception queue that flags anomalous reads for staff review before bills are issued.
Weak implementation looks like: The system generates bills but routes all exceptions to a general inbox or spreadsheet for manual review. Staff have no visibility into exception status until a customer complaint arrives.
Ask your vendor: "Walk me through what happens when the system detects a read that is 40% higher than the same-period read last year. What does the exception workflow look like? How does staff resolve it?"
SMART360: Utilities switching to automated exception management on SMART360 report fewer billing errors within 12 months of go-live.
What it must do: Process billing adjustments, credits, and refunds within the billing workflow, with an audit trail that ties back to the original bill and the staff member who approved the change.
Weak implementation looks like: Credits are processed outside the billing platform, requiring manual journal entries and creating no native audit trail.
Ask your vendor: "How does a billing manager process a credit for a leak adjustment? Show me the adjustment workflow from request to account update, including the audit trail entry."
What it must do: Generate billing accuracy reports showing exception rates, estimated-read percentages, and billing cycle completion rates by billing period, district, and meter type. Every bill must carry a full audit trail.
Weak implementation looks like: The system generates bills but offers no native reporting on billing accuracy metrics.
Ask your vendor: "What billing accuracy reports does the system generate natively? Can I see what percentage of last month's bills were estimated reads versus actual AMI reads?"
Can your billing platform handle both AMI and AMR meter populations simultaneously without separate billing runs?
The accuracy of every bill your utility issues depends on what happens between the meter and the billing engine. AMI integration is the most common capability gap in legacy billing platforms and the most expensive to discover after go-live.
What it must do: Integrate directly with your AMI and MDM systems using pre-built connectors, not a middleware layer requiring separate licensing, maintenance, and custom development. Native integration means meter reads flow into the billing engine automatically, with no manual file transfers.
Weak implementation looks like: The vendor offers integration via third-party middleware. Every AMI firmware update or meter network change requires a middleware configuration change and potentially a new statement of work.
Ask your vendor: "Is your AMI integration native or middleware-dependent? Which meter manufacturers and MDM platforms do you integrate with out of the box?"
SMART360: SMART360 supports 25+ pre-built integrations including Sensus, Itron, Landis+Gyr, and major MDM platforms.
What it must do: Automate VEE processing for incoming meter reads: validate against historical consumption and expected ranges, apply estimation algorithms for missed reads, and provide an editing workflow for staff to review and override automated decisions before billing.
Weak implementation looks like: VEE processing is manual. Staff review exception reports and classify reads by hand, with no automated validation against consumption history.
Ask your vendor: "Walk me through your VEE workflow. What validation rules does the system apply automatically? How does staff override an automated estimation?"
What it must do: Support real-time meter data ingestion for AMI-enabled meters and batch ingestion for AMR systems in the same platform. For utilities with mixed meter populations, the system must handle both simultaneously.
Weak implementation looks like: All meter data processes in a single batch at end of billing period. Utilities deploying AMI face a capability gap from day one of their AMI rollout.
Ask your vendor: "Our meter population is 60% AMR and 40% AMI. How does your system handle both data types simultaneously? What changes at full AMI deployment?"
Does your vendor hold a current SOC 2 Type II certification and can they produce the audit report during the evaluation?
These two capabilities are not negotiable for any US utility. Your billing platform is part of your compliance infrastructure: treat it accordingly when reviewing vendor contracts.
What it must do: Generate regulatory reports (consumption reporting, billing cycle compliance reports, revenue reporting for PUC filings) directly from the billing platform, without manual data extraction. Report templates must be configurable to match state-specific PUC formats.
Weak implementation looks like: Regulatory reports require exporting billing data to a spreadsheet and manually formatting it to match the submission format.
Ask your vendor: "Which regulatory reporting formats does your platform support natively? Can you show me a state PUC billing compliance report generated directly from the system?"
What it must do: Hold a current SOC 2 Type II certification. All customer account data, billing records, and payment information must be encrypted at rest and in transit (AES-256 minimum). The vendor must conduct annual penetration testing.
Weak implementation looks like: The vendor holds a SOC 2 Type I certification (a point-in-time assessment) but cannot provide Type II documentation or penetration testing results.
Ask your vendor: "Can you provide your most recent SOC 2 Type II audit report? What is your penetration testing schedule and who conducts it?"
How much of your inbound customer service volume is billing questions a self-service portal should handle?
Billing-related calls are the single largest driver of inbound call volume for most utility customer service teams. These three capabilities determine whether your billing platform actively reduces your service desk burden.
What it must do: Provide a mobile-responsive self-service portal connected live to the billing platform, showing real-time account balance, bill history, usage history, and payment status. Customers must be able to submit service requests, enroll in autopay, and go paperless without calling your office.
Weak implementation looks like: The portal exists but operates on a 24-48 hour data sync lag. Portal and billing records regularly disagree.
Ask your vendor: "How often does the portal sync with the billing platform? If a customer makes a payment at 2pm, what do they see when they log in at 4pm?"
What it must do: Accept payments through at minimum four channels: online web portal, mobile app, IVR, and ACH/credit card autopay. Each channel must update the billing record in real time.
Weak implementation looks like: Online payment routes through a third-party processor not integrated with the billing platform. Staff must manually reconcile payment records each morning.
Ask your vendor: "Which payment channels are native to your platform versus handled through third-party processors? What is the payment reconciliation frequency?"
What it must do: Give customer service staff a unified account view showing billing history, payment history, usage history, open service requests, and active exceptions in one screen, updated in real time.
Weak implementation looks like: Customer service staff work from three separate screens. There is no unified account view and staff copy account details between windows to answer basic questions.
Ask your vendor: "Show me what a customer service rep sees when a customer calls to dispute their bill. How many systems does the rep access during that call?"
For a comparison of how leading billing platforms perform against these criteria, see the best utility billing software buyer's guide.
Use this two-tier framework to prioritize your evaluation:
| Must-Have (Disqualifying if absent) | Nice-to-Have (Negotiate or roadmap) |
|---|---|
| Multi-rate and usage-based billing (Feature 1) | Advanced demand forecasting analytics |
| Exception management workflow (Feature 2) | Outage notification integration |
| AMI/MDM native integration (Feature 5) | GIS mapping within billing view |
| VEE automation (Feature 6) | Customer consumption benchmarking |
| SOC 2 Type II certification (Feature 9) | Multi-language portal support |
| Regulatory reporting automation (Feature 8) | Integrated capital planning module |
| Real-time customer portal (Feature 10) | AI-powered usage anomaly alerts |
Prioritize the billing engine and meter integration layer before evaluating the customer portal or reporting dashboards. The most common post-implementation problems (billing errors, revenue leakage, and compliance gaps) originate in exception management, AMI/MDM integration quality, and VEE automation. If a vendor cannot demonstrate these three capabilities in a live system, the surface-level features will not compensate.
For a utility between 5,000 and 100,000 meters with reasonably clean data, a modern cloud-native billing platform should go live in 12-24 weeks. Implementations exceeding six months typically reflect data migration complexity, custom development requirements, or vendor resource constraints. Any vendor quoting 12-18 months for a standard deployment warrants a direct question about what specifically drives that timeline.
AMI (Advanced Metering Infrastructure) refers to the two-way communication network between meters and the utility's head-end system. MDM (Meter Data Management) refers to the software layer that validates, stores, and manages the data collected by the AMI network before it reaches the billing system. If that billing-to-MDM integration is middleware-dependent rather than native, any change to the MDM system can disrupt the billing data feed.
Three indicators to examine: the size of your exception queue as a percentage of total billing accounts each cycle (anything above 2-3% warrants investigation); the percentage of bills in the last cycle based on estimated reads rather than actual AMI or AMR reads; and the gap between metered consumption and billed consumption across your system. Utilities with aging CIS platforms and limited exception automation consistently find measurable revenue leakage when they run this audit.
The 12 capabilities in this checklist cover the areas where billing platforms most commonly fail utilities after go-live. A vendor who walks through every item with a live demonstration, specific reference contacts, and direct answers to the vendor questions is a vendor whose system performs the way the demo shows. Vendors who deflect, show slides instead of live systems, or cannot produce SOC 2 Type II documentation are signaling capability limitations before the contract is signed.
For utilities that have completed the feature evaluation and are now modeling the total financial commitment, see the utility billing software total cost of ownership guide for a five-year cost framework covering licensing, implementation, migration, and hidden costs.
Bynry Inc.
111 Galestown Cir
Chesterfield, NJ 08515
+1 732-630-0285
Bynry Inc.
Serene Tower, Pakharbaug
Pune, Maharashtra 411021
+91 93252-51217
