Why Solar Designers Produce Different Yield Forecasts

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.

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:

1. Match the project and output boundary.
2. Match array size and equipment identity.
3. Compare weather source and period.
4. Compare geometry, orientation, and shade.
5. Compare component and conversion models.
6. 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.

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 establish 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.

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. The generation and financial workflow can connect modeled energy to scenario analysis, but forecast energy and customer savings must 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.

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:

1. Freeze and hash or otherwise retain both original model exports.
2. Build an input-difference register with evidence links and owners.
3. Agree one site, system, period, and output boundary for comparison.
4. Select a controlled baseline model and record its version.
5. Change one input category, rerun, and retain the result.
6. Review material effects and resolve or preserve each difference.
7. 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.

Why can two solar forecasts for the same site differ?

Two solar yield forecasts for the site differ when their project boundary, weather data, timestamps, roof geometry, orientation, shading, equipment, electrical configuration, loss treatment, model version, or reported energy point does not match. The difference can also come from scenario choices, so reviewers should reconcile inputs and methods before treating disagreement as a calculation error or selecting the larger result.

Start with scope. Confirm that both runs cover the same property, buildings, array areas, module count, DC and AC configuration, operating scenario, reporting period, and energy point. A report that includes another carport or reports gross DC energy is not directly comparable with a net AC forecast for a smaller system.

Then move through the calculation chain. Weather and timestamps define the resource presented to the model. Geometry and shade define the receiving surfaces and obstructions. Equipment and topology define conversion. Losses and availability define additional treatment. The report boundary defines which modeled energy appears on the page.

Use a difference table that makes the mechanism visible:

Do not use annual totals to guess which layer differs. Two runs can reach similar annual energy through offsetting choices, while two well-supported scenarios can differ materially because their weather or site assumptions answer different questions. Compare intermediate records where the software exposes them.

Illustrative workflow example, not a customer result: Two designers model the same address and produce different annual reports. The identity check shows that one run includes an additional roof plane and reports a different output boundary. The team preserves both files, aligns the project and report scope, and reruns a controlled case before reviewing weather, shade, equipment, or losses. Nobody averages the original totals or calls the higher result more accurate.

The example demonstrates review order. A scope mismatch is cheaper to find than a deep debate about loss percentages, and it can explain the entire visible gap. If it does not, the team continues one input category at a time.

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.

Build team controls without freezing judgment

Standardization should make differences visible, not force every project through one undocumented default. Maintain approved weather sources, component libraries, assumption sets, model versions, naming rules, and review templates. Add a controlled exception process for site evidence that justifies a change.

Create a model run record with project, author, date, version, input set, evidence references, output boundary, reviewer, exceptions, and superseded run. Keep customer-facing figures linked to that record so a later revision can identify which proposal changed.

Review sample projects across designers. Compare inputs first, then intermediate results, then outputs. If the team starts with annual energy, they can argue over the visible symptom while missing a recurring weather import or roof-orientation problem.

Train on discrepancy cases. Give two designers the same source package, then discuss where judgment diverged and what evidence would resolve it. The purpose is not to punish variation. It is to turn private assumptions into reviewable decisions.

Use software libraries carefully. Locking component or loss records can reduce accidental variation, but stale data can become a company-wide error. Assign ownership, update dates, source records, validation, and retirement rules.

The solar design review checklist provides release levels for concept, coordination, permit, procurement, and construction outputs. Add yield-model identity and reconciliation to the level where forecast energy influences the decision.

Explain forecast differences to customers without losing trust

Do not tell a customer that the other model is “wrong” until the team can name and support the error. Explain the mechanism: a different weather file, roof orientation, shade scene, equipment selection, loss treatment, or reporting boundary changed the result.

Show a compact assumptions table beside the revised forecast. Use ordinary language and retain technical definitions in supporting records. Identify which values are site evidence, sourced data, company standards, and customer scenarios.

Make revisions visible. State which input changed, why it changed, which outputs were affected, who reviewed the revision, and which questions remain. Replacing a proposal silently makes an evidence correction look like concealment when the customer later compares files.

Avoid converting a model into a guarantee. Future production varies with weather, site condition, equipment, operations, availability, and other factors. Any contractual performance term must be separately defined and reviewed under the governing agreement and jurisdiction.

Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility.

Two designers do not need identical instincts. They need enough shared evidence, definitions, and version control for another person to understand the difference and choose the model basis responsibly.

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.