7 Solar Loss Factors Designers Should Document

A loss table can look exact while concealing more than it explains. Seven percentages appear in neat rows, but one includes shading already modeled elsewhere, another came from a default nobody can date, and a third uses “availability” to absorb every unexplained gap. The total is not auditable because the categories have no boundaries.

Consistent documentation means that two designers use the same definitions and record fields, not that they enter the same percentage for every roof. Site evidence, equipment, configuration, climate, and intended use should drive project values. The common system preserves how each effect enters the production chain.

This article is a desk-research framework for solar designers and reviewers. It does not prescribe a universal loss stack, predict actual production, or replace model documentation, field evidence, engineering, manufacturer requirements, or external review criteria.

These seven groups are a documentation framework, not seven additional deductions to enter into every tool. A category may already be calculated, may contain several separate mechanisms, or may be not applicable. Retain the model’s native definitions and note each group’s implementation before assigning any value.

Map every loss to an energy boundary

Before listing factors, draw the modeled path: available irradiance, plane-of-array irradiance, effective irradiance, module response, DC array output, inverter conversion, AC collection, meter or delivery point, and any time-based availability or curtailment. The exact chain depends on the tool and project.

Sandia’s PV Performance Modeling Collaborative publishes a modeling guide that organizes performance work into weather and design inputs, module modeling, inverter behavior, and AC output. That public structure is useful because “system loss” can refer to several different stages.

For each documented factor, record:

• physical meaning and excluded mechanisms;
• input or output energy boundary;
• source, observation date, and jurisdiction or site scope where relevant;
• value, unit, denominator, and time resolution;
• whether the model calculates it or accepts a user input;
• status as measured, sourced, estimated, or planning default;
• owner, review date, and change trigger;
• downstream result and proposal revision that uses it.

Never use one category to make the final number “look reasonable.” If an unexplained residual exists, investigate it or leave it visible. A miscellaneous percentage creates apparent agreement while destroying information.

What should a loss-category definition record contain?

A loss-category definition should record the mechanism, model boundary, implementation, unit and denominator, evidence source, exclusions, owner, and change trigger. It should also identify the downstream report or decision that consumes the result. Those fields turn a percentage from a loose label into a traceable modeling assumption that another analyst can inspect, update, or reject without guessing its original purpose.

Start with the mechanism. “Shading” is too broad if the record does not say whether it covers horizon obstruction, nearby objects, array self-shading, or an electrical response applied after a geometric calculation. The analyst reading the definition should know which physical effect belongs in the category and which nearby effects belong somewhere else. Exclusions are part of the definition, not an optional note.

Next, state where the mechanism acts. Name the input and output boundary using the terms displayed by the chosen model. For example, a field may modify plane-of-array irradiance before the module model, adjust DC array output, or reduce deliverable AC energy under an operating rule. A reviewer should not need to reverse-engineer that location from the final report.

Use a category dictionary that every project copies before values are entered:

The denominator deserves its own review. A time fraction, energy fraction, conversion efficiency, and change relative to a baseline are not interchangeable simply because the interface formats each as a percentage. Preserve the software’s native definition, then document any transformation used in a summary. If a report reverses the sign or converts an efficiency into a loss, record that operation and verify it through the approved calculation method.

Evidence scope also belongs beside the value. A manufacturer document may describe equipment behavior, a weather file may supply environmental inputs, and a site observation may describe current obstructions. Each answers a different question. Do not let a reputable source become support for a claim outside its actual scope.

Finally, connect the category to the assumption register used across production analysis. The nine assumptions to standardize in solar production analysis provide a companion structure for weather, equipment, geometry, and other shared inputs. The loss dictionary should reference those records instead of copying values into an isolated table that will age independently.

Copy-ready loss-definition record

Copy this block into a modeling brief or review ticket and complete every applicable line:

LOSS CATEGORY:
PHYSICAL MECHANISM:
INCLUDED EFFECTS:
EXCLUDED EFFECTS:
MODEL OR SOFTWARE VERSION:
APPLIED STAGE:
INPUT BOUNDARY:
OUTPUT BOUNDARY:
IMPLEMENTATION FIELD OR SUBMODEL:
VALUE, UNIT, AND DENOMINATOR:
TIME AND SPATIAL RESOLUTION:
EVIDENCE SOURCE AND OBSERVATION DATE:
STATUS: MEASURED / SOURCED / ESTIMATED / DEFAULT / CALCULATED / REQUIRED
OVERLAP CHECKED AGAINST:
OWNER AND REVIEWER:
CHANGE TRIGGER:
DOWNSTREAM REPORT OR DECISION:
OPEN LIMITATION:

An incomplete record is still useful if the missing item is visible. Mark it as pending, restrict the scenario to its intended decision, and name the evidence needed to replace the assumption. Blank fields that quietly pass into a proposal are much harder to control than declared gaps.

1. Shading needs geometry, date, and method

Shading can come from roof obstructions, nearby buildings, terrain or horizon, trees, array rows, and temporary or planned objects. It varies by time and location. One annual percentage may be a report output, but the assumption record should point to the geometry and method that produced it.

PVPMC groups resources for shading, soiling, and reflection losses. Grouped documentation does not make the mechanisms interchangeable. A shade model begins with object and array relationships, sun position, and the method used to translate shade into electrical effect.

Document:

Reopen shading after layout movement, new site evidence, vegetation changes, adjacent development, or equipment relocation. Do not keep an old shade report attached to a new array merely because both show the same module count.

2. Soiling and snow require an operating story

Soiling represents material accumulating on module surfaces and changing received irradiance. Its pattern can vary with precipitation, dry periods, dust sources, tilt, cleaning, and local conditions. Snow is different and may require a separate method where relevant. Do not place both under one unexplained seasonal haircut.

PVPMC’s soiling-loss resources describe approaches and models for soiling. A project value still needs a source suited to the site and a clear cleaning assumption. Vendor guidance or a regional study should not be presented as a measured condition on the roof.

Record whether the input is an annual average, monthly profile, daily accumulation model, measured soiling ratio, or another representation. State cleaning events and whether natural cleaning is modeled. Keep maintenance planning separate from guaranteed future execution.

If no local data exists, label the value as estimated and show sensitivity. A proposed cleaning schedule can be a scenario, not a promise that every event occurs on time or restores output to a fixed level.

3. Optical reflection needs its own definition

Light striking a module at an angle can experience reflection effects. Modeling may use an incidence-angle modifier or another optical treatment. Do not add a separate “reflection loss” if the module or irradiance model already applies the effect.

PVPMC documents incident-angle reflection losses and several model forms. Record the selected method, parameters, module or cover basis, and where it is applied. A default method can be reasonable for screening, but it remains a declared model choice.

Optical categories are particularly prone to naming overlap. “IAM,” “reflection,” “optical,” and “effective irradiance” may describe related positions in different tools. Build a translation table when analysts compare platforms. The table should state whether each interface field is an input, model calculation, or report output.

Do not combine spectral treatment, reflection, and soiling merely because they all affect irradiance. Their evidence and model logic differ, and combined reporting makes later updates difficult.

4. Temperature loss begins with more than ambient temperature

PV electrical behavior changes with cell or module temperature. A production model estimates operating temperature from weather, irradiance, mounting, and chosen model parameters. Ambient temperature is an input to that relationship, not a substitute for module temperature.

PVPMC collects cell-temperature model documentation, and the Department of Energy discusses temperature among PV performance and efficiency factors. Neither source selects the correct project parameters automatically.

Document weather fields, temperature model, parameter source, mounting configuration, airflow or standoff representation, module coefficients, and software version. Check units. A copied parameter set can survive a roof-type or mounting change because the annual result still looks plausible.

Run sensitivity when mounting information remains preliminary or the result materially affects the decision. Replace the screening assumption when the design selects a different support condition or module.

5. Mismatch and DC electrical losses need separate sources

Mismatch describes differences among modules or strings that prevent the group from operating as identical devices. Causes and model treatments can include manufacturing variation, irradiance differences, temperature differences, degradation, and other conditions. DC wiring and connection losses arise through electrical resistance and design configuration. Keep the categories distinct.

For mismatch, record what variation the model represents, its source, grouping, and whether shade or soiling nonuniformity is already modeled elsewhere. For wiring, record the electrical design basis, conductor and route assumptions, operating point or method, and where the loss ends. A generic DC percentage should not replace required electrical calculations or qualified design.

Do not use a published rule of thumb as site evidence without checking scope. Early screening may need a default. Later stages should reconcile the production input with the current stringing, conductor, connector, and layout basis.

Watch for double counting between module mismatch models and blanket loss fields. Also check whether the software’s module parameter set already incorporates any effect the analyst is adding separately.

6. Inverter and AC losses depend on the selected configuration

Inverter conversion is often modeled from equipment-specific behavior across operating conditions, not one fixed efficiency. Clipping, standby or night use where included, transformer effects, AC wiring, collection, and auxiliary loads can occupy different parts of the chain.

PVPMC’s DC-to-AC conversion overview identifies conversion losses and efficiency models. The project should name its reporting point. “Annual AC energy” is incomplete if one analyst reports at inverter terminals and another after modeled transformer and wiring effects.

Document exact inverter model, quantity, DC allocation, operating limits, efficiency representation, clipping method, control settings, AC collection assumptions, transformer model where used, and auxiliary consumption treatment. Reconcile the configuration with the SLD.

When an inverter is substituted, rerun the electrical and production review. Similar nameplate rating does not prove identical input limits, conversion behavior, clipping, or control response.

7. Availability and curtailment should not become a junk drawer

Availability commonly represents whether equipment or the plant can operate, while curtailment represents a limit or instruction that reduces otherwise available output. Model definitions vary. Scheduled maintenance, failures, grid outages, export limits, clipping, snow, and soiling should not all be placed into one “availability” line without a declared method.

Separate at least:

• equipment or plant availability assumption;
• planned maintenance treatment;
• grid or utility outage treatment if included;
• export control or curtailment rule;
• contractual or operational limitations;
• model mechanisms already represented elsewhere.

Record whether the effect is a time fraction, energy fraction, chronological rule, event series, or another method. Percentages with different denominators are not comparable. A flat annual deduction may be an early scenario, while a time-dependent control may be required for load and tariff analysis.

Do not infer future availability from a single vendor statement or unrelated project. Use the evidence and review standard required by the customer, contract, finance party, insurer, or responsible analyst. Keep uncertainty visible when no suitable dataset exists.

Prevent double counting with a loss ledger

A loss ledger maps each mechanism to one stage and one implementation. Build it before tuning values.

Review the ledger blind to the final annual number. If analysts begin with a preferred result, they can unconsciously use generic losses to close the gap. A defensible process lets the input evidence drive the model and accepts that the result may challenge the early expectation.

Do not compute total loss by mentally summing row percentages. Use the model’s documented sequence or a validated calculation with declared denominators. Preserve intermediate outputs where possible so a reviewer can trace energy through the chain.

How can analysts detect double counting in a solar loss model?

Analysts can detect double counting by tracing the customer-facing output backward through intermediate energy boundaries, then matching each reported loss to the physical mechanism and software field that applied it. Duplicate names are not the only warning. Two differently named fields can represent the same effect, while one shared label can hide several mechanisms with different denominators or time bases.

Begin with a clean copy of the scenario and a ledger that does not assume the report is correct. Record the raw output names exactly as the software presents them. Then add the internal category name, physical mechanism, applied stage, and report label. The translation exposes collisions that a polished customer table can hide.

Use this diagnostic sequence:

1. Select the exact output shown to the customer and record its scenario, run, design, equipment, weather, and reporting boundary.
2. Move backward to the immediately preceding model output. Record the mechanism or calculation that connects the two boundaries.
3. Continue backward until the trace reaches the weather and design inputs. Do not skip a stage because its displayed change looks small.
4. Map every user-entered percentage, physical submodel, time series, control rule, and report adjustment to one position in that trace.
5. Compare each mechanism with neighboring entries. Ask whether either entry includes the other, receives an already-adjusted input, or changes the same timestamps.
6. Review denominators and sign conventions. An efficiency, a loss relative to an upstream value, and a fraction of unavailable time may all be displayed with a percent symbol.
7. Neutralize one manual input at a time in a diagnostic copy where the tool and review method allow it. Inspect the affected intermediate boundary, not only the annual total.
8. Record the finding and repair its origin in the model, assumption register, or publishing layer. Do not patch only the final loss table.

The key question at each stage is simple: has this energy already been changed for the mechanism I am about to apply? A soiling-adjusted irradiance series followed by a separate blanket soiling field deserves investigation. So does a module or mismatch model followed by a generic mismatch percentage whose definition includes the same variation.

Names can mislead in the other direction. “Availability” may represent an equipment state in one tool and a post-model energy deduction in another. “System loss” may be a report grouping rather than a calculation field. The reviewer needs the implementation and boundary before deciding whether two rows overlap.

Illustrative workflow example, not a customer result: An analyst sees “near-object shade” in the geometric model and “shading allowance” in the loss table. The labels sound related, but that alone does not prove duplication. The analyst traces the effective-irradiance output, confirms whether the shade model already modifies it, reads the allowance definition, and checks the downstream DC boundary. If both entries represent the same obstruction at the same modeled stage, the analyst removes or redefines one in the diagnostic copy, reruns the approved workflow, and records the repair. If the allowance covers a distinct mechanism, the analyst documents that exclusion rather than merging the labels on sight.

The example contains no assumed energy value because the decision does not require one. The evidence is the boundary trace and the field definition. Any numerical comparison from the diagnostic run should be generated by the software or an approved calculation, then stored with the scenario rather than recreated from memory.

A disagreement between reviewers is a reason to improve the dictionary. Ask each reviewer to state the mechanism, input boundary, output boundary, and implementation they believe the row represents. If those descriptions differ, the category was never stable enough for release, even if both reviewers happened to accept the same annual number.

Tie loss assumptions to release maturity

At lead screening, company defaults may support a qualified comparison when categories and limitations are visible. At proposal stage, replace defaults with project evidence for geometry, shade, equipment, and operating conditions. At technical, contract, or finance review, follow the data and method required by the responsible party.

Use statuses:

1. Default for screening: approved internal value with definition and expiry.
2. Project estimate: chosen from project context but not measured on site.
3. Measured or observed input: captured through an identified method and period.
4. Model-calculated effect: output of a documented mechanism using bound inputs.
5. Externally required input: specified by a customer, lender, insurer, contract, or authority with source.

One status is not automatically “better.” A measured short period may be less representative of a long-term condition than a well-selected dataset. The register should let the reviewer examine suitability rather than treating labels as a ranking.

Solar Designing supplies the current layout, the Generation and Financial Tool supports modeled scenarios, and Solar Proposals carries selected outputs. Keep all three on the same scenario and revision where they share assumptions.

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.

Review changes by mechanism, not by total result

When a model result changes, compare inputs and intermediate energy boundaries. A lower annual value may come from a new weather file, changed shade geometry, different module model, revised temperature treatment, inverter clipping, or an added availability assumption. The total alone does not reveal the cause.

Run controlled scenarios where one mechanism or connected group changes at a time. Record the old and new source, value, model version, output delta, and decision. A sensitivity result describes the model under two assumptions; it does not state the likelihood of either future.

Publish a concise loss table beside the result with definitions and sources, then link to the ledger. The table should help a customer see what was modeled without implying that every percentage was measured at the future site.

Consistent loss documentation protects the argument behind the production number. Another analyst can see where irradiance changed, where DC became AC, which operating limits were included, and what must be reviewed when the design moves.

Audit one scenario from the report backward

Forward review starts with inputs and follows the model. A backward audit starts with the customer-facing output and asks what produced it. Both views are needed because report templates can detach from the current run even when the model itself is well controlled.

Choose the annual production value shown in the proposal. Identify its scenario ID, model file, run date, output boundary, layout revision, module and inverter configuration, and weather source. Then locate the loss report and trace each of the seven categories to its implementation. If the proposal cannot identify that run, stop before debating whether a percentage is suitable.

Use a worksheet:

Next, search for unclassified loss fields in the software and report. Terms such as “other,” “system,” “miscellaneous,” “derate,” and “adjustment” deserve investigation. They may be valid fields in a documented model. They may also contain a manual value added to close a difference. Record the actual meaning and denominator or remove the entry.

Check sign conventions. Some tools display losses as positive percentages, others as negative changes, and some report efficiencies. A reviewer can reverse or double an effect when moving values between systems. Preserve the raw output label and document any transformation used in the proposal.

Inspect seasonal and daily patterns rather than only annual percentages. A flat annual soiling input and a monthly soiling profile may produce similar annual energy while changing the timing used for load analysis. Curtailment during selected hours can differ materially from an equal annual deduction. The intended decision determines whether chronology matters.

Finally, rerun a copy with each manual loss input neutralized one at a time, where the software and review method allow. Compare the intermediate boundaries. This is not a recommended production scenario. It is a diagnostic that reveals whether the input acts at the documented stage and whether another mechanism already produces the same effect.

Record every audit finding against its origin. A stale shade scene needs a design-data repair. A hidden report adjustment needs a publishing repair. A duplicated loss needs model-configuration repair. A missing source needs research or a visible estimate status. Patching the final table alone leaves the defect ready to return.

When should a solar loss summary be held from release?

A solar loss summary should be held from release when the result cannot be tied to one model run, current design revision, declared output boundary, and reviewed assumption ledger. A missing source, unexplained adjustment, duplicated mechanism, stale geometry, or unresolved reviewer decision is enough to pause the handoff. Release resumes after the defect is corrected or the responsible reviewer authorizes a bounded use appropriate to the intended decision. Disclosure alone does not close a required technical or external review.

A hold is a workflow state, not a verdict that the whole project is wrong. It prevents a result from moving farther than its evidence. The owner should record what failed, which outputs are affected, who decides the repair, and what proof closes the hold. Vague instructions such as “check losses” keep work stuck because nobody knows what completion looks like.

Use a release record that separates blocking defects from visible limitations:

Not every uncertainty requires stopping all work. A screening scenario can move forward when the estimate is labelled, the intended use is narrow, and the event that replaces it is recorded. The same unresolved assumption may block a finance submission, contract exhibit, or engineering release because those uses apply a different evidence standard. The release record must name the intended decision.

Treat stale links between model and proposal as blocking. A technically sound model cannot support a customer-facing number if the proposal points to another run. Likewise, a corrected proposal does not repair an undocumented field inside the model. Close both sides of the handoff and record their shared scenario identifier.

Copy-ready release-or-hold record

OUTPUT UNDER REVIEW:
INTENDED DECISION OR AUDIENCE:
SCENARIO AND RUN IDENTIFIER:
LAYOUT AND EQUIPMENT REVISION:
WEATHER OR SITE-EVIDENCE BASIS:
OUTPUT BOUNDARY:
LOSS LEDGER REVISION:
OPEN FINDING:
AFFECTED DOWNSTREAM FIELDS:
STATUS: RELEASE / RELEASE WITH VISIBLE LIMITATION / HOLD
LIMITATION TEXT SHOWN TO READER:
REPAIR OWNER:
QUALIFIED OR EXTERNAL REVIEWER, IF REQUIRED:
EVIDENCE REQUIRED TO CLOSE:
REVIEW DATE AND CHANGE TRIGGER:

When a finding affects only one comparison or claim, restrict that output instead of allowing the defect to contaminate the whole proposal. For example, the team may hold a production comparison that depends on unresolved equipment behavior while continuing to collect site details. The record should say what remains usable and why.

Close a hold only after inspecting the repaired origin and its downstream consumers. A changed loss input can require a rerun, an updated summary table, a revised proposal claim, and another external review. Checking only the first file leaves the old value circulating elsewhere.

Keep software inside its proper boundary. SurgePV can support connected design, model, and proposal records, but it cannot decide whether evidence satisfies an engineer, authority, lender, insurer, utility, contract, or customer. Those reviewers retain responsibility for their approvals. The useful software outcome is a traceable handoff that shows them exactly what changed and what remains open.

Give customer readers an honest loss summary

The customer usually does not need every internal parameter, but they do need the assumptions that could change their decision. Present loss categories in plain language beside the model basis, and identify which are site-derived, product-derived, default, or estimated. Explain that categories can be calculated at different stages and are not necessarily additive.

Keep the detailed ledger available for technical review. The summary can group related minor components if the grouping has a stable definition and no effect is counted elsewhere. Do not group away a material uncertainty, such as unknown future shade, a preliminary equipment selection, or an unverified operating restriction.

If the proposal compares options, hold shared assumptions constant unless the option itself changes them. A different module may require a different electrical or temperature model. A different array layout changes shade and geometry. Record those coupled changes so the comparison does not attribute every energy difference to the label on one product.

The strongest disclaimer is a visible boundary, not vague legal language. State which configuration was modeled, which evidence remains pending, and which event will trigger an update. That gives the customer a practical way to understand why a later survey or substitution may change the result.

Frequently Asked Questions

Can solar loss percentages simply be added together?

Do not add displayed percentages unless the model definition and calculation method explicitly support that operation. Losses can occur at different stages, interact, or be applied chronologically or multiplicatively. Use the model’s documented chain or a validated calculation, preserve units and denominators, and check that no mechanism appears twice.

Is shading loss the same as soiling loss?

No. Shading represents irradiance blocked by objects or array geometry, while soiling represents material accumulated on module surfaces. Models may place them near each other, but their evidence, spatial and seasonal patterns, mitigation, and review triggers differ. Keep separate records even when a reporting tool groups their output.

Where should inverter clipping be documented?

Document clipping within the inverter and DC-to-AC configuration, with the selected inverter model, DC array, operating limits, weather basis, output boundary, and simulation method. Do not also place the same modeled energy effect in a generic loss percentage. Recalculate when stringing, DC capacity, inverter quantity, or controls change.

How should a team choose an early-stage default loss?

Choose defaults from a documented company method and suitable evidence, label them as screening assumptions, define what each category includes, and set a replacement trigger. Run sensitivity when the value can change the decision. A default becomes stale when site, equipment, configuration, climate, or operating evidence provides a more specific basis.

Does documenting losses make a production estimate accurate?

Documentation makes the model reproducible and reviewable; it does not guarantee accuracy or future generation. Weather, site conditions, installation, equipment behavior, outages, maintenance, and operating limits can differ from assumptions. Report the modeled basis, output boundary, uncertainty, intended use, and changes that require the scenario to be rerun.