Answer
Two solar designers can forecast different yield for one site because they may use different weather records, site geometry, shade treatment, equipment models, loss assumptions, and output definitions. Reconcile those inputs in a controlled comparison before judging either forecast. Matching annual totals alone cannot show which model better represents the intended system and decision.
Two yield reports for the same address can disagree while both software runs completed exactly as configured. One designer used a different weather period. The other modeled a roof plane at a different azimuth, excluded a tree, selected another inverter, or reported energy at a different point in the system.
This guide is for solar designers, reviewers, sales engineers, and operations leaders who need to reconcile those forecasts without guessing which number “looks right.” It covers six common causes and a repeatable comparison method. It does not validate a particular model, predict actual generation, or replace survey evidence, engineering judgment, manufacturer instructions, contract review, or qualified local review.
The Department of Energy explains in its solar radiation primer that radiation reaching a surface varies with location, time, season, weather, and orientation. A yield forecast turns that variable resource into modeled energy through a chain of data and assumptions. Different links produce different answers.
Last updated: November 2026
Reconcile Your Next Forecast Against One Project Record
Keep geometry, shading, equipment and loss inputs in one model, so a second designer starts from the same basis.
Book a DemoChecking cost first? See the SurgePV pricing page.
Begin with forecast identity, not the annual number
Before comparing results, confirm that both forecasts describe the same site, array, equipment, operating scenario, reporting period, and output boundary. A comparison fails immediately if one report includes an added carport, uses more modules, reports inverter output, or covers a different period from the other.
Create a forecast identity sheet. Record model name and version, run date, modeler, site coordinates, time zone, weather source, array configuration, DC capacity, AC capacity, module and inverter identifiers, orientation, shade method, loss method, and energy output field. Attach exports rather than copying values into an untraceable email.
Use three labels for inputs: observed or measured, sourced from a named record, and assumed for the scenario. Modeled output gets its own label. These categories prevent a precise result from lending false authority to an uncertain roof edge or a default loss value.
Start the reconciliation with structure, then move into detail:
- Match the project and output boundary.
- Match array size and equipment identity.
- Compare weather source and period.
- Compare geometry, orientation, and shade.
- Compare component and conversion models.
- Compare losses, availability, and reporting definitions.
Do not overwrite either original file. Create a controlled comparison case and maintain a run log. If a reviewer changes five settings at once, the new total may converge without revealing which difference mattered.
| Reconciliation layer | Values to compare | Typical hidden mismatch |
|---|---|---|
| Scope | Site, meter, buildings, arrays, scenario | Added array appears in only one run |
| Resource | Dataset, coordinates, years, timestamps | Different weather file or location |
| Geometry | Tilt, azimuth, horizon, row spacing, roof planes | Inferred plane differs from survey |
| Equipment | Module, inverter, quantities, topology | Generic and named products mixed |
| Losses | Shade, soiling, wiring, mismatch, availability | Defaults versus project assumptions |
| Output | Gross or net, AC or DC, interval, year basis | Similar label means a different quantity |
The solar insolation reference gives broader resource terminology. This article stays on the operational problem: finding the input or method that caused two project forecasts to diverge.
Reason 1: the weather datasets describe different conditions
Weather data supplies irradiance, ambient conditions, time information, and other inputs used by a performance model. Two valid datasets can represent different periods, stations, gridded sources, processing methods, spatial resolutions, or long-term summaries. They should not be treated as interchangeable because both are labeled “typical.”
Sandia’s PV Performance Modeling Collaborative organizes weather and design inputs across solar position, irradiance, weather observations, array orientation, plane-of-array irradiance, and losses. That map shows how early the weather choice enters the calculation chain.
Record the exact dataset identifier and retrieval settings. Coordinates alone are insufficient. Capture source, version or edition where available, period, spatial point, elevation treatment, time zone convention, interval, missing-data handling, and any transformation applied before import.
NASA POWER provides an API service for analysis-ready meteorological data, while the European Commission’s Joint Research Centre describes PVGIS as a tool for solar resource and PV performance information. These are examples of documented data services, not proof that one source is universally preferable.
Check whether each designer chose a source appropriate to the intended market, model, and decision. A screening scenario, lender review, contractual model, and operational forecast may have different requirements. Those requirements should come from the project brief and qualified stakeholders, not habit.
Time handling deserves special attention. A shift in timestamp convention can move irradiance against temperature, shade, load, or tariff intervals. Daylight-saving treatment can create a quiet mismatch. Compare raw or intermediate time-series samples rather than trusting an annual total.
When weather is the suspected cause, run both designs with one agreed dataset while holding everything else fixed. The change isolates resource choice from layout and equipment differences. Retain the original cases because the comparison run does not retroactively change what each designer proposed.
Reason 2: roof geometry and array orientation do not match
A shared address does not guarantee a shared site model. Designers may trace different roof edges, interpret image scale differently, assign another tilt or azimuth, place modules on different planes, model obstructions at different heights, or use survey evidence with different status.
Compare geometry visually and numerically. Overlay roof boundaries and array polygons where the workflow permits. Reconcile roof-plane identifiers, tilt, azimuth, module count, module orientation, row spacing, setbacks used, obstructions, ground elevation, tracker limits, and any terrain or horizon treatment relevant to the system.
Sandia separates array orientation and the calculation of plane-of-array irradiance within its modeling guide. The relationship matters because a weather file’s horizontal and direct irradiance components still have to be translated to the receiving surface modeled by the designer.
Trace every geometry value to its source. A remotely inferred roof can support early option work if its status is clear. It should not silently gain survey authority when passed into a later yield report. A field measurement may also contain unit, transcription, or reference-point errors, so “measured” needs a method and record.
Use versioned site evidence. Record imagery capture date where available, survey date, drawing origin, coordinate system where relevant, and the person who accepted changes. If two files conflict, list the discrepancy and owner instead of choosing the one that produces the preferred energy value.
For fixed systems, modest orientation differences can change modeled irradiance timing and total. For trackers, algorithms, limits, terrain, backtracking, and stow assumptions add more choices. Do not generalize a residential roof workflow to a utility-scale model.
The 3D roof design page describes SurgePV’s roof-modeling context. Software can help keep geometry and array layout connected, but the model remains dependent on the source evidence and reviewer decisions entered into it.
Reason 3: shading and horizon treatment differ
Shade can be represented through horizon profiles, near-object geometry, time-series factors, monthly reductions, string or module treatment, or a broad loss assumption. Two methods can produce different yield even when designers agree that a tree, parapet, chimney, or neighboring structure exists.
Sandia groups shading, soiling, and reflection losses as distinct effects. A reconciliation should keep them distinct too. A single “system loss” field can hide whether one designer modeled geometry and another entered a percentage allowance.
Ask what physical objects were included, which date the site evidence represents, whether vegetation growth or removal is assumed, how the horizon was derived, and how shade maps to electrical configuration. A shade scene and an electrical topology may interact inside the selected model, so matching an annual shade percentage does not guarantee matching treatment.
Inspect seasonal and hourly outputs when available. A similar annual loss can have a different production shape, which can matter for self-consumption, tariffs, storage, or operational loads. Keep any financial implication in a separate, controlled model with current customer and tariff inputs.
The shadow analysis page explains the product workflow at a high level. For review, insist on source date, method, modeled objects, exclusions, and revision status. A dramatic shadow image is useful only when another reviewer can reproduce its basis.
Separate existing and future conditions. A tree-removal plan, future building, scheduled reroof, or unbuilt obstruction is a scenario input, not a present observation. Name the owner and decision date. Do not blend aspirational site work into a base case without a visible label.
To isolate shading, use the same geometry, weather, equipment, and non-shade losses in a comparison run. Then substitute one shade treatment at a time. If the software cannot expose enough detail, document that limitation rather than claiming precise reconciliation.
Reason 4: component and conversion models are not equivalent
Module and inverter modeling choices affect how irradiance and temperature become DC output and how DC becomes delivered AC energy. Designers may select different component records, generic models, database versions, inverter quantities, DC-to-AC ratios, power limits, efficiencies, or electrical configurations.
Sandia’s guide treats DC module current-voltage characteristics and DC-to-AC conversion as separate modeling stages. That is a useful review boundary. First reconcile the array’s DC behavior and topology, then the conversion equipment and limits.
Match exact identifiers, quantities, nameplate inputs, model families, parameter sources, database dates, and any custom edits. A component name displayed in a report may mask a generic parameter set. Conversely, two database entries with different names may describe closely related configurations. Inspect the actual parameters needed by the chosen model.
Temperature modeling can differ even with the same module. Designers may use another mounting assumption, thermal model, ambient temperature input, wind treatment, or coefficient source. Do not isolate module choice while leaving these connected settings unmatched.
Check topology. String lengths, parallel inputs, inverter loading, optimizer or module-level electronics treatment, clipping, standby behavior, transformer treatment, and auxiliary loads can affect model boundaries. The relevant list depends on the system architecture and software.
Manufacturers are valid first-party sources for their own published specifications. Their documents do not prove that a product or model is objectively best. Retain the current document, revision, and exact parameter provenance used in the forecast.
If the final installed equipment changes, update every dependent output under revision control. The forecast, bill of materials, electrical record, proposal, and commissioning basis should not describe different systems.
Key Takeaway
Most forecast gaps trace to one input category, not to a calculation error. Match scope, weather, geometry, shade, equipment and losses in that order, and the gap usually shrinks to something explainable.
Keep Model Inputs Connected to the Forecast
Check how weather, layout, shading and equipment records feed one yield estimate in a SurgePV walkthrough.
Book a DemoWant the feature view? See the generation and financial tool or the SurgePV pricing page.
Reason 5: loss assumptions use different boundaries
“Losses” can contain many mechanisms: soiling, mismatch, wiring, connections, availability, curtailment, degradation scenario, transformer effects, auxiliary consumption, shading not modeled elsewhere, or other project-specific items. A default total can conceal double counting, omission, or a different energy boundary.
Build a loss register rather than comparing one total. For every item, record name, definition, basis, value or method, source, status, time pattern, model location, and output boundary. Mark whether the effect is already represented by geometry, component behavior, or another model stage.
The central review question is not whether two percentages match. It is whether both models represent the same physical effect once, at the correct stage, using an appropriate basis. One designer may model soiling by month while another enters an annual factor. A single annual number cannot expose that shape.
Availability and curtailment require careful ownership. They may depend on operating strategy, grid requirements, service arrangements, or customer actions outside the designer’s control. Use current project evidence and qualified stakeholder input. Do not insert a convenient assumption solely to make the forecast commercial case work.
Keep measured history separate from future assumptions. If an operating plant has actual downtime or soiling observations, state period, coverage, instrumentation, data quality, and whether the future case uses them. A new plant lacks that site history and may require a sourced or scenario assumption.
The loss-factor documentation guide provides a fuller input register. The related assumption-standardization guide shows how a team can use controlled defaults without pretending every site behaves identically.
Standard defaults need an exception path. Record who can change them, which evidence is required, which outputs must be rerun, and how the reviewer sees the difference from the baseline. Otherwise two designers can each believe they followed company policy while using private variations.
Reason 6: the reports answer different yield questions
Even identical calculations can appear different when reports use different units, periods, or energy points. One may show gross DC energy, another net AC energy. One may report a typical-year estimate, another a calendar-year scenario. One may include availability assumptions that the other displays separately.
Define the requested output before modeling. Name energy unit, power basis, interval, reporting period, output location, inclusions, exclusions, and whether the figure is a model estimate, measured value, normalized result, contractual definition, or financial-model input.
Check labels such as “specific yield,” “performance ratio,” “net generation,” and “production.” A familiar term can have a project or tool-specific boundary. Preserve the formula or model documentation rather than translating every output into a loose synonym.
Annualization needs care when the source period is partial or timestamps differ. Do not scale a short period mentally and present the result as an established annual fact. Any derived value needs declared inputs, formula, units, provenance, and a calculation executed and checked outside the prose.
Financial outputs add another boundary. Utility-bill effects depend on consumption, timing, tariff, export treatment, fixed and demand charges, future assumptions, and jurisdiction. Review the generation and financial workflow for your scenario requirements. Forecast energy and customer savings remain distinct claims.
Reports can also differ through rounding and display precision. Compare unrounded exports where the tool makes them available. Do not spend hours explaining a display-only difference before checking whether the underlying series materially diverges.
The most useful report includes an input summary and limitations. Exact digits without provenance create the appearance of agreement while leaving the model impossible to review.
Sandia’s 2021 blind PV modeling comparison supplied weather and system descriptions and requested separate plane-of-array irradiance, module-temperature, and DC-power series. Its structure offers a useful lesson: compare intermediate stages, not just an annual total. That study concerned defined research systems and DC output; it does not validate a customer forecast or establish a universal discrepancy tolerance.
Source: Sandia PVPMC 2021 blind PV modeling comparison, opened November 2026. The page reports no numeric spread between modelers.
Pro Tip
Ask both designers for hourly or monthly exports, not just annual totals. Compare irradiance on the array first, then temperature, then DC power, and stop at the first stage where the series diverge.
Use a controlled reconciliation run instead of averaging
Averaging two forecasts produces a third number with no physical or model basis. The midpoint may look diplomatic, but it does not identify which weather data, geometry, shade, equipment, losses, or definition should govern the project.
Use a staged reconciliation:
- Freeze and hash or otherwise retain both original model exports.
- Build an input-difference register with evidence links and owners.
- Agree one site, system, period, and output boundary for comparison.
- Select a controlled baseline model and record its version.
- Change one input category, rerun, and retain the result.
- Review material effects and resolve or preserve each difference.
- Release the chosen forecast with its basis and open limitations.
Do not treat convergence as proof of truth. Two models can agree because they share the same weak input. The comparison run explains sensitivity to identified differences; the evidence review decides which input is suitable.
Set a materiality rule appropriate to the project decision. The rule may concern energy, finance, equipment, schedule, or contractual effect. Record who approved it. Avoid publishing a universal tolerance that lacks support across system types and use cases.
If the disagreement stems from model capability or validation, involve a reviewer who understands that model and application. A salesperson should not settle a technical dispute by selecting the forecast that makes the proposal easier to sell.
How should a design team compare two yield forecasts?
A design team should compare yield forecasts by freezing both original runs, creating an input difference register, agreeing one site, system, period, and output boundary, and changing one category at a time in a case. Reviewers should retain each run, distinguish evidence from assumptions, validate derived values, and route unresolved model, site, engineering, contract, or customer questions to responsible roles.
Use a copy-ready reconciliation record:
Solar yield forecast reconciliation
Project, site, and forecast purpose: [controlled identifiers]
Original run A: [model, version, author, date, export]
Original run B: [model, version, author, date, export]
Agreed comparison boundary: [arrays, equipment, period, energy point]
Input differences: [weather, time, geometry, shade, equipment, losses, operations]
Source and status for each difference: [observed, measured, sourced, assumed, unresolved]
Controlled baseline: [run identifier and reason]
Category changed: [one category per run]
Output effect: [retained computed result, not mental arithmetic]
Disposition: [resolved, accepted scenario difference, or escalated]
Reviewer and release boundary: [role and intended use]
Run the comparison in sequence. First align identity and output. Next align array and equipment. Then weather and time. Then geometry and shade. Then component models and topology. Finally compare the loss register and reporting display. Preserve the original results because the controlled run explains differences; it does not rewrite what each designer originally issued.
Every derived delta needs a validated calculation with exact inputs, units, formula, source references, and script output. If the team cannot validate a displayed difference, describe the direction qualitatively or retain the two source outputs without publishing a buyer-created number.
Set a decision-specific materiality rule with the responsible reviewer. The rule may relate to layout, energy, finance, equipment, contract, or another project outcome. Avoid a universal tolerance chosen only to make two runs appear close enough.
Close each difference with evidence and a decision. “Changed until totals matched” is not a disposition. Record why one input fits the project, why both remain valid scenarios, or why qualified review is still required.
Which solar yield forecast should a customer use?
A customer should use the yield forecast whose site evidence, weather source, geometry, equipment, losses, model version, reporting boundary, limitations, and revision history best match the intended project decision after responsible review. The chosen forecast remains a model, not a guarantee. If material inputs are unresolved, the proposal should preserve scenarios or a decision condition rather than average competing outputs.
The customer-facing explanation should name the mechanism that changed the result. “We selected the lower number to be conservative” is not sufficient unless the underlying inputs and purpose support that policy. “This revision uses the field-reviewed roof geometry and the current equipment schedule” gives the buyer inspectable reasons.
Use a decision note:
Customer yield forecast basis
Forecast and proposal revision: [identifiers]
Intended use: [design comparison, proposal scenario, financial input, or other]
Project boundary: [site, arrays, equipment, period, energy point]
Site and weather evidence: [sources and dates]
Shade, loss, and operating assumptions: [named records]
Differences from prior forecast: [input mechanism and affected outputs]
Open limitations: [unresolved inputs and next evidence]
Review completed: [role and scope]
Customer action or next trigger: [decision or verification event]
Present forecasts as modeled scenarios with the inputs and uncertainty nearby. Do not convert them into a meter reading from the future. Weather, site conditions, equipment behavior, operations, curtailment, availability, maintenance, and customer actions can differ from the modeled case.
If a contract contains a performance term, keep that legal and commercial commitment separate from the design forecast and route it through qualified review. Similar numbers do not prove that the report and agreement define the same energy, period, exclusions, remedies, or responsibilities.
When the selected input changes, issue a new model and proposal revision. Preserve the earlier customer document, explain what evidence changed, and regenerate every dependent financial or commercial output. Silent replacement turns a technical correction into a trust problem.
Prevent the same discrepancy next time
Use the nine production-assumption categories to agree shared definitions, model mappings, and exception rules. Keep actual project values and evidence in the production-estimate assumption register. These controls make differences visible without forcing every site to use identical losses or equipment.
Train on retained discrepancy cases. Give two designers the same source package, then compare where their judgments diverged and what evidence would resolve them. Review component libraries and defaults when software versions or product records change. A locked but stale record can spread the same error across projects.
Before sending the selected forecast, use the production estimate trust checklist to confirm that the report, design, and proposal carry the accepted revision and limitations. Reconciliation explains a disagreement; release review decides whether the resulting package is ready for its audience.
If you want to run this comparison on a live project, book a SurgePV demo and bring both forecasts.
Review the inputs behind your next solar forecast
Bring a representative layout and your reporting requirements to a guided SurgePV walkthrough.
Book a guided demoSources reviewed September 30, 2026. Project-specific input selection and release remain subject to the responsible reviewer.
Frequently Asked Questions
Does the higher solar yield forecast represent the better design?
No. A higher forecast can come from more array capacity, a sunnier weather file, less shade, different losses, or a different output boundary. Compare like with like, then examine evidence quality and model suitability. The more defensible forecast is the one whose inputs, methods, limitations, and revisions remain traceable to the project decision.
Should two designers get the same result from the same software?
Only if their software version, site model, weather data, equipment, settings, time basis, loss treatment, and requested outputs also match. A shared tool does not force shared judgment. Export the input reports, reconcile differences one category at a time, and rerun a controlled case before attributing the gap to calculation error.
Which yield-model input should reviewers compare first?
Begin with system identity and output boundary: site, array areas, module count, DC and AC capacity, reporting period, and energy point reported. Then compare weather and geometry. This order catches scope mismatches before the team spends time debating smaller loss settings inside two forecasts that describe materially different systems.
Can a solar yield forecast guarantee future production?
No model can remove future variation in weather, soiling, shading, availability, equipment condition, operations, curtailment, or site change. A contract may define a separate performance commitment, but that requires its own qualified review. Present forecast energy as modeled output with stated inputs and uncertainty, not as a meter reading from the future.
How should a design team resolve a disputed forecast?
Freeze both original cases, create an input-difference register, agree the comparison boundary, and change one category at a time in a controlled model. Record each run and its effect. Escalate unresolved site, engineering, contractual, or model-validity questions to the appropriate reviewer rather than averaging the forecasts into an unsupported compromise.
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.
