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 can't 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.
This checklist covers 12 specific capabilities to evaluate before you sign a contract. Each item identifies what the feature must do for a small or mid-size US utility, what a weak implementation looks like, and what to ask a vendor to prove. Use it in your next demo. Use it in your RFP. Use it when a vendor tells you their system "handles that" without telling you how.
The average utility software evaluation focuses on the front end: the dashboard, the customer portal, the bill format. These things matter — but they are not what causes billing errors. Billing errors originate in three places that most vendor demos never cover in depth: the billing engine's handling of exceptions and rate complexity, the accuracy of meter data integration, and the completeness of compliance and audit trail functionality.
Utility billing software refers to a platform that automates the full billing cycle - meter read ingestion, rate calculation, bill generation, exception management, and payment processing — for water, electric, and gas utilities. A modern platform integrates directly with AMI and MDM systems, automates regulatory reporting, and provides a customer self-service portal. It replaces legacy Customer Information Systems (CIS) that require manual data handling and offer limited integration.
The 12 features below are organized into five capability areas. Each one represents a real evaluation criterion, not a marketing category. Work through them in order. The vendors who can answer every question specifically, with live demonstrations and reference customers, are the ones worth shortlisting.
The billing engine is where revenue is either captured correctly or lost to errors, estimates, and exceptions. These four capabilities determine whether the engine actually works for a utility with rate complexity.
What it must do: Handle tiered rates, time-of-use rates, seasonal rate structures, and inclining block rates without manual workarounds. Rate tables should 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. Staff export data to a spreadsheet to calculate tiered charges.
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?"
SMART360: SMART360's billing module supports multi-rate, usage-based, and tiered billing configurations natively, with utility-managed rate tables.
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. Exception resolution should be built into the workflow, not handled outside the system.
Weak implementation looks like: The system generates bills but routes all exceptions to a general inbox or exports them to a 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.
What it must do: Process billing adjustments, credits, and refunds within the billing workflow, without requiring manual journal entries in a separate accounting system. Adjustments should carry an audit trail that ties back to the original bill and the staff member who approved the change.
Weak implementation looks like: Credits and adjustments are processed outside the billing platform. Staff manually update account balances and create separate records. The billing system has no native adjustment workflow.
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 that show exception rates, estimated-read percentages, and billing cycle completion rates — by billing period, by district, and by meter type. Every bill generated should carry a full audit trail.
Weak implementation looks like: The system generates bills but offers no native reporting on billing accuracy metrics. Management cannot see what percentage of bills in the last cycle were based on estimated reads without a manual count.
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?"
Explore SMART360's billing capabilities: SMART360 utility billing software module
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.
Three capabilities define whether a billing platform handles meter data properly.
What it must do: Integrate directly with your AMI and MDM systems using pre-built connectors — not a middleware layer that requires 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 a third-party middleware platform. 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? How many pre-built integrations do you currently support?"
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 or failed 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 manually classify reads as valid, estimated, or edited. There is no automated validation against consumption history or configurable estimation algorithm.
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 happens when an edited read is contested by a customer?"
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 without requiring separate billing runs.
Weak implementation looks like: The system processes all meter data in a single batch at end of billing period. There is no near-real-time read processing. Utilities deploying AMI face a capability gap from day one of their AMI rollout.
Ask your vendor: "Our meter population is currently 60% AMR and 40% AMI, with a phased AMI rollout over the next three years. How does your system handle both data types simultaneously? What changes at full AMI deployment?"
See SMART360's AMI/MDM integration library: meter data management and AMI integration
These two capabilities are not negotiable for any US utility. They are also the capabilities most frequently under-specified in vendor contracts, not because vendors deliberately omit them, but because procurement teams rarely push on the specifics until an audit or a data incident surfaces the gap.
Electric utilities are subject to NERC CIP cybersecurity standards. Water utilities operate under EPA Safe Drinking Water Act reporting requirements. Gas utilities face PHMSA compliance obligations. Every utility, regardless of type, is subject to state Public Utility Commission reporting requirements. Your billing platform is part of your compliance infrastructure — treat it accordingly.
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 and reformatting. Report templates should be configurable to match state-specific PUC formats.
Weak implementation looks like: Regulatory reports are generated by exporting billing data to a spreadsheet and manually formatting it to match the required submission format. There is no native reporting module for EPA or PUC filings.
Ask your vendor: "Which regulatory reporting formats does your platform support natively? Can you show me an example of a state PUC billing compliance report generated directly from the system? How are report templates updated when regulatory formats change?"
What it must do: Hold a current SOC 2 Type II certification, covering the security, availability, and confidentiality trust service criteria. All customer account data, billing records, and payment information must be encrypted at rest and in transit using current standards (AES-256 minimum). The vendor should conduct annual penetration testing.
Weak implementation looks like: The vendor holds a SOC 2 Type I certification (a point-in-time assessment, not an operational audit) but cannot provide Type II documentation. There is no documentation of 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 are our customer payment records protected and where are they stored?"
Billing-related calls are the single largest driver of inbound call volume for most utility customer service teams. Every call about a bill status, a payment question, or a usage query that your team takes manually is a call that a well-configured self-service portal should have handled. These three capabilities determine whether your billing platform actively reduces your service desk burden — or simply fails to prevent it.
What it must do: Provide a mobile-responsive self-service portal that connects live to the billing platform — showing real-time account balance, bill history, usage history, and payment status. Customers should 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 data sync with a 24–48 hour lag. Customers calling about a payment they made yesterday are told the system has not updated yet. 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? Can you show us a live demo of the portal against a test account?"
What it must do: Accept payments through at minimum four channels: online web portal, mobile app, interactive voice response (IVR), and automatic payment (ACH/credit card autopay). Each channel should update the billing record in real time and generate a payment confirmation.
Weak implementation looks like: Online payment is available but routes through a third-party payment processor that is not integrated with the billing platform. Staff must manually reconcile payment records each morning. IVR payments require a separate vendor contract.
Ask your vendor: "Which payment channels are native to your platform versus handled through third-party processors? How are payments reconciled against billing records? What is the 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. Staff should be able to identify a billing dispute and its root cause without switching between systems.
Weak implementation looks like: Customer service staff work from three separate screens: the billing system, the payment processor, and the work order system. There is no unified account view. Staff copy account details between windows to answer basic customer 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? Can they see the usage history, billing history, and any open service requests on the same screen?"
Not every capability on this checklist carries equal weight. Some gaps are fixable with configuration. Others are architectural limitations that cannot be resolved without a platform replacement. Use this two-tier framework to prioritize your evaluation.
1. "Show me a billing cycle run, from meter read ingestion through bill generation, on a test account with a tiered rate structure. Do not show me a slide. Show me the live system."
2. "What is your current SOC 2 Type II certification status? Can you provide the most recent audit report during our evaluation?"
3. "How many of your current utility clients are under 50,000 meters? Can you provide two reference contacts at utilities comparable to ours?"
4. "What does implementation look like for a utility our size? What is the realistic go-live timeline and what has caused delays for clients with similar data migration complexity?"
• The vendor quotes more than 6 months for go-live on a utility under 100,000 meters without a clear explanation tied to your specific data migration complexity. Modern SaaS platforms should go live in 12–24 weeks.
• AMI integration is described as "available" without specifying whether it is native or middleware-dependent.
• The vendor cannot provide a SOC 2 Type II report - only a Type I, or a self-assessment.
• Pricing is quoted per-user rather than per-meter. Per-user pricing penalizes utilities that add staff and creates budget volatility.
• The demo environment does not match the production environment. If the demo looks dramatically better than the reference client screenshots, ask why.
SMART360 by Bynry implements in 12–24 weeks for utilities between 3,000 and 100,000 meters against an industry average of 12–18 months for legacy enterprise platforms. Island Water Authority went live in under 8 weeks and reduced operational costs by 47%. That timeline is not typical of all deployments, data complexity matters, but it is the ceiling any modern SaaS platform should be able to approach.
See the full Island Water Authority case study: how SMART360 cut costs by 47% for Island Water Authority
Pay-per-meter pricing means your software costs scale predictably with your meter count — not with every new hire or system user you add. For a utility managing a fixed meter base, that is a structurally lower TCO than per-user licensing.
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 either data migration complexity (legacy systems with years of uncleaned data), custom development requirements driven by non-standard integrations, 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 — including the meters, communication network, and data collection 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. A billing platform integrates with the MDM layer to receive clean, validated meter reads. If that integration is middleware-dependent rather than native, any change to the MDM system can disrupt the billing data feed.
Three indicators to examine: (1) your exception queue size as a percentage of total billing accounts each cycle, anything above 2–3% warrants investigation; (2) the percentage of bills in the last cycle based on estimated reads rather than actual AMI or AMR reads; (3) the gap between metered consumption and billed consumption across your system. AWWA research suggests that revenue leakage from billing errors at utilities with legacy CIS platforms commonly falls in the 1–3% of annual revenue range — team to verify exact figure and source before publish.
