Quick Answer
A solar production estimate assumption register lists every material input, its source, date, status, owner, and release effect. It distinguishes measured or documented project evidence from planning assumptions, and it tells the reader which changes require the estimate to be rerun.
A solar production estimate is credible when a reviewer can trace its material inputs and understand what would cause the result to change. The number at the end of a model may be useful for a proposal, investment discussion, or design comparison, but it is never the whole forecast. The useful question is not only “What does the model produce?” It is “What did the model assume, what evidence supports those assumptions, and which of them remain conditional?”
This article is desk research for installers and EPCs. It does not provide an energy yield guarantee, investment advice, a bankability opinion, or a substitute for project-specific engineering, metering, weather analysis, tariff review, or legal terms. Different tools, datasets, loss methods, and project types can produce different results from the same site. The process below makes those differences easier to discuss before a customer or decision-maker mistakes a scenario for a promise.
Direct Answer
Put a short assumption register beside every material production estimate. For each input, record the value or method, source, date, status, owner, and what happens if it changes. Release the estimate with the register’s boundaries visible, and rerun the scenario when a material design, site, operating, or data input changes.
Why a Single Annual-kWh Figure Is Not Enough
Production estimates travel fast inside a solar business. A designer uses one to compare layouts. A salesperson uses it to explain a proposal. A finance conversation may translate it into savings, revenue, payback, or risk. A project manager may later use it to spot whether an installed configuration differs from what was described. Each use can be reasonable, but only when the estimate carries its assumptions with it.
The NREL PVWatts calculator describes itself as a tool for estimating the energy production of grid-connected photovoltaic systems. It is a valuable public reference and a useful way to understand the categories of model inputs. It does not validate a particular roof, system layout, tariff, or customer claim. A modeled result remains conditional on the site and assumptions entered.
An assumption register prevents a common communication failure: a preliminary number is copied into a proposal, then the project changes while the explanatory basis disappears. The number may stay similar enough to avoid immediate attention, but a changed orientation, shading treatment, inverter, module count, loss input, consumption pattern, or operating plan can alter what the original result meant.
Define the Decision Before Choosing the Model Detail
The level of analysis should fit the decision. Early sales screening may compare broad options using limited evidence. A technical design review needs a more controlled set of inputs. A financial decision may require its own treatment of degradation, price escalation, curtailment, availability, degradation, consumption, export treatment, and uncertainty. Calling all of these “the estimate” hides meaningful differences.
Write a purpose statement before modeling. Examples: “Compare two preliminary roof-layout options using currently available site information,” “support a customer-facing annual-energy scenario,” or “review the consequence of a confirmed module-count change.” The statement should say what the estimate is for and what it is not for. It prevents a screening output from being reused as a construction or investment commitment without further review.
| Purpose | Evidence standard | Appropriate language |
|---|---|---|
| Early opportunity screen | Public location data and customer-supplied information may be incomplete | Indicative scenario; site conditions and design remain to be confirmed |
| Proposal comparison | Controlled design inputs with visible qualifications | Modeled annual-energy estimate for the stated configuration |
| Technical release review | Current equipment, layout, and survey-backed inputs | Recheck when a material project input changes |
| Financial or risk decision | Defined data, methods, scenarios, and relevant specialist review | State assumptions and uncertainty method; avoid a single guaranteed outcome |
The NREL solar resource maps and data help explain why resource data is location-specific and dataset-based. They do not replace a project team’s decision about which data source, time period, spatial resolution, or loss treatment is suitable for a particular use.
Build the Register Around Inputs That Change Decisions
An assumption register should not become a transcription of every software field. Concentrate on inputs that can change the result or change the way someone should rely on it. Start with categories, then include only meaningful project entries.
| Assumption category | Example record | Why the status matters |
|---|---|---|
| Site and location | Address or coordinates, source, verification status | A wrong site can invalidate weather, shading, and layout context |
| System configuration | Module count, rating, orientation, tilt, inverter selection | Establishes what system the model actually represents |
| Solar resource data | Dataset, source, model setting, retrieval date | Shows the basis for the weather/resource input |
| Shading and horizon | Survey evidence, model method, or provisional treatment | Distinguishes observed conditions from an assumed clear horizon |
| Losses and availability | Value, method, and reason for use | Prevents a default value from appearing site-confirmed |
| Consumption and tariff | Bill/interval-data period, tariff source, treatment | Separates generation from financial or self-consumption conclusions |
| Future changes | Re-roof, expansion, tree growth/removal, operating change | Signals conditions that may require a rerun |
Each row needs a status. A three-part status is often enough: supported, planning assumption, or required before a later release. “Supported” means a named source exists and is suitable for the current decision, not that the project is free from uncertainty. “Planning assumption” means the team used a value to explore a scenario. “Required” means the estimate should not be relied on for the stated later use until the matter is resolved.
Separate Resource Data, Site Evidence, and Model Judgment
These categories are related but different. Resource data might come from a named public dataset. Site evidence may include survey notes, imagery, drawings, photographs, or measured conditions. Model judgment includes choices about losses, shading treatment, configuration, and the intended scenario. Blending them into a generic “data source” field makes it harder to review the outcome.
For example, an address may be supported by customer documentation, orientation may be based on a preliminary roof model, and vegetation may be an unverified observation from imagery. A thoughtful register says so. It does not claim that all three are equally confirmed merely because they were entered into the same software project.
This is also where Shadow Analysis is relevant. A shading workflow can help teams model and communicate shade conditions, but it cannot establish that a modeled roof surface, neighboring feature, or future vegetation condition represents site reality without appropriate project evidence and review.
Make Solar Assumptions Easier to Follow Through the Workflow
Explore how SurgePV connects solar design, Shadow Analysis, generation modeling, and customer-facing proposal work around the same project inputs.
Book a DemoBring an active project to a live walkthrough and discuss its decision points.
Give Each Assumption an Owner and a Trigger
Registers become useful when they influence action. For every material open item, name who can resolve it and what event will cause the estimate to be reviewed. An owner can be a role rather than an individual where the organization works that way, but it must be specific enough to act: site survey lead, design owner, customer contact, procurement lead, electrical reviewer, or commercial lead.
Triggers are equally important. A new module model, confirmed tree condition, revised roof geometry, storage addition, changed export arrangement, updated interval data, or changed operating schedule may require a rerun. Do not state that any one of these always changes energy by a fixed percentage. The impact depends on the project. The trigger is a request to reassess, not a pre-decided conclusion.
| Register field | Example | What it enables |
|---|---|---|
| Input and value | Annual consumption from specified bill period | Makes later data comparison possible |
| Source and date | Customer-provided PDF received on a stated date | Lets the reviewer assess currency and origin |
| Status | Planning assumption pending interval data | Prevents overconfident financial language |
| Owner | Commercial analyst requests data | Creates accountability |
| Rerun trigger | New interval dataset or load change | States when the current scenario expires |
| Release effect | Required before final financial recommendation | Separates useful screening from a later decision |
Show the Difference Between Energy, Savings, and Outcome
Annual energy output, bill savings, revenue, payback, and return metrics are not interchangeable. Energy is one modeled output. Financial outcomes also depend on consumption alignment, tariff structure, export treatment, charges, financing, incentives where applicable, operating costs, and other assumptions. An assumption register should show when an article, proposal, or internal model moves from an energy scenario into a financial scenario.
Avoid attaching an energy estimate to a promise such as “your bill will fall by this amount.” A responsible statement is more specific: “This is a modeled annual energy scenario for the listed design and inputs; financial results require the tariff, consumption, export, and commercial assumptions stated in the proposal.” That sentence does not weaken the customer conversation. It tells the reader what evidence would improve the answer.
The DOE’s Solar Energy Technologies Office offers broad context on solar technology and deployment. Project-specific financial modeling still requires current local data and terms; an industry source cannot confirm an individual customer’s tariff treatment or future savings.
Use Scenario Labels Instead of Hiding Uncertainty in Footnotes
When the purpose allows it, present defined scenarios rather than implying that one number represents every possible future. A design comparison can show “current preliminary layout” and “layout after survey confirmation.” A commercial review may compare stated operating profiles. The key is that each scenario names what changed and what stayed fixed.
Do not manufacture a high, base, and low range simply to make the presentation look sophisticated. If an uncertainty range is used, document the method and its limitations. P50, P75, and P90 labels have technical meanings in appropriate contexts and should not be applied casually to a three-number sales illustration. The Generation & Financial Tool is the appropriate SurgePV destination for teams evaluating connected simulation and financial workflows, while project-specific assumptions still need qualified review.
Review the Register at Handoffs
The register should not be created once and forgotten. Review it at moments when people tend to copy outputs forward: before a proposal is issued, when a design changes, before a customer signs a scope, before procurement locks equipment, and before a construction or financial release uses the estimate. The review can be short when no material input has changed. It should be deeper when a trigger appears.
Keep the review history factual. “Rev 2 issued after confirmed roof survey; orientation and shading inputs updated” is useful. “Numbers now accurate” is not. All models have boundaries, and accuracy claims require evidence beyond an internal status note.
Questions for a Proposal Reviewer
- What configuration, resource input, and site treatment produced this estimate?
- Which values are sourced from current project evidence, and which remain assumptions?
- Does the customer-facing language describe a modeled scenario rather than a guaranteed result?
- Did an equipment, site, shading, consumption, tariff, or operating input change after the estimate was run?
- Which owner is responsible for each condition that must be resolved before the next release?
Improve the Register From Real Rework
At project close or after a substantial revision, look for inputs that repeatedly turn out to be incomplete or misunderstood. Perhaps sales teams request annual bills when interval data would materially affect a commercial scenario. Perhaps preliminary shading inputs are being reused after a site observation changes the roof story. Perhaps equipment substitutions reach the model late. Convert those observations into a better evidence request or a clearer rerun trigger.
Do not use one company’s return reasons to claim an industry average. The useful learning is local: which information arrives too late for the decision it affects, and how can the workflow surface that condition earlier?
Practical Next Steps
- Add a source, date, status, owner, and rerun trigger to every material model input.
- Label customer-facing results as modeled scenarios and state their design and data boundary.
- Recheck the register whenever the site, system, shading, equipment, consumption, tariff, or operating assumptions change.
Connect Solar Modeling to the Project Record
Book a free SurgePV demo to see Solar Designing, Shadow Analysis, the Generation & Financial Tool, and Solar Proposals in a connected workflow.
Book a Free DemoFrequently Asked Questions
What is an assumption register for a solar production estimate?
It is a controlled list of the inputs and judgments behind a forecast. Each material entry should state the value or method, source, date, status, owner, and the decision or release it affects. It turns a single output number into a reviewable project record.
Does an energy-model estimate guarantee solar output?
No. Production depends on resource data, weather variation, equipment, design, site conditions, shading, losses, availability, operation, and other assumptions. Present the result as a modeled scenario with stated inputs and boundaries, not as a guarantee of energy or financial outcome.
When should a team rerun a solar production estimate?
Rerun it when a material input changes or when the estimate is being used for a more consequential decision. Common triggers include a changed layout, module or inverter selection, verified survey finding, revised shading treatment, updated consumption information, changed tariff assumptions, storage addition, or a different operating plan.
