How to Automate Solar System Sizing and Financial Modeling for Customer Proposals

The Manual Proposal Tax

Watch a rep build a proposal by hand and you see where the hours actually go. A photo of the roof gets traced in one app. The customer's twelve bills get keyed into a spreadsheet to find annual usage. A sun-hours figure gets multiplied against a panel count to guess production. Then a second spreadsheet holds the money: the cash price, a loan at some rate the rep half-remembers, a federal credit applied in the wrong year, and a payback number that nobody can reproduce a week later. By the time the PDF goes out, half a day is gone and the design, the production estimate, and the savings each live in a different file.

None of that work is wrong to do. It is wrong to do by hand. Scaling a bill into a load shape, sizing an array to a target, applying the credit, and rolling the cashflow are all arithmetic with fixed rules. That is exactly the kind of work software should carry, and the kind a person should only be checking. The point of automating a proposal is not to remove the designer. It is to move the designer off the calculator and onto the decisions that actually need judgment, so the slow steps run in seconds and the output is reproducible.

This piece walks the automated path from a customer's usage and rate to a sized system and a client-ready proposal, and it is honest about the seam running through the middle: some steps the software should own outright, and some it should never be trusted to decide on its own.

What the Automation Needs From You

An automated proposal is still only as good as what you hand it. The engine can size, model, and price without you, but it cannot invent the facts it is sizing against. Gather this set before you start, and the rest of the flow runs without stopping to chase a missing number.

• The customer's annual usage in kilowatt-hours, ideally from twelve months of bills rather than a single month scaled up.
• The utility and the specific rate schedule, since a flat residential rate and a tiered or time-of-use rate size very differently.
• The address, so the tool can pull the right weather data and a roof image for the layout.
• A target: a percentage offset, a monthly bill cap, or simply the largest system the roof will hold.
• Roof facts the image does not show, including shading from trees, membrane or shingle age, and any structural concern.
• Whether the customer wants storage, and if so, whether the goal is backup, self-consumption, or demand savings.
• The financing paths to model: cash, a loan at a real quoted rate and term, or a PPA if you offer one.
• The assumptions that drive the money, meaning the utility escalation rate, the system degradation rate, and a discount rate.
• The customer's tax situation at a high level, because the federal credit only helps a buyer with tax liability to offset.
• Any state or utility incentive that applies, entered as a known value rather than an optimistic guess.

The first few items feed the sizing engine. The last few feed the financial model. Keeping them straight up front is what lets the automation run start to finish instead of stalling halfway.

Turning a Bill Into a Load Profile and a Rate

Everything downstream rests on one translation: a stack of bills becomes a usage pattern the software can model against. At the residential level this is usually annual kilowatt-hours spread across a typical load shape, since most homes bill on energy and do not have interval meters. The tool takes the twelve-month total, shapes it against a regional profile, and now has a monthly and hourly estimate of when the house draws power. On commercial work the same step pulls real interval data when it exists, which matters far more there because demand charges hinge on timing.

The rate is the other half, and it is the half reps most often get wrong by hand. A kilowatt-hour offset under a flat rate is worth the flat rate. The same kilowatt-hour under a tiered rate is worth whatever tier it would have fallen in, and under a time-of-use rate it is worth whatever that hour prices at. The U.S. Energy Information Administration explains that retail prices reflect fuel, grid investment, distribution, and regional supply and demand, and rate schedules slice those costs into parts that respond differently to solar. Automating the rate lookup means the savings are computed against the structure the customer actually pays, not a single blended cents-per-kilowatt-hour number typed in from memory.

This is a step to let the software own, with one caution. Confirm the rate it selected is the one on the bill. Utilities carry dozens of schedules, default assignments drift, and a proposal built on the wrong tariff is wrong from the first line no matter how clean the rest of the model looks.

Sizing the Panels and Battery Automatically

With usage and a rate in hand, sizing becomes a target-matching problem the engine solves quickly. You tell it the goal, offset a set percentage of annual usage, hold the bill under a number, or fill the roof, and it returns a panel count, a module layout, and an inverter configuration that hits the target on the modeled production. In Enact's Design and Proposals flow this is where the panel count and the layout get set, and where a battery count is sized alongside the array rather than bolted on after.

Battery sizing is its own decision and the automation needs direction. A battery for backup is sized to the loads the customer wants to ride through an outage and for how long. A battery for self-consumption is sized to soak up midday overproduction and release it in the evening. A battery for demand charges, on commercial jobs, is sized to shave the peak at the hour it lands. Those three goals produce three different batteries, so the tool should be told which one it is solving for rather than left to assume. Enact models the array and the battery against the same usage profile, which keeps the pairing honest instead of treating storage as a separate quote.

What the engine gives you is a candidate, not a final design. It has sized against the roof image and the usage, but it has not stood on the roof. The number it returns is the starting point for the judgment steps later in this flow, not the system you propose without looking.

Modeling Production the Software Can Trust

A panel count is not a production estimate. Real output is what the array delivers after the site's irradiance, the orientation and tilt, shading across the full year, temperature, soiling, and inverter and wiring losses all take their cut. This is the step automation does far better than any hand calculation, because the inputs are a weather dataset and a physics model, not a rule of thumb. Multiplying nameplate watts by a generic sun-hours figure skips every real-world factor and produces a number the meter will not back up.

The U.S. Department of Energy explains that a photovoltaic system's real-world performance is shaped by factors including the available solar resource, orientation, temperature, soiling, and shading, rather than by the nameplate rating on its own.

U.S. Department of Energy, Solar Performance and Efficiency

Good proposal software builds the estimate on validated weather data for the address, applies a temperature coefficient, includes soiling for the local climate, and accounts for inverter clipping when the array is oversized to its inverters. The National Renewable Energy Laboratory's PVWatts model is the public reference many tools either use or mirror, and its logic is the baseline a proposal production estimate should meet. The one input the engine cannot pull on its own is shading, which is covered below. Present the output as a modeled estimate with its assumptions stated, because on any serious deal that production number is the foundation the entire financial model stands on.

Modeling Cash, Loan, and PPA Side by Side

Once production is modeled, it converts to a dollar value, and the financing path decides how the customer actually experiences that value. The three common paths read differently, and a strong proposal shows all three rather than steering to one.

Cash is the simplest to model. The customer pays the full installed cost up front, claims any credit they qualify for, and from then on the modeled bill savings are pure return. Payback is the cash outlay divided into the annual savings, adjusted for escalation and degradation, and the lifetime return is the largest of the three because no financing cost is skimmed off.

A loan keeps the customer's cash in pocket and spreads the cost over a term at a rate. The model has to carry the real rate and term, any dealer fee folded into the principal, and the gap in the early years when the loan payment can sit close to or above the old bill before the credit is applied to the balance. EnergySage walks through how solar loan terms, rates, and fees shape the true cost, and a loan modeled without the fee or at an invented rate flatters the deal in a way the customer will notice at signing.

A PPA is different in kind. The customer buys the power the system produces at a per-kilowatt-hour rate, usually with an annual escalator, and never owns the asset or claims the credit. The model here is production times the PPA rate against the avoided utility rate, year over year, with the escalator working against the customer over time. Automating all three side by side is where software earns its place, because building three internally consistent 25-year models by hand is exactly the work that takes an afternoon and introduces errors.

Where the ITC and Incentives Enter the Model

The federal Residential Clean Energy Credit is the single largest lever in most residential models, and where it enters the math changes the answer. The credit is a percentage of eligible cost that a buyer with tax liability claims against their federal taxes, and the IRS describes it as a credit for qualified clean energy property placed in service during the tax year. It is not a rebate at purchase and not a discount the installer fronts. The model should apply it the way the customer will actually receive it, as a reduction in taxes owed in the year the system is placed in service, which for a loan usually means a separate decision about whether the customer re-amortizes the balance.

The automation handles the arithmetic cleanly, but two judgment calls stay with you. First, the credit only helps a buyer who owes enough federal tax to absorb it, so a model that assumes the full credit for a customer with little liability overstates the return. EnergySage's explainer on how the solar tax credit works is a fair reference to point customers to rather than giving tax advice yourself. Second, state and utility incentives vary widely and expire without warning, so enter them as confirmed values, not as whatever the tool last had cached. Commercial deals add their own layer through accelerated depreciation, which the Solar Energy Industries Association treats as a separate benefit that lowers the effective cost of the asset. Label every one of these as a modeled estimate and keep the tax specifics attributed.

Payback and the 25-Year Cashflow

Payback is the number customers ask for, and it is also the one most often computed too simply. A real payback accounts for the utility rate rising over time, the system producing slightly less each year as the panels degrade, and the time value of the money spent today. Dividing cost by first-year savings ignores all three and lands on a figure that drifts from reality within a few years.

The 25-year cashflow is where an honest model lives. It runs each year forward: modeled production stepped down by the degradation rate, savings valued at a utility rate stepped up by the escalation rate, financing payments where they apply, and the credit landing in its proper year. The cumulative line crosses zero at the true payback, and the final figure is the net lifetime benefit. The assumptions driving it, the escalation rate and the degradation rate in particular, matter more than any single input, which is why they belong to the designer and not to a default. An escalation rate set a point or two high can swing a 25-year total enough to make a marginal deal look strong. Keep those assumptions visible in the proposal and defensible if a customer, or a commercial finance team, tests them line by line. National cost benchmarks such as EnergySage's installed cost data give a directional check that the inputs sit in a believable range before the cashflow runs.

Manual Build vs Automated, Step by Step

The clearest way to see what automation buys you is to put the two workflows next to each other, step for step. The pattern is consistent: the slow, error-prone arithmetic moves to software, and the human effort concentrates on the few steps that need a decision.

What Still Needs Human Judgment

Automating the arithmetic does not mean trusting the output blind. A few steps sit outside what the engine can decide, and skipping the human check on them is how a clean-looking proposal turns into a problem at install.

Shading is the clearest example. The tool can pull a roof image and model production, but it cannot see the oak that shades the southwest plane every afternoon or the neighbor's addition going up next spring. A real shade study, whether on-site or from a measured horizon, feeds the model a factor it cannot derive from an aerial photo, and on a tight roof it can move the production estimate by a meaningful margin.

Structural and roof condition is the next. An engine sizes against area, not against whether the roof can carry the load or has enough membrane or shingle life left to justify a 25-year array. Mounting a long-lived system on a roof with a few years left forces an expensive removal and reinstall partway through, and only a person looking at the roof catches that.

The rate and incentive confirmations covered earlier are judgment calls too, as is the final sanity check. Before anything reaches the customer, a designer should read the finished model the way a skeptical buyer would and ask whether the payback, the offset, and the assumptions hold together. The Department of Energy's homeowner's guide to going solar frames the questions a buyer should bring, and a proposal that answers them before they are asked is one a person has actually checked.

Where Automated Proposals Go Wrong

Automation does not remove errors. It changes which errors you make and lets you make them faster, so the failures below are worth knowing before they ship a hundred proposals built on the same bad assumption.

Running on default assumptions. The escalation rate, degradation rate, and discount rate often ship with optimistic defaults. Leave them untouched and every proposal inherits a rosy bias that a finance-savvy customer will spot.

Trusting the tool's rate selection blindly. Utilities carry dozens of schedules and default assignments drift. A model built on the wrong tariff is wrong from the first line, however polished the output looks.

Skipping the shade study. An aerial image does not show the tree or the future obstruction. Letting the engine model production with no real shading input inflates the kilowatt-hours and the savings together.

Applying the ITC to a customer who cannot use it. The credit only helps a buyer with federal tax liability. Assuming the full credit for someone with little liability overstates the return and risks a hard conversation later.

Confusing a sizing candidate with a final design. The engine sizes against an image, not against a structural review. Treating its first output as buildable skips the step where a roof fails the load check.

Showing one financing path. Modeling only the path you prefer hides the comparison the customer needs. Cash, loan, and PPA each read differently, and the honest proposal shows all three.

Hiding the assumptions. A payback number with no visible escalation or degradation rate behind it cannot be defended. If the customer cannot see the inputs, they cannot trust the output.

From Usage File to Client-Ready Proposal

These steps fall apart when they live in separate tools. Usage in a spreadsheet, the layout in a design app, the financials in a second spreadsheet, and the proposal in a template means every handoff is a chance for a number to drift, and the version the customer signs rarely matches the one the model produced. The whole case for automating a proposal collapses if the automation is really four disconnected tools stitched together by copy and paste.

Keeping the chain connected is the point. You bring in the usage and the rate, size the array and battery against both, model production on validated site data, build the cash, loan, and PPA financials with the ITC applied correctly, and generate the document from the same model. PVComplete's PVSketch runs that flow for fast sales layouts, proposals, and energy modeling, and hands off to detailed engineering when the deal needs it, while Enact's design and proposal platform carries the model through to the client-ready document. Because the design, the production estimate, and the savings share one model, the system you size is the system you propose, and the proposal rests on math a customer, or a reviewer, can follow straight back to the bill. The software does the arithmetic in seconds. You still own the assumptions and the final read, and every dollar figure stays a modeled estimate tied to what you entered.

Frequently asked questions

How do you automate a solar proposal from a customer's bill?

You feed the customer's annual usage, rate, and address into proposal software, which shapes a load profile, sizes the system, models production, and builds the financials in one pass. The tool scales the bill into a usage pattern, sizes the array to a target offset, estimates production on validated weather data, and rolls a cash, loan, and PPA comparison with the federal credit applied. A designer still confirms the rate, the shading, and the roof. See PVSketch for how that end-to-end flow runs.

Can software size a solar system and battery on its own?

It can produce a sized candidate from usage, a rate, and a target, but a person has to confirm it against the real roof. The engine returns a panel count, layout, and a battery sized to the goal you set, whether that is backup, self-consumption, or demand savings. It cannot see shading the aerial image misses or judge whether the roof can carry the load. Enact's Design and Proposals platform sizes the panels and battery against one usage profile, then the designer checks the result.

How does a solar financial model handle the federal tax credit?

It applies the Residential Clean Energy Credit as a reduction in federal taxes owed in the year the system is placed in service, not as an upfront rebate. The IRS describes it as a credit for qualified clean energy property, and it only helps a buyer with enough tax liability to absorb it. A good model applies it in the correct year and lets you adjust for a customer with limited liability. Treat the result as a modeled estimate, not tax advice.

What is the difference between cash, loan, and PPA in a proposal?

Cash means the customer owns the system and keeps all savings, a loan spreads the cost at a rate while the customer still owns it, and a PPA means the customer buys the power without owning the asset or claiming the credit. Each reads differently over 25 years once escalation and degradation are applied. EnergySage explains how loan rates, terms, and fees shape the true cost, and an honest proposal models all three side by side.

How accurate is automated solar production modeling?

It is accurate when built on validated weather data with real losses applied, and unreliable when it skips shading or uses a generic sun-hours shortcut. The Department of Energy notes that performance depends on the solar resource, orientation, temperature, soiling, and shading rather than the nameplate rating (DOE). Tools that mirror the NREL PVWatts model meet a reasonable baseline, but a real shade study is the input the software cannot derive on its own.

Why show a 25-year cashflow instead of just payback?

Because a simple payback hides the escalation, degradation, and time value that decide the real return. A 25-year cashflow steps production down each year, values savings at a rising utility rate, and lands the credit in its proper year, so the payback and lifetime benefit are defensible. National cost benchmarks like EnergySage's installed cost data help confirm the inputs sit in a believable range before the model runs. Keep every assumption visible in the proposal.

Sources

1. IRS - Residential Clean Energy Credit
2. DOE - Solar Performance and Efficiency
3. DOE - Homeowner's Guide to Going Solar
4. NREL - PVWatts Calculator
5. EnergySage - How the Solar Tax Credit Works
6. EnergySage - Solar Loans
7. EnergySage - Solar Panel Cost
8. EIA - Electricity prices and factors affecting prices
9. SEIA - Depreciation of Solar Energy Property