DER Interconnection Queue Software: How Utilities Keep Hundreds of Solar and Storage Applications Inside a Statutory Clock

An interconnection queue is a clock, not a ticket list

The distinguishing feature of interconnection work is that the calendar is written into law. Your tariff or state rule says you acknowledge receipt within a set number of business days, tell the applicant whether the application is complete within another, run the initial review screens within another, and issue a study agreement or an approval within another. Miss any of them and the applicant does not send a polite reminder. They file a complaint with the commission, and the commission asks for your processing statistics going back three years.

That is why generic case tools break here. A ticketing system counts age. Interconnection counts a specific clock per milestone, and the clock tolls the moment you send a deficiency notice and restarts when the applicant responds, and it counts business days against a holiday calendar, and it does something different for a fast track application than for a supplemental review than for a full study. The engineer who tracks all that in a spreadsheet tab is not being lazy. No tool the utility already owns can express it.

The second thing that breaks is volume shape. Residential solar arrives in floods from a handful of installers who submit dozens of applications a week, and each one is close to identical. Commercial storage arrives in ones and twos and each is a genuine engineering study. Treating both as the same work item is how the small ones get slow and the large ones get missed.

What the shared inbox actually costs your team

Walk the process as it usually stands. An application PDF arrives by email. An analyst opens it, checks whether the single line diagram is attached, whether the inverter is on the approved equipment list, whether the site plan shows the point of common coupling. Half the time something is missing, so a deficiency email goes out and the application effectively disappears until the installer replies. Nobody tracks who is waiting on whom.

The screens run in a spreadsheet against feeder data the planning engineer pulled last quarter. Aggregate generation on the circuit is stale, so an application that should have failed the penetration screen passes, and the problem shows up months later during the study. Deposits arrive by check, get recorded in a finance spreadsheet, and refunds against actual study cost require someone to reconstruct which hours were charged to which project.

Then permission to operate. The system is built, the inspection passes, and the account still needs the net metering rate code set in the customer information system and the meter configured. That handoff usually happens by email to a billing analyst, which means the customer generates for six weeks with no credit and calls the commission about that too.

Where PowerClerk and GridUnity stop

Be fair to both products. Clean Power Research PowerClerk is genuinely strong at configurable forms, correspondence and program workflow, which is unsurprising given its heritage in incentive program administration. If your need is a well built intake form, a document checklist and templated emails, it does that and does it without a project. GridUnity is aimed further up the stack at study and queue management, and it is a serious tool for transmission scale queue processing.

What neither gives you out of the box is the part where your utility is specific. Your screens run against your feeder data in your planning model. Your cost allocation follows the cost sharing method in your tariff, which is not the method the next state uses. Your study fee schedule, your deposit refund rules, your upgrade agreement template and your permission to operate handoff into your customer information system are yours alone. So the configurable product owns the front of the process, the engineers own the middle in spreadsheets, and billing owns the end in a separate system, and the queue status field in the product is a summary of work happening somewhere else. When the commission asks how many applications missed a deadline last year and why, that summary is not evidence.

What a custom build has to include

A clock engine as a first class object, not a due date field. Every regulatory milestone becomes a configured timer with a start event, a stop event, a business day calendar, and explicit tolling rules. When you send a deficiency notice the timer pauses and the pause is recorded, because that record is your defence when the processing time is challenged.

Executable screens rather than documented screens. The screen logic reads current aggregate nameplate on the circuit and section, the line configuration, the transformer, and the applicant nameplate, then returns a pass, a fail with the reason, or a route to supplemental review. Utilities that get this right refresh circuit loading from the planning model on a schedule so screens run against something recent rather than a quarterly export.

Document validation at intake. The approved inverter list check, the certification of the equipment to the current standard, the presence of a single line diagram and site plan, and the signature block. Rejecting an incomplete application in an hour instead of a week is the single largest reduction in cycle time available to you, and it is mostly rules, not artificial intelligence.

A deposit and cost ledger. Study deposits, actual study cost, refunds, upgrade cost allocation across a group of projects, and the payment schedule attached to an upgrade agreement. This is accounting, and it has to reconcile to the general ledger, which means the build touches finance whether you planned for it or not.

Group or cluster handling if your rules allow it. Applications get grouped by circuit and window, studied together, and upgrade cost is allocated among them by the method in your tariff. Withdrawals then trigger restudy and reallocation, and the reallocation math is where disputes live, so it has to be reproducible on demand.

An installer channel. The five installers submitting most of your residential volume will use an application programming interface or a bulk portal if you give them one, because it saves them as much time as it saves you. Structured submissions from the top submitters remove a large share of the deficiency loop before it starts.

Reporting built for the commission, not for a dashboard screenshot. Applications received, completed, withdrawn, average and median days per milestone, deadline compliance by month and by class of application, all exportable and all traceable to the underlying events.

Integrations that decide the timeline

Four connections drive most of the schedule risk. The geographic information system, usually Esri, for the circuit and transformer topology. The planning model, commonly CYME, Synergi Electric or Milsoft, for circuit loading and existing generation. The customer information system for the account, the premise and the net metering rate setup, which is often the oldest and least friendly system in the building. And electronic signature plus a payment path for agreements and deposits. Scope these in discovery with the people who own them, because access approval inside a utility is measured in weeks and it is the most common cause of a slipped date.

What it costs and how long it takes

A first release covering intake with document validation, the clock engine, screens for one state rule set, and the study workflow through agreement runs $95,000 to $190,000 and ships in 14 to 20 weeks. A full platform adding cost allocation and the deposit ledger, group studies, the installer application programming interface, permission to operate handoff into the customer information system, and commission reporting runs $260,000 to $600,000 phased over 8 to 14 months.

What pushes cost up: operating in more than one state, because each rule set is a separate clock and screen configuration. Cluster study support with reallocation on withdrawal. Deep planning model integration rather than a scheduled export. Utility security review and hosting requirements, which for a regulated entity can add a month before a line of production code runs. What keeps cost down: starting with the highest volume class of application, usually residential net metered solar under a defined size, and leaving commercial storage on the existing process for one more release.

When buying is the right call

If you take fewer than about 50 applications a month, operate in one state, have no cluster or group study process, and rarely allocate upgrade costs, buy. Configure PowerClerk, connect the deposits to your existing finance process, and accept that engineering will keep a spreadsheet. The build case begins when missed deadlines are producing commission complaints, when a single application class is arriving faster than your analysts can screen it, or when upgrade cost allocation across projects has already caused a dispute you had to settle by hand.

How to choose a developer for interconnection software

Ask them to model tolling on a whiteboard before you sign anything. If they cannot explain how a deficiency notice pauses a business day timer and how that pause is evidenced later, they have built a ticketing system before and will build one again.

Ask how they will get circuit loading. A developer who says they will read the planning model export and refresh it on a schedule has thought about it. A developer who assumes a live application programming interface into your planning tool has not talked to your planning engineers.

Ask what happens on withdrawal from a group study. The reallocation rule is the hardest logic in the domain and the answer tells you whether they have read your tariff or skimmed your request for proposal.

Ask who owns the code and get it written down before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit, and any vendor who hesitates on that point is selling you a dependency rather than a system.