Street Light Management Software: How Do You Prove What the Utility Is Billing You For?

You are paying a bill nobody can check

An unmetered street lighting bill is not a measurement. It is an arithmetic exercise: a count of fixtures, by wattage class, multiplied by an assumed number of annual burn hours from the tariff sheet, multiplied by a rate. The count comes from a file the utility maintains. Your city has usually never audited that file against the poles that actually exist.

Here is the specific way this goes wrong. Ten years ago your city converted a corridor from 250 watt high pressure sodium to LED. The contractor did the work. Somebody told the utility, on a spreadsheet, by email. Half the records got updated. Since then a developer dedicated a subdivision to the city and those lights were never added at all. Three poles were knocked down and never replaced, but they are still on the billing file. And when the conversion crew replaced a 400 watt head with a 150 watt LED, the utility's record kept the old wattage class because the change form used the old fixture code.

Every month you pay against that file. Nobody in Public Works can reconcile it because the utility's file has their identifiers, your GIS layer has yours, and the field has neither. The first honest inventory a city does after a conversion almost always finds discrepancies in both directions, and the direction that matters is the one where you have been paying for wattage you no longer draw.

The second bill nobody can check: the savings guarantee

If your LED conversion was financed through an energy savings performance contract, someone guaranteed a savings figure and you are paying against it. Verification under measurement and verification protocols for lighting retrofits is usually a stipulated calculation rather than metered consumption, because these circuits are unmetered by definition. That means the verification is only as good as the fixture count and the wattage assignment. Which is the same register you cannot currently trust.

Councils ask about this. A council member who reads the ESPC schedule will ask, in a public meeting, whether the guaranteed savings are being realised. The correct answer requires you to state how many fixtures of what type are operating and for how many hours, and to have that traceable to something other than the contractor's closeout spreadsheet.

Outages: residents find them, and the fix takes two weeks

Without controllers, the outage detection system is a resident driving home at 11pm. They report it to 311, or on Facebook, or by calling a council office. The report says the light is out near the corner of Elm and Fifth, which describes four poles. A crew is dispatched with a work order that has no pole identifier on it, spends time locating the right one, finds it needs a part they did not bring, and comes back. The resident calls again in the meantime and creates a second ticket for the same pole.

Even in areas where you do have networked controllers, the alarm goes into the controller vendor's portal, which is a different system that the maintenance crew does not use. So the outage is known by a machine and unknown by the person with the bucket truck.

This matters beyond service quality. Outage duration on a street the city owns is a liability conversation after a night time collision or an assault, and the question in a deposition is when you knew and what you did. A ticket in one system, an alarm in another and a work order in a third is not an answer.

What Telensa, Itron, Signify, Ubicquia and Tvilight actually give you

• Telensa built a control system around its own telecells and network. Where deployed it does dimming, scheduling and fault reporting competently. The asset model is theirs and it covers the nodes they sell, which is the heart of the issue: your inventory includes lights with no node on them and they are invisible to a control management system.
• Itron Streetlight.Vision is a mature control management system that supports multiple node vendors, which is a genuine advantage in a city that has bought controllers in three waves. It manages control and faults. It is not built to reconcile your utility's unmetered billing file against your asset register, and that reconciliation is where the money is.
• Signify Interact City is strong inside the Signify ecosystem and is a sensible default if your luminaires and controllers are theirs. Mixed estates are where it strains, and almost every city estate is mixed after a decade.
• Ubicquia and Tvilight are hardware led, delivering devices in the standard control receptacle with their own analytics. Useful capability, same boundary: they see what they are attached to.

The pattern is consistent. These are control management systems sold alongside hardware. The city's problem is an asset, billing and work management problem that spans hardware from several vendors plus thousands of fixtures with no hardware at all. The TALQ interoperability standard exists precisely because the industry knows this, and it helps, but standardising the control interface does not give you a register, a bill check or a work order.

What a custom street lighting system has to include

The register is the foundation and it has to be honest about uncertainty. Each record is a pole with a location, ownership, a structure type, and one or more luminaires with a fixture type, wattage, control type, install date and source of truth flag. That last field matters more than it sounds: a record confirmed by a field survey in the last two years is different from a record inherited from a contractor closeout file, and the system should know which is which and show it. Cities that skip this end up with a clean looking database that is quietly as wrong as the spreadsheet it replaced.

Then build the billing reconciliation as a first class feature, because it is the one that pays for the project. Ingest the utility's unmetered billing file each cycle, match it to your register on identifier and location, and produce three lists: billed but not in your register, in your register but not billed, and billed at a wattage that disagrees with your register. Then compute the expected charge yourself from the tariff schedule, using the burn hours printed on that schedule, and show the variance. That variance report, handed to the utility with location evidence attached, is the artefact that gets bills corrected. The first run of it is usually the moment the project pays back.

Outage handling has to close a loop across three channels. Citizen reports come in from a 311 platform, a web form or a phone call. Controller alarms come in from whichever vendor systems you have. Field crews report during patrols. All three create or update one issue against a specific pole, deduplicated so that four residents reporting the same dark pole produce one work order and four notification subscriptions. The crew gets a work order with the pole identifier, coordinates, fixture type, expected part and last work history, and closes it in the field with a photo. Anything else is a crew driving to a corner and guessing.

Controller integration should be treated as several adapters behind one internal model rather than a dependency. You will change vendors, and you will operate two at once during a transition. Normalise alarms and status into your own schema so the work order flow does not care whose node reported it.

Energy and savings modelling then falls out of the register. Connected load by wattage class, burn hours from the tariff or from actual controller run time where you have it, dimming schedules where applied, and a comparison against the pre conversion baseline. This produces the number you put in front of council, and the number the ESPC savings check is measured against.

Finally, the capital programme view. Conversion projects, dark spot complaints, lighting level surveys, pole condition and knockdown replacements are all work with money attached, and they belong in the same asset context rather than in a separate project tracker.

Cost, timeline and what changes the number

A first release with the luminaire and pole register, field survey app, utility billing file reconciliation and citizen report to work order flow runs $50,000 to $110,000 over 10 to 14 weeks. The full platform adding multi vendor controller adapters, energy and savings modelling, capital programme tracking and a public facing outage map runs $140,000 to $300,000 phased over 6 to 10 months.

What raises the cost: the number of controller vendors, since each is an adapter with its own authentication and quirks. The state of your starting data, because merging a GIS layer, a utility file and a contractor closeout spreadsheet into one register with confidence flags is real reconciliation work. Integration with your existing 311 or asset management system, whether that is Cityworks, Accela, SeeClickFix or a Salesforce based portal. And whether you need a public facing map, which brings accessibility requirements and a different security posture.

What lowers it: skip controller integration in release one entirely. Register plus billing reconciliation plus work orders is the value core, and it works with zero connected nodes.

One cost that is not software: the field survey. If your register is going to be trustworthy, someone walks or drives the estate and confirms fixtures. Budget for it, do it with the app you just built, and treat it as part of the project rather than a surprise afterwards.

When you should not build this

Do not build if the utility owns the poles and the lights and maintains them under a full service tariff, and you have no conversion programme. Your leverage is a data request and a sample audit, not a system.

Do not build if you own under about 1,500 lights and your 311 volume is manageable. A well maintained GIS layer plus your existing work order system is proportionate.

Build when you own the assets and pay an unmetered tariff you cannot verify, when you are carrying a savings guarantee you cannot substantiate, when you have controllers from more than one vendor, when outage complaints reach elected officials, or when your inventory was handed to you by a conversion contractor and you have never independently confirmed it.

How to choose a developer

Ask them how they would reconcile the utility billing file against your register when the identifiers do not match. If the answer is a lookup table, they have not seen a real one. The answer involves spatial matching, fuzzy identifier matching and a human review queue for the residue.

Ask how they model a pole with two luminaires on different circuits, because your estate has them and a one to one model will corrupt your counts.

Ask what they have integrated on the controller side and on the city side. Naming Itron, Telensa or Signify specifically is different from claiming integration experience, and Cityworks or Accela integration is a known quantity to people who have done it.

Ask who owns the code, the database and the cloud accounts, in writing, before kickoff. Your lighting register is a public asset record that will outlive several vendor relationships. At Digital Heroes the client owns the repository from the first commit. A practical first step: send us your last utility billing file and your current GIS lighting layer, and we will tell you within a week roughly how far apart they are.