Before a sales rep sends a production estimate, the release owner should be able to identify its project, current model run, intended use and unresolved conditions. This checklist is a compact pre-send gate. It checks whether the evidence package is ready for the proposed customer conversation; it does not validate the model’s physical accuracy.
Answer: Review a solar production estimate before release by matching its project and design revision, resource basis, equipment, shading/loss assumptions, model run and output units. Confirm the intended use, reviewer and unresolved limitations. Hold stale or unexplained figures, assign corrections and verify dependent proposal and financial outputs. A completed checklist is a bounded release record, not a production guarantee.
SurgePV publishes this checklist and sells solar software. The release rules below are suggested operational controls for a team to adapt, not a universal engineering or permitting standard.
Use this at one defined gate
Run the check after the estimate is prepared and before its chart or number enters a customer-facing proposal. Repeat it when a material input changes. Name the sales owner and the technical reviewer; keep their responsibilities distinct.
Use the assumption register for the detailed input/source/status record. Use the eight buyer-facing proof points to explain an accepted package in a meeting. This page is the send, narrow or hold decision between those activities.
The pre-send checklist
Mark each row ready, conditional or hold. Keep a record link and responsible owner beside it.
| Check | Ready evidence | If it is missing or conflicts |
|---|---|---|
| Project identity | Correct site, building/array areas, option and estimate purpose | Hold the property-specific result until identity is resolved |
| Current design | Output matches the layout and equipment revision being offered | Mark stale; ask the modeling owner whether rerun is required |
| Resource basis | Named weather source/file and period or typical-year basis | Recover the source; avoid calling unexplained data “local” |
| Shading and losses | Defined treatment, evidence dates and material exclusions | Flag the missing condition and restrict unsupported claims |
| Model/output identity | Run reference, method/version, units, period and energy boundary | Hold an unexplained number or chart |
| Material assumptions | Current register with accepted defaults and unresolved inputs | Assign an owner and decide whether preliminary use remains appropriate |
| Customer language | Estimate label and limitations match intended use | Remove unsupported guarantees, accuracy badges or approval language |
| Dependent artifacts | Proposal, BOM/equipment schedule and financial outputs match the accepted revision | Reconcile each affected item before sending |
| Review | Named reviewer, bounded purpose, decision and date | Keep internal until the designated review is complete |
| Correction route | Retained issued copy, recipients and successor process | Establish how stale copies will be replaced |
“Conditional” needs a written limitation and release decision from the responsible owner. It is not permission to hide a missing material input in a footnote. “Hold” pauses the affected result or claim; it does not necessarily stop every unrelated project task.
Make the units and boundaries explicit
Do not confuse installed power in kW, monthly or annual energy in kWh, irradiance in W/m² and irradiation in kWh/m². Also distinguish array DC output, inverter AC output and delivered/exported meter energy.
The PVWatts V8 documentation makes those output distinctions concrete: monthly DC and AC energy are separate fields, annual AC output is energy, and hourly AC output is power. It also returns input and weather-source records. Use the equivalent named fields for the model actually used; a screenshot title cannot establish them.
A representative-weather estimate is not a promise that next year’s meter will record the same value. If the output is described with a confidence or exceedance label, require its method and review evidence. PVPMC’s uncertainty guidance addresses variability and uncertainty in model inputs and results. A limitation list alone does not quantify that uncertainty.
Keep production distinct from the financial scenario
Confirm which energy output feeds the savings calculation. Consumption, export value, tariffs, finance and incentives have their own evidence and dates. Production does not become savings by multiplying every generated kWh by an unexplained retail rate.
The FTC’s United States consumer guidance advises obtaining detailed written bids with system size and expected power delivery, while considering site and system factors. This supports a clear written basis; it does not approve this checklist or a specific private proposal.
If finance terms or an incentive remain unconfirmed, label their scenario separately. Escalate engineering, utility, contract and jurisdiction-specific questions to the designated qualified reviewer.
Revision example: an inverter substitution after review
This is an illustrative process example, not a customer case or claimed software result.
A proposal was reviewed against layout B and output run B. Procurement then proposes a different inverter. The sales owner should not keep the old energy chart merely because the module count is unchanged.
Record the substitute, affected design and prior run. The technical owner checks compatibility and whether output assumptions change, then reruns or documents why the existing result remains applicable. Finance reviews any changed energy/cost inputs. The release owner issues the accepted successor and replaces affected proposal attachments.
The check closes only when the released documents match the accepted decision. It does not close when someone edits the equipment name in the PDF.
Retain a short release record
| Release field | Entry |
|---|---|
| Project and customer-facing purpose | |
| Design revision and model run | |
| Checklist decision: ready, conditional or hold | |
| Unresolved item, affected claim and owner | |
| Reviewer, scope and date | |
| Approved limitations and next verification | |
| Proposal/financial versions and issued recipients | |
| Successor or correction reference |
Sample completed records during operating review. Count missing links, stale charts and unresolved exceptions from your own work; do not turn those process measures into an industry accuracy benchmark.
When evaluating SurgePV’s design workflow or proposal workflow, request a requirements demonstration of how your team can retain the relevant evidence and revisions. This checklist does not establish automatic cross-document updates or approvals.
Frequently Asked Questions
When should a solar team use this checklist?
Use it before a modeled production number or chart reaches a customer and repeat it after material changes. Retain the bounded release decision with the relevant design, run and issued proposal.
Does a completed checklist prove production accuracy?
No. It records whether evidence and review support a stated release use. Physical accuracy, future weather, measured performance, engineering approval and guarantees require their own methods and evidence.
What should happen when the estimate uses an old revision?
Mark the affected output stale. Ask the responsible owner to rerun or document its continued applicability, then reconcile dependent proposal and financial artifacts before release.
Sources reviewed September 30, 2026.
Sources
Primary research and reference material used for this desk-research article.
Where this fits
This article is part of SurgePV's Solar Business & Operations hub, which works through the topic from first principles to the decisions a project team actually has to make.
