Write a utility billing software RFP that gets comparable answers. See the sections to include, questions to ask vendors, and where to post it.
A utility billing software RFP is the document you issue to vendors to solicit competitive, comparable proposals for a new billing or customer information system. A strong one states your requirements, rate complexity, integrations, data-migration scope, and evaluation criteria clearly enough that vendor answers can be scored side by side. This guide covers what to include, the questions that separate a real fit from a good demo, and where to post the RFP so qualified vendors actually see it.
Buying billing software is one of the highest-stakes procurements a utility makes, and the RFP is where most of the risk is either controlled or created. A vague RFP produces vague proposals, incomparable pricing, and a selection you cannot defend to the board. A precise one forces vendors to answer the questions that matter and gives you a scorecard you can stand behind.
This guide is for water, electric, and gas utilities serving roughly 3,000 to 100,000 connections that are preparing to replace a billing or CIS platform. It is written from the buyer's side. If you are still deciding what you need before you write anything, start with a clear picture of your requirements and how modern utility billing software is structured, then use the sections below to turn that into a document vendors can respond to.
Does your draft RFP tell a vendor enough to price the work accurately, or will every proposal come back full of assumptions?
A billing software RFP is only as good as the detail it gives vendors. Thin requirements produce padded, defensive pricing. Include these sections at minimum:
The pricing format matters more than utilities expect. If you let each vendor structure pricing their own way, you cannot compare them. Specify the delivery model you want priced, and it helps to understand the range of utility billing services first, because a hosted platform, an outsourced service, and a licensed install price completely differently.
Is your timeline built around your billing cycle and budget calendar, or did you pick dates at random?
Writing the document is half the job; running a clean process is the other half. Follow these steps in order.
When proposals arrive, will they be comparable line for line, or will you be reconciling several different formats by hand?
The attachments do as much work as the narrative. Requiring vendors to complete standardized forms is what makes proposals comparable and pricing auditable, which is why public RFPs lean on fixed exhibits rather than open-ended responses. Common attachments to require:
Standardizing these up front prevents the most common evaluation problem: proposals that cannot be compared because each vendor answered in its own format.
Which vendor answers would actually change your decision, and are you asking those questions in writing?
Demos show the software at its best. The RFP is where you ask the questions that reveal fit under pressure. Put these in writing and require specific answers, not marketing responses.
| Question to ask | Why it matters | What a strong answer looks like |
|---|---|---|
| How does the system handle our full rate schedule? | Rate complexity is where legacy systems fail and change requests pile up | Configured in the admin UI, not a billable custom build |
| What does data migration cost and how accurate is it? | Migration is the top implementation risk and hidden cost | A defined process, accuracy standard, and validation cycles |
| Which integrations are pre-built versus custom? | Custom connectors add cost and fragility | Named pre-built connectors for your ERP, AMI, and payments |
| What is the implementation timeline for our size? | Unrealistic timelines signal underscoping | A phased plan with milestones matched to your connection count |
| What happens if the first billing cycle fails? | Cutover risk can expose your revenue | A rollback plan through the first validated billing cycle |
| Who supports us after go-live, and for how long? | Support quality determines long-term cost | A named contact and defined service levels, not a ticket queue |
Turn these into a scored section rather than open-ended prose, and pair the RFP with a structured utility billing software evaluation checklist so your team scores every vendor the same way.
Have you decided how you will weight each criterion before proposals arrive, or will you rationalize it afterward?
Publishing your scoring criteria and their relative weight inside the RFP is what makes the selection defensible. Vendors write to what you weight, and your team scores consistently. Public utility RFPs commonly score on the criteria below.
| Evaluation criterion | Relative weight | What it measures |
|---|---|---|
| Functional fit | Highest | How completely the system meets your billing, rate, and CIS requirements |
| Cost | High | Total cost across license or subscription, implementation, and support |
| Demonstrations | High | How the software performs on your own data scenarios, not a canned demo |
| Implementation approach | Moderate | Realism of the timeline, migration plan, and staffing for your size |
| References | Moderate | Outcomes at comparable utilities you can actually call |
| Vendor stability and support | Moderate | Financial standing, support model, and long-term viability |
| Local preference or certifications | Varies | Local-vendor or certification credit where your procurement rules allow it |
Weighting these in advance, and stating the weights in the RFP, is what separates a scored decision from a popularity contest after the final demo.
Do your terms protect the utility if the project goes wrong, or only describe the software you want?
Public and municipal utilities carry obligations a private buyer does not, and the RFP has to reflect them. Beyond features, require clear terms on:
These are what protect the utility and the ratepayers if a project underdelivers. If your procurement also touches meter data, the same rigor applies, and the MDM RFP evaluation guide covers the meter-data side of the same purchase.
An electric utility RFP carries requirements a water RFP does not. Specify how the system handles complex electric rate structures, time-of-use and demand billing, net metering for distributed generation, and any regulatory reporting your commission requires. If you run or plan an AMI deployment, require the vendor to detail how meter data flows from the head-end system into billing, because that integration is where electric billing accuracy is won or lost.
If you are the buyer, are you reaching the vendors who fit your size, or just the ones who happen to find your website?
Utilities post RFPs to public procurement channels so vendors can find and respond to them, and vendors watch those same channels for opportunities. As a buyer, post your RFP to your own procurement page and to the utility RFP databases and bid boards vendors monitor, such as DemandStar, BidNet Direct, Bonfire, and your state or regional procurement portal. Posting widely gets you more proposals; directly inviting a shortlist of platforms that fit your size gets you better ones. It helps to build that shortlist in advance from a comparison of the best utility billing software, so your RFP reaches vendors who can actually serve a utility your size.
At minimum: background and scope, functional requirements, your full rate and billing complexity, integration requirements, data-migration scope, implementation and support expectations, and clear evaluation criteria with a required pricing format. The pricing format is critical, because if each vendor structures pricing differently you cannot compare proposals. The more specific you are about rate complexity and integrations, the more accurate and comparable the proposals you receive.
Plan for two to four months from publishing to award for most mid-sized utilities. Give vendors three to four weeks to respond, then allow time for scoring, finalist demos on your own data, reference checks, and internal approval. Rushing the evaluation is where utilities pick the best demo instead of the best fit, so schedule the process around your billing cycle and budget calendar rather than a fixed deadline.
The questions that reveal fit under pressure: how the system handles your full rate schedule, what data migration costs and how accurate it is, which integrations are pre-built versus custom, the implementation timeline for your size, what happens if the first billing cycle fails, and who supports you after go-live. Weak vendors answer these with marketing language; strong vendors answer with specifics, named connectors, defined processes, and a rollback plan.
Set the weights before proposals arrive and publish them in the RFP. Functional fit and cost usually carry the most weight, followed by demonstrations on your own data, implementation approach, references, and vendor stability. Public procurements may also add a local-vendor or certification credit where the rules allow. Deciding and disclosing the weights up front is what makes the award defensible, because vendors respond to what you weight and your team scores every proposal the same way.
Require standardized exhibits so proposals are comparable: a milestone-based cost workbook with no "to be determined" lines, a functional requirements matrix, a data-conversion scope sheet, an implementation and staffing plan, a references form, company background and financial standing, and signed acknowledgment of every addendum with the insurance and compliance certifications your procurement rules require. Standard forms are what let you score pricing and capability line for line instead of reconciling several formats.
A utility billing software RFP is not paperwork, it is the instrument that makes vendor proposals comparable and your selection defensible. Specify your requirements, force specific answers to the questions that matter, protect the utility with clear terms, and post it where qualified vendors will see it. When you are ready to see what a modern platform puts on the table, review how a unified utility billing software platform handles rates, integration, and migration, the three areas where most RFP answers separate the real fits from the rest.
Bynry Inc.
8 The Green STE.R,
Dover, Kent,
Delaware 19901
+1 732-630-0285
Bynry Inc.
Serene Tower, Pakharbaug
Pune, Maharashtra 411021
+91 93252-51217
