Community Solar Subscriber Management Software: Why the Credits You Allocated and the Credits the Utility Actually Posted Never Agree

The month the credits arrived late and wrong

A developer runs 14 projects across three states with roughly 4,200 subscribers. On the fifth of the month the production data lands from the monitoring portal. Allocation runs, subscriber invoices go out at the discounted value of the credits each subscriber is expected to receive, and the finance team books the revenue.

Then the utility credit files arrive, on three different days, in three different shapes. One utility posted credits at a rate that differs from what the allocation assumed. Another posted nothing for eleven accounts because those customers had moved and the utility closed the account without telling anyone. A third sends a correction file in the following cycle that restates credits for two months back. Meanwhile a subscriber calls billing support and says their utility bill shows a credit of one amount while the invoice from the developer was calculated on another, and asks, reasonably, which one is right.

By the end of the quarter the asset manager wants subscription percentage per project, credit realisation rate and churn, and the honest answer is that all three are approximations built in a spreadsheet from files that do not agree. On assets financed against twenty year cash flows, approximations are an expensive habit.

Problem one: allocation is a ledger, not a percentage

The naive model gives each subscriber a percentage of a project and multiplies it by monthly production. Reality breaks that in several ways at once.

• Subscribers sized to their own consumption end up over allocated in high production months, and the surplus either banks, expires or gets wasted depending on the programme.
• Churn leaves capacity stranded mid month, and whether the departing subscriber's share reallocates immediately, at the next cycle or not at all depends on the utility's rules.
• Low and moderate income carve outs have to be maintained as a floor at all times, so a churn event in that segment cannot be backfilled with just anyone from the waitlist.
• Anchor offtakers with contractual minimum allocations constrain everything else.
• Projects with a construction ramp or a partial energisation have production that does not map to the full nameplate the subscriptions were sold against.

The correct model is an allocation ledger with effective dated entries, where every change is a dated transaction with a reason, and the state of any project on any past date can be reconstructed. That is the only way to answer the question an asset manager or an auditor will eventually ask: what exactly was this project's subscribed percentage on the last day of Q3, and who held each share.

Problem two: every utility posts credits differently and corrects them differently

This is the part outsiders underestimate. Credit mechanics are set at the programme level and executed at the utility level, so the same state can give you two utilities with meaningfully different behaviour. Some deliver a subscriber level credit file on a predictable calendar. Some post credits to the customer's bill and give you a summary that arrives days later. Some restate prior periods without a clear correction marker, so the only way to detect the change is to compare the new file against what you already recorded.

Layer the programme differences on top and the complexity is real rather than theoretical. New York's value stack, Illinois Shines, Massachusetts SMART and Minnesota's garden programme each define eligibility, credit valuation and consumer protection differently. A platform designed around one state's mechanics has to be bent to serve another, and the bending happens in spreadsheets maintained by whoever knows that market.

What a build does is separate the canonical credit event from the utility specific ingestion. Each utility gets an adapter that parses its file and emits credit events with a period, an account, a value and a source reference. Corrections become new events that supersede rather than overwrite, so the audit trail survives. Then the reconciliation report compares allocated, invoiced and posted for every subscriber every month, and the exceptions queue is ranked by dollars rather than by date.

Problem three: churn is a revenue event and it is usually handled by email

Community solar subscription is easy to leave, in most programmes deliberately so. A subscriber moves, closes the utility account, or simply cancels within the window their state disclosure grants them. Every one of those is capacity going dark, and the meter that matters is time to backfill.

Most developers we talk to handle this with a shared inbox, a spreadsheet of waitlisted applicants, and someone calling down the list. The result is capacity stranded for one or two production months, which on a project financed to a subscription assumption is a direct hit to the cash flow the lender modelled.

Automating it is not glamorous work and it pays quickly. A departure triggers a backfill task with the segment constraint attached, meaning a low and moderate income share can only be filled from qualified applicants. The waitlist is pre qualified in advance, including utility account validation, so an offer can be accepted and enrolled the same week rather than starting verification from scratch. Time to backfill becomes a number on the dashboard that the operations lead is measured against, which is usually enough on its own to move it.

Problem four: income verification is a document workflow, not a checkbox

Where a programme requires low and moderate income participation, qualification usually rests on documentation: an income statement, a benefits enrolment letter, or a geographic or categorical eligibility proof depending on the state. Those documents arrive as photos of paper, they contain personal financial information, and they have retention and access obligations.

Handling them in a shared drive is both an operational drag and a privacy exposure. A build should treat verification as a workflow with document capture, reviewer assignment, an approval record tied to the subscription, expiry where the programme requires recertification, and access controls that keep the documents away from everyone who does not need them. The same workflow produces the compliance evidence the programme administrator asks for, which otherwise gets assembled by hand each reporting period.

Where Arcadia, Ampion and PowerMarket actually fit

Arcadia has the strongest utility data connectivity in this space and the largest reach, and for a developer who wants subscriber acquisition and management handled as a service it removes a genuine burden. The trade is structural. You are renting the platform and often sitting behind their relationship with the subscriber, the economics are a share of your project revenue, and the subscriber experience is theirs rather than yours. Developers building a consumer brand feel that constraint before they feel any functional gap.

Ampion is a managed service and is good at being one. If your team is small and you would rather not run billing operations, that is a legitimate answer. What you inherit is their process, so unusual programme structures or a distinctive commercial offer tend to become exceptions handled manually on their side, which you pay for and cannot see into.

PowerMarket is more configurable and sits closer to being a platform you operate. Coverage varies by market, so the practical question is whether the utilities you deal with are already supported and how quickly a new one gets added when you enter a state.

None of these is a bad choice at the right stage. The reason developers move off them is rarely a missing feature. It is that once you hold a portfolio across several states, the reconciliation, the churn economics and the investor reporting become your core operating discipline, and you cannot run your core discipline inside someone else's model.

What this costs and how long it takes

Based on what Digital Heroes has delivered in energy and subscription billing, the bands are as follows. A first release with the allocation ledger, production ingestion, utility credit adapters for your current markets, subscriber invoicing and the three way reconciliation runs $60,000 to $130,000 and ships in 12 to 16 weeks. Adding churn and waitlist automation, income verification workflow, disclosure and consent capture, a subscriber portal and asset owner reporting takes the total to $150,000 to $400,000 over 6 to 12 months.

Cost drivers specific to community solar: the number of utilities you take credit data from, since each is an adapter with its own correction behaviour. The number of state programmes, because eligibility, disclosure and carve out rules become separate rule sets. Consolidated billing where a state offers it, which changes the invoicing model entirely. And payment processing with ACH and card handling for a residential base, including the dunning path for subscribers who stop paying while still holding capacity.

How to choose a developer for community solar software

Ask them to design the allocation model on a whiteboard. If they draw a percentage field on a subscriber record, they will not survive the first correction file. You want to see dated ledger entries and a way to reconstruct a project's subscription state on a past date.

Ask what happens when a utility restates credits for a period you already invoiced. The answer should involve superseding events and a credit note path, not an update statement.

Ask how they would handle income verification documents, and listen for access control and retention rather than file upload. This is personal financial information belonging to households, and it should be treated that way from the first sprint.

Ask which utility credit formats they have actually parsed, by utility name. Community solar experience is specific, and a developer who has done subscription billing generally will still be learning your correction behaviour on your budget.

Ask who owns the repository and the infrastructure accounts, and put it in the contract before kickoff. At Digital Heroes the client owns the code from the first commit. A concrete next step: take last month and calculate, for one project, the total value you allocated, the total you invoiced and the total the utility actually posted. The gap between those three numbers, annualised across your portfolio, is the business case and nobody has to argue about it.