Who Chose Richmond’s New Utility Billing System?

 

An Investigative Look at the RFP Process Behind Project Synergy

By Brian K. Telfair | The Richmond Chronicle

Richmond unquestionably needed a new utility billing system.

Its old Customer Information System, known as Banner, was nearly 30 years old and approaching the end of its useful life. In August 2024, the City announced that it had selected Oracle to replace that system as part of what would become Project Synergy. The City said Oracle’s cloud-based platform was the most technologically advanced of the solutions it evaluated and would provide better customer service, improved disaster recovery, modern billing tools and greater self-service capabilities.

The harder question is not whether Richmond needed modernization.

It is whether Richmond's procurement and evaluation process adequately accounted for the enormous operational risks involved in replacing the system responsible for billing tens of thousands of utility customers.

That question has become considerably more important since Project Synergy went live.

The City Knew the Old System Had Problems

Long before Oracle was selected, Richmond's own auditor had documented serious weaknesses in DPU's billing operation.

A February 2023 City Auditor report concluded that internal controls over DPU billing and collections needed improvement. The audit found that accounts receivable had climbed above $60 million as of June 2022.

The problems extended directly into billing accuracy.

During FY2022, auditors found 131,106 estimated gas and water readings affecting 28,044 service lines. Nearly 9,800 service lines were estimated for at least half the year, while 3,807 were estimated for all 12 months. DPU policy generally prohibited more than three consecutive estimated readings, but auditors found that the system limit had been removed during the pandemic and that there was no process for monitoring estimated bills.

The audit also found approximately 47,000 open gas and water service orders, some dating as far back as 2001.

These findings matter to the procurement story.

Richmond was not simply replacing old software. It was attempting to migrate complicated business processes, account information and billing practices from a department already struggling with significant operational weaknesses.

That should have made the procurement process unusually rigorous.

What Did Richmond Ask Vendors to Solve?

The central document is the original solicitation.

An RFP for a utility Customer Information System should do much more than ask vendors who has the slickest software.

It should translate Richmond's existing problems into detailed requirements.

Did the solicitation specifically require solutions for consecutive estimated bills?

Did it address meter-reading exceptions?

Did it require automated controls over billing adjustments?

Did it account for old service orders, inconsistent account information and customer-service backlogs?

Did Richmond require vendors to demonstrate how their systems handled messy data inherited from a legacy platform?

Those questions are important because Richmond's 2023 audit effectively supplied a roadmap of risks before the new system was selected.

The auditor even noted that DPU anticipated using the CIS replacement to automate some internal-control processes.

In other words, Project Synergy was supposed to become part of the solution to problems the City already knew existed.

How Was Oracle Selected?

The City's August 2024 announcement provides some information, but not enough to fully evaluate the competition.

Richmond said Oracle had been selected after evaluating other solutions and described Oracle as the most technologically advanced option. DPU also cited Oracle's support for an "omnichannel" customer experience.

But that leaves several important questions unanswered publicly.

How many companies submitted proposals?

Who were they?

What were their proposed costs?

How did Richmond weight price against technical capability?

How much weight was placed on implementation experience?

Were vendors required to provide references from utilities comparable to Richmond?

What scores did Oracle and its competitors receive?

And perhaps most importantly, how heavily did Richmond evaluate implementation risk?

The phrase "most technologically advanced" sounds impressive. But municipal software does not succeed because it wins a feature contest.

It succeeds because the software, data, employees, billing rules, outside vendors and customer-facing systems all work together on Monday morning when residents expect their bills to be correct.

The RFP Should Be Examined as a Risk Document

A conventional procurement review asks whether the City followed purchasing rules.

A better investigation asks whether the procurement process actually protected Richmond from foreseeable failure.

For a project of this complexity, the evaluation should have considered at least five areas: data conversion, integration with payment and billing vendors, testing, employee readiness and contingency planning.

Those issues are especially relevant because the system involved much more than Oracle software.

When Richmond launched Project Synergy on May 26, 2026, it implemented Oracle Customer Cloud Service and Oracle Field Service, while also preparing a separate customer portal called DPU Connect.

That created an ecosystem rather than a single piece of software.

Every connection became another possible failure point.

Then Came Go-Live

The contrast between the City's launch announcement and what followed deserves scrutiny.

On May 26, DPU announced that implementation had been successfully completed. The City said there had been extensive testing, training, dress rehearsals and validation. It reported that its final bill-validation exercise produced a 99.7% success rate.

Days later, the City acknowledged a system error affecting utility payments. Some payments had been received but were not properly applied to customer accounts.

Subsequent updates acknowledged additional billing and payment-processing problems following the launch, including issues involving third-party vendors. The City temporarily suspended disconnections, paused flow restrictor installations and removed related late fees while problems were addressed.

That does not prove Oracle was improperly selected.

Nor does it prove the RFP was defective.

But it creates an obvious investigative question:

If testing showed a 99.7 percent successful bill-validation rate, why did significant customer-facing problems emerge almost immediately after launch?

The answer may lie outside Oracle entirely.

It could involve payment processors, bill printers, interfaces, configuration, business rules or implementation decisions.

But that is precisely why the procurement documents matter.

Did Richmond Procure a System or an Outcome?

This may be the most important distinction.

Governments sometimes procure technology by specifying the software functions they want.

The stronger approach is to contract around measurable outcomes.

For example:

Accurate bills.

Payments posted within a defined period.

Successful migration of customer balances.

Required integration testing before launch.

Maximum allowable error rates.

Defined system uptime.

Vendor responsibility when interfaces fail.

Financial remedies when performance requirements are missed.

If Richmond's contracts contain strong service-level agreements and performance guarantees, taxpayers should know whether those provisions are being enforced.

If they do not, that raises another question about how the procurement was structured.

The Missing Public Scorecard

Richmond has explained why it believes Oracle was the best choice.

What citizens have not seen nearly as clearly is the comparative evidence behind that conclusion.

The public should be able to examine a straightforward procurement scorecard showing:

Question	What Richmond Should Disclose
Number of proposals	Every responsive bidder
Evaluation criteria	Technical, cost and implementation weighting
Proposal scores	Final scores for each bidder
Contract price	Initial and total projected lifecycle cost
Implementation partner	Roles and responsibilities
Testing requirements	Acceptance standards before go-live
Service levels	Required performance after launch
Remedies	Credits, penalties or corrective-action provisions
Change orders	Additional spending after award

Without those documents, the public is largely being asked to accept the City's conclusion that the best solution was selected.

That may ultimately prove correct.

But an investigative standard requires evidence, not simply assurances.

Richmond Had Warning Signs Before Procurement

There is another reason this procurement deserves unusual scrutiny.

The billing system inherited problems that were not technological alone.

The 2023 audit recommended formal employee training, performance measures, quality-assurance procedures, better monitoring of estimated bills and improved management oversight.

Software cannot repair weak processes by itself.

If flawed business practices are migrated into a sophisticated new system, the result can simply be old problems wearing new software.

A responsible procurement therefore should have examined DPU's business processes before determining how the technology would be configured.

That makes one document particularly important: any fit-gap analysis identifying where Oracle's standard processes differed from Richmond's existing practices.

Such a document could reveal whether Richmond changed its practices to fit the system or customized the system to preserve existing practices.

That distinction can dramatically affect cost and implementation risk.

The Richmond Chronicle's Verdict

The evidence currently available does not establish that Richmond conducted an improper procurement.

It does establish that the procurement deserves much greater public examination.

Richmond knew its existing billing operation had substantial weaknesses. It knew it was replacing a nearly 30-year-old system. It knew tens of thousands of accounts would have to be migrated. And it knew that virtually every Richmond utility customer would be affected if the transition went wrong.

The City nevertheless declared the implementation successfully completed on May 26, citing extensive testing and a 99.7 percent bill-validation success rate. Customer-facing problems emerged shortly thereafter.

That makes the original RFP, vendor proposals, scoring sheets, contracts, testing criteria and change orders more than procurement paperwork.

They are the roadmap to determining whether Richmond bought the wrong system, implemented the right system poorly, suffered failures elsewhere in the vendor chain, or encountered problems that reasonable planning could not have prevented.

Until those records are examined side by side, the most important question surrounding Project Synergy remains unanswered:

Did Richmond's procurement process merely select sophisticated software, or did it adequately protect Richmond residents from the risks of putting that software into operation?

That is the investigation City Hall should welcome, not fear.

Brian K. Telfair
Publisher & Editor | The Richmond Chronicle

Independent commentary and investigative analysis on Richmond government, public spending, economic development, and the decisions shaping the city’s future.

The Richmond Chronicle
Asking the questions City Hall would rather not answer.