Answer
Review a complex solar roof plane by plane: verify geometry and source dates, locate and size obstructions, apply the project’s actual setback and access requirements, assess shading, and coordinate equipment and electrical grouping. Record unresolved conditions and responsible reviewers. Reconcile the accepted layout with materials, energy and proposal outputs; a clean model does not establish structural suitability or local approval.
A complex roof needs a traceable geometry and constraint record before a team optimizes module count. Dormers, valleys, upper roof planes and service equipment can change both usable space and shading. The checklist below is a proposed design-review method for installers and EPCs; it does not establish structural capacity, regulatory compliance or permission to install.
SurgePV publishes this guide and sells the software referenced. Product links identify relevant workflows rather than independently verified automation or approval capability.
Review the roof evidence before placement
| Check | Record | Resolve before relying on the layout |
|---|---|---|
| Roof planes | Plane ID, boundaries, dimensions, tilt, true-north orientation and evidence date | Conflicting imagery and survey measurements |
| Obstructions | ID, location, dimensions, height and source photo | Missing height, hidden equipment or uncertain position |
| Adjacent objects | Upper roofs, trees and neighboring buildings represented in the model | Unmodeled objects affecting the intended study |
| Setbacks and access | Requirement source, edition, local amendments and applicable interpretation | Assumed universal distances or blocked service routes |
| Structure and attachments | Roof condition, proposed mounting and responsible reviewer | Capacity, substrate or attachment questions beyond remote imagery |
| Equipment and electrical grouping | Exact equipment, orientation/shade groups and design basis | Compatibility, operating limits or grouping requiring qualified review |
A satellite image may support a preliminary concept while leaving material questions unanswered. Record which geometry was measured, inferred or unresolved. Use stable plane and obstruction IDs so a correction can be traced through photographs, notes and the revised layout.
Apply the actual project requirements
Do not copy a generic setback into every roof plane. Identify the jurisdiction, building and fire requirements, roof use, occupancy, service-access needs and applicable manufacturer instructions. Record the authority or responsible professional who resolves an interpretation.
New York City’s solar design-professional requirements illustrate a jurisdiction-specific review of affected rooftop, structural and electrical components. They are NYC guidance, not global setback rules. This article supplies no universal pathway width, roof-load allowance or electrical setting.
Drainage, maintenance access and planned roof work also need explicit consideration. A software exclusion area should carry its source and purpose; it is not evidence that the selected constraint meets the local requirement.
Start With a Single Source of Project Truth
The project record should contain the customer address and site reference, data-source dates, current layout revision, equipment selections, energy assumptions, open items, and the person accountable for each open item. Do not spread these controls across a proposal PDF, a chat thread, a spreadsheet, and a personal notebook. That makes it difficult to tell which value is current.
A shared workflow also changes the quality of the customer conversation. When a representative can show which figures are estimates and which have been verified, the proposal is easier to explain. This is especially important for production and savings. A generation estimate is a modeled result based on stated inputs, not a promise of output. Link customers and internal reviewers to the assumptions behind it, including irradiance source, shading treatment, system size, orientation, losses, rate assumptions, and the date of the model.
For a connected workflow, solar design software can keep design inputs and project outputs together instead of requiring the team to transpose values between unrelated tools. Use the platform as the project record only after your team agrees on the fields and reviews that must be present.
Define the Review Gates Before the Work Starts
A practical set of gates has four moments. First, qualify the opportunity: what is known about the site, load, decision process, and project objective? Second, review the preliminary design: can the layout, roof geometry, access, setbacks, and electrical approach support the concept? Third, review the commercial proposal: do the production, financial, scope, and exclusions describe the same project as the design? Fourth, release the handoff: has every customer-facing promise that affects delivery been transferred to the delivery team?
Each gate should have a purpose rather than a generic approval. For example, a preliminary-design gate is not an instruction to redraw every project. It is a check that the roof model and constraints are suitable for the level of certainty being represented. A commercial-review gate is not an accounting exercise. It is a check that a savings scenario uses the correct tariff, consumption period, escalation assumption if one is used, and finance terms supplied by the provider.
Review the Design Before You Trust the Numbers
Panel count is only one output. Review the roof planes, obstructions, access paths, setbacks, usable area, module orientation, stringing assumptions, and any required electrical or structural review. When a design is generated from imagery or an early site survey, label the confidence level. A later measurement may change the usable roof area or reveal equipment that is not visible in the first data set.
Shading deserves the same discipline. A model should name its source data and method, then make clear whether vegetation, near objects, horizon effects, and future construction are represented. The Solar shading analysis product page is relevant when a team needs a structured way to examine shading as part of the project workflow. It is not a substitute for the site-specific review required by local rules or the project’s engineering standard.
DOE’s PV design overview explains system components. Sandia’s shading, soiling and reflection overview identifies distinct modeling inputs and loss processes. Use the relevant methods and data in the project record rather than assigning one generic loss to every complex roof. Neither source validates the geometry or approves a particular design.
Keep Layout, BOM, and Proposal in Agreement
The bill of materials (BOM) should be tied to a revisioned design, not rebuilt from memory. At a minimum, compare module quantity, inverter quantity and rating, mounting approach, electrical accessories, and assumptions that change procurement or installation scope. If a substitution is proposed, record whether it changes electrical compatibility, layout, performance assumptions, warranty terms, or price.
Then compare the proposal to the same source record. The project name, system size, module count, expected production, scope, exclusions, financing scenario, and next step should tell one consistent story. A proposal that is visually polished but tied to a prior layout creates an avoidable customer-trust problem. Solar Proposals is designed around producing customer-facing materials from project work; teams should still retain a human review for customer commitments and local requirements.
Translate roof changes into the next output
If a plane becomes unusable or an obstruction moves, identify the modules, grouping, modeled energy, materials and scope affected. Each artifact can have its own version, but it must reconcile with the controlling project state. A roof correction should not leave an older layout in the customer proposal.
For the customer-facing financial and scope review, use the customer-ready proposal framework. For a sequential design workflow, see nine steps for complex multi-plane roofs. This checklist supplies the evidence record; those guides cover the next workflow and handoff.
Assign Owners for Exceptions, Not Just Tasks
Most problems appear in exceptions: a roof-plane measurement differs from imagery, the customer changes usage assumptions, an equipment item is unavailable, or a utility requirement changes. A task list alone does not resolve these cases. The record needs an owner, a due date, the decision required, and the project artifact affected. That lets the team decide whether to revise the layout, the financial model, the proposal, or all three.
Set an escalation rule as well. Questions involving code compliance, structural capacity, interconnection, electrical design, contractual scope, or a material production assumption should go to the qualified person designated by your organization. No checklist can turn a non-engineering review into engineering approval.
Measure Process Quality Without Inventing a Benchmark
Measure whether the control is being used, not whether a generic industry target has been met. Useful internal measures include the share of proposals tied to a current design revision, the number of open items at handoff, the time between a material change and a customer update, and the categories that drive rework. These are team diagnostics. They should not be portrayed as a promise of commercial outcomes.
A monthly review can be small. Select a handful of completed and delayed projects, inspect the record, and ask where an assumption became invisible. If the same issue repeats, add a field, gate, or owner to the workflow. If a control is never used, check whether it remains required, is redundant or needs a clearer owner before changing it. The goal is a record that supports real decisions, not a longer form.
A Field-Ready Checklist
- Confirm the current site and customer data source, including its date.
- Identify which inputs are confirmed, estimated, pending, or changed.
- Record the current design revision and its reviewer.
- Check layout, shading, access, equipment, and electrical assumptions for consistency.
- Reconcile the BOM and proposal with the controlling design state, preserving each artifact’s own version.
- Label production, tariff, incentive, and financing assumptions clearly.
- Assign an owner and due date to each exception.
- Escalate code, engineering, utility, and contract questions to the qualified reviewer.
- Save the approved customer-facing version and the delivery handoff record.
- Review recurring exceptions and improve the workflow at the next operating review.
Pro Tip
Place the source date next to every high-impact input. A value can be reasonable and still be stale. Date labels make follow-up faster and reduce arguments about which version the team used.
Release record
- Build one project record before the team produces multiple versions of the same information.
- Review the design, BOM, financial model, and proposal as connected artifacts.
- Treat exceptions as owned decisions and preserve the reason for each change.
Frequently Asked Questions
What should a complex solar roof checklist include?
Record plane geometry, obstruction locations and heights, source dates, shading inputs, applicable setbacks and access, structural questions, equipment and electrical grouping. Assign unresolved items and reconcile the accepted layout with materials, modeled energy and customer-facing outputs.
Can aerial imagery establish structural suitability?
No. Imagery can support a preliminary roof model but does not establish framing capacity, substrate condition or attachment suitability. Route the required site evidence and mounting questions to the responsible qualified reviewer before relying on the layout for installation.
Are solar roof setbacks the same everywhere?
No. Identify the project jurisdiction, applicable requirements, local amendments, roof conditions and relevant manufacturer instructions. Document the source and responsible interpretation instead of treating a default software distance as universal approval.
What should happen when a roof measurement changes?
Record the corrected evidence and identify the affected planes, modules, electrical grouping, energy result, materials and proposal. Recalculate or review the affected outputs as appropriate, issue reconciled versions and notify known recipients of superseded material information.
Sources and review scope
- DOE Solar Photovoltaic System Design Basics: component context.
- Sandia PVPMC shading, soiling and reflection overview: distinct model inputs and loss processes.
- NYC solar design-professional requirements: jurisdiction-specific review context.
Sources checked September 30, 2026. This is an editorial checklist, not a measured case study or approved project design.
Use a SurgePV demo to inspect how your proposed solar design workflow records geometry, constraints and output revisions on a representative roof. Confirm supported features and review responsibilities before using it for a customer commitment.
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.
