Back to Blog
solar design 34 min read

Solar Engineering Services: Scope and Buyer Guide

Compare solar engineering services through project stages, disciplines, controlled inputs, deliverables, professional boundaries, QA, changes, and acceptance.

Keyur Rakholiya

Written by

Keyur Rakholiya

CEO & Co-Founder · SurgePV

Rainer Neumann

Edited by

Rainer Neumann

Content Head · SurgePV

Published ·Updated

Quick Answer

Solar engineering services convert verified project requirements into coordinated energy, electrical, structural, civil, grid, controls, construction, and commissioning deliverables. Buyers should assemble the scope by project stage and discipline, then control inputs, design criteria, responsibilities, interfaces, issue status, reviews, changes, and acceptance evidence.

Solar engineering services should be assembled around decisions, disciplines, and project stages. A list of drawing names cannot show whether the package is suitable for approval, tender, construction, or commissioning.

The buyer should define the next decision first. Then assign inputs, technical work, interfaces, responsible people, deliverables, reviews, and acceptance evidence.

Quick Answer

Assemble the scope by project stage and discipline. Control the inputs, design criteria, responsibilities, interfaces, issue status, reviews, changes, and acceptance evidence before comparing providers.

Scope gateBuyer questionControlled evidence
ProjectWhat site, system, route, capacity, and commercial model are being engineered?Project definition and boundary register
StageWhich decision must this issue support?Stage matrix and permitted-use status
DisciplineWho owns each technical decision and interface?Discipline and responsibility matrix
BasisWhich verified inputs, criteria, standards, and assumptions apply?Dated design basis and input register
OutputWhich calculations, drawings, specifications, and records are required?Deliverable register with acceptance rules
QAWho checks, approves, changes, and closes each issue?Review plan, comments, revisions, and change log

This guide is a procurement framework. It is not project engineering, legal advice, authority approval, or a substitute for qualified professional review.

Keep the Solar Engineering Services Scope Distinct

This page covers broad service assembly. It helps buyers connect project stages to disciplines and outputs.

It does not assess a provider’s corporate governance. Use the solar engineering company guide for entity, staffing, insurance, and business-continuity checks.

It does not define a developer’s entire investment process. The engineering services for developers guide covers development-stage decisions and transaction gates.

It does not teach electrical calculations. Use the solar electrical engineering guide for DC, AC, protection, grounding, interconnection, and controls detail.

The solar detailed engineering guide covers construction-level package depth. The solar design company guide focuses on provider selection.

Reference these adjacent pages in the RFQ. Do not duplicate their scope under vague labels.

Classify the Project Before Assembling Services

A residential rooftop, industrial facility, ground plant, floating array, carport, and storage project need different disciplines. Their authority and construction routes can also differ.

Create a one-page project definition. Record:

  • Site address, country, state or province, and local authority
  • Owner, applicant, off-taker, facility operator, and land or roof rights
  • Rooftop, ground, canopy, floating, brownfield, or mixed site type
  • Proposed DC, AC, storage, and generator capacity basis
  • Grid-connected, isolated, backup, captive, export, or other operating route
  • Service voltage, point of connection, ownership line, and utility
  • Residential, commercial, industrial, utility, or community use
  • New construction, retrofit, expansion, repowering, or repair
  • Financing, insurer, lender, and independent-review interfaces
  • Target decision, construction window, shutdowns, and operational constraints

Do not infer site facts from a proposal drawing. Tag unknown items and assign a verification owner.

Define physical and professional boundaries

Mark where the appointed provider’s work begins and ends. Include equipment, land, roof, facility systems, utility assets, communications, and other disciplines.

Then mark professional boundaries. Identify which work requires a licensed, registered, chartered, or otherwise authorized person under the actual jurisdiction.

A provider may coordinate a discipline without accepting professional responsibility for it. The contract must state that distinction.

Build a Stage-by-Stage Service Matrix

The same drawing title can carry different maturity at different stages. Define the evidence needed for each decision.

Screening

Screening tests whether a concept deserves further expenditure. Inputs may be incomplete, so assumptions and uncertainty need visible control.

Possible outputs include fatal-flaw checks, indicative layout, connection screening, resource review, major site constraints, discipline needs, and next investigations.

Do not use a screening package for procurement or construction. Mark its limitations and expiry triggers.

Concept and feasibility

Concept work compares viable architectures. Feasibility develops the preferred option enough to expose technical, approval, constructability, and cost risks.

Outputs may include option layouts, preliminary energy models, electrical architecture, foundation concepts, drainage concepts, access, grid assumptions, fire interfaces, and investigation scopes.

Show which inputs are measured, supplied, assumed, or pending. Give every uncertainty a decision date.

Permit or approval

Permit scope serves a named authority and application. Obtain the current checklist for the actual jurisdiction and project.

Define applicant, form owner, required professional, submission format, fees, comments, resubmissions, site visits, and validity periods. Never assume one authority’s package applies elsewhere.

Approval documents may not contain construction detail. State whether an approved permit issue can direct field work.

Interconnection

Interconnection work addresses the utility or network boundary. Define the current application route, study responsibility, models, protection, metering, communications, settings, witness tests, and energization steps.

Utility acceptance remains separate from professional responsibility. Neither one guarantees construction quality.

Tender

Tender engineering gives bidders a common technical basis. It should reduce hidden substitutions and incompatible assumptions.

Provide performance requirements, reference layouts, interfaces, minimum evidence, schedules, specifications, BOQ basis, deviations, and bid-return forms. State which quantities bidders must verify.

Detailed design and IFC

Detailed design resolves calculations, interfaces, equipment, routes, details, schedules, settings, and specifications. Issued for construction, or IFC, is a controlled status for approved field use.

Define the checker, approver, review closure, vendor-data status, constructability review, and authorized issuer. Do not label unfinished work IFC.

Construction support

Construction support manages requests for information, submittals, substitutions, unforeseen conditions, redlines, site observations, tests, and defects.

State response times as contract terms only after confirming capacity. Define emergency escalation separately from routine review.

Commissioning and as-built

Commissioning proves defined installed functions through controlled procedures and records. As-built documents record the accepted installed configuration.

Define prerequisites, instruments, witnesses, expected results, pass criteria, defects, retests, settings, configurations, training, and handover. The solar commissioning checklist provides a focused evidence plan.

Use the solar handover pack guide to define final records. A marked-up drawing becomes an as-built only after responsible verification and controlled issue.

Control Inputs and the Design Basis

The design basis should connect project requirements to verified inputs and engineering criteria. It is a live controlled document, not a generic template.

Build an input register

Record each input’s source, date, revision, status, owner, verification method, dependent outputs, and closure date.

Input groups can include:

  • Boundary survey, topography, coordinates, and legal constraints
  • Solar resource, weather, soiling, albedo, and horizon data
  • Utility bill, load, demand, power quality, and operating schedule
  • Service, network, fault, metering, and interconnection information
  • Module, inverter, storage, transformer, and balance-of-system data
  • Roof, structure, foundations, materials, and existing drawings
  • Geotechnical, hydrology, flood, drainage, erosion, and contamination data
  • Wind, cyclone, seismic, temperature, humidity, salt, dust, and corrosion conditions
  • Fire access, emergency response, hazardous areas, and process risks
  • Roads, lifting, laydown, trenches, routing, security, and construction access
  • Authority, utility, land, building, environmental, and professional requirements
  • Owner standards, insurer requirements, warranties, and operational plans

Separate facts from assumptions. A reasonable assumption can still be unsuitable for construction.

Create the design basis

The design basis should state project definitions, boundaries, adopted criteria, accepted inputs, assumptions, exclusions, interfaces, design life, and issue-stage limitations.

List standards and regulations by exact title, edition, amendment, adoption route, and applicable discipline. Do not paste a global code list into every project.

India projects can start with the CEA’s official 2023 electrical safety regulations. They still need the actual state, licensee, inspectorate, and local authority route.

Every design-basis change needs an impact review. Identify affected calculations, drawings, costs, submissions, procurement, construction, tests, and schedules.

Assemble Disciplines and Interfaces

Buy the disciplines the project needs. Do not assume a multidisciplinary brand includes every specialist.

Energy and layout

Energy work can cover resource inputs, shading, layout assumptions, losses, availability inputs, uncertainty, and scenario comparisons. Define whether the result is indicative, contractual, lender-reviewed, or operational.

The solar energy yield assessment guide covers this discipline in depth. No model can guarantee future weather or energy.

Layout work coordinates equipment, access, shading, setbacks, fire paths, maintenance, drainage, structure, cables, roads, fencing, and construction sequence. A drawing without those interfaces is incomplete.

Electrical and protection

Electrical work can cover architecture, strings, DC and AC circuits, conductors, transformers, equipment, protection, grounding, metering, controls, and commissioning requirements.

Protection work may need fault studies, device ratings, coordination, settings, and utility interfaces. The actual study package depends on project evidence and adopted requirements.

IEC publishes IEC 62548-1:2023 for PV array design. Its scope does not create a universal multidisciplinary engineering package.

Grid and interconnection

Grid work starts with the actual connection point and network operator. It may cover applications, models, load flow, fault, stability, harmonics, protection, reactive power, control, metering, and testing.

Do not assume each study is required. Record the utility trigger, model format, scenario, data owner, reviewer, and acceptance route.

Structural

Structural work can cover existing roofs, attachments, frames, trackers, canopies, equipment supports, foundations, and temporary conditions. It depends on verified geometry, materials, condition, loads, and site hazards.

The solar structural engineering guide provides a discipline-specific procurement method. A module mounting certificate does not verify an existing structure.

Civil and geotechnical

Civil scope may include grading, drainage, erosion control, roads, pads, trenches, fencing, water crossings, and construction staging. Coordinate it with environmental and land approvals.

Geotechnical scope may include desk study, investigation plan, boreholes, tests, groundwater, corrosion, soil parameters, foundation recommendations, and construction verification. Use the geotechnical survey guide to define evidence.

Do not transfer parameters from a nearby site without a responsible basis. Conditions can change across short distances.

Fire and emergency interfaces

Fire scope can affect access, spacing, shutdown, detection, suppression, water, labels, emergency plans, storage, and responder coordination. Requirements vary by jurisdiction, building, occupancy, and technology.

Identify the fire professional and authority where required. Electrical, architectural, controls, and operational teams must close the same interfaces.

Controls and SCADA

Controls scope should define operating modes, cause and effect, alarms, interlocks, setpoints, local and remote authority, communications, logging, time synchronization, access, backup, and recovery.

SCADA points need identifiers, units, scaling, ranges, quality, permissions, update rates, and tested protocol versions. A protocol name alone does not prove interoperability.

Commissioning and operations

Commissioning engineering converts design intent into measurable tests. Operations review checks access, isolation, spares, monitoring, cleaning, inspection, diagnostics, repairs, and records.

The NREL PV and storage O&M guide connects design quality with deployment, commissioning, and operational planning. It remains guidance, not a local authority rule.

Define Deliverables by Decision

Create a deliverable register instead of asking for “complete drawings.” Each row should identify:

  • Discipline and stable deliverable identifier
  • Title, purpose, and permitted use
  • Project stage and maturity
  • Required inputs and dependencies
  • Calculation, model, study, drawing, schedule, or specification type
  • File format, native format, and software version
  • Author, checker, approver, and external reviewer
  • Submission, comment, revision, and acceptance rules
  • Issue date, status, revision, and transmittal
  • Record retention, ownership, licence, and exit format

Calculations and models

Require formulas, inputs, units, assumptions, methods, results, limits, and checker evidence. Native models may be needed for later updates.

Define model ownership and compatible export formats. Retain equipment libraries and source documents used by the accepted issue.

Drawings and schedules

Use consistent identifiers across layouts, diagrams, details, equipment, cables, settings, BOQ, installation, tests, and asset records.

Every drawing needs title, stage, status, revision, author, checker, approver, date, notes, and references. Define whether it is informative, submitted, tender, construction, or record status.

Specifications and BOQ

Specifications should state performance, materials, workmanship, testing, documentation, substitutions, and acceptance. Avoid copying requirements that conflict with selected equipment or authority rules.

A BOQ needs a measurement basis and exclusions. Mark provisional quantities and purchaser-supplied items.

Quantity accuracy depends on input maturity. Define how later changes affect price and schedule.

Assign Responsibility Explicitly

Create a responsibility matrix for every workstream and decision. Include owner, developer, engineer, specialist, utility, authority, vendor, EPC, installer, controls integrator, commissioning authority, and operator.

Use verbs that can be verified. Examples include provide, verify, calculate, check, approve, sign, submit, answer, install, inspect, witness, accept, update, and retain.

Avoid “coordinate as required.” It hides who closes the interface.

Professional boundaries

Professional rules vary by jurisdiction and discipline. Verify actual statutes, boards, authority procedures, project type, and location.

Name who takes professional responsibility where required. Confirm who signs or seals each output, who can revise it, and who responds to field changes.

A seal, registration, or company certificate does not prove every discipline, office, or project is covered. Verify the named person’s current status and role.

Authority boundaries

Authorities decide their acceptance. The engineering team can prepare compliant evidence and support responses, but cannot guarantee approval or timing.

Define applicant ownership, fees, meetings, forms, submissions, comments, resubmissions, inspections, tests, energization, expiry, and record retention.

Operate Multidiscipline QA

Quality control should be planned for every issue. A final visual review cannot reconstruct missing input and decision history.

Use four review layers:

  1. Originator self-check against the design basis and input register.
  2. Discipline check of calculations, outputs, and technical decisions.
  3. Interface review across disciplines, vendors, authority requirements, and construction.
  4. Approval for the stated issue purpose by the named responsible role.

Track comments with identifier, source, date, owner, due date, response, disposition, evidence, and closure. Preserve rejected comments with reasons.

ISO describes responsibilities, documented information, measurement, and improvement in its ISO 9001 overview. Certification does not prove a specific solar package is correct.

The IEA PVPS June 2026 photovoltaic project decisions report treats quality decisions across the value chain as connected. Its utility-scale guidance is not a project contract.

Control issue status

Define every status in the project procedure. Possible statuses include draft, review, approval submission, tender, IFC, superseded, redline, and as-built.

Restrict who may issue, revise, and withdraw documents. Maintain a current register and transmittal history.

Prevent superseded issues from reaching the site. Confirm receipt and removal where necessary.

Control changes and substitutions

Record the reason, initiator, affected inputs, disciplines, documents, studies, approvals, costs, schedule, construction, tests, warranties, and final decision.

Equipment substitutions can alter electrical, structural, civil, fire, controls, energy, and approval assumptions. Require multidisciplinary impact review before acceptance.

Field conditions need technical queries and controlled redlines. Update calculations and submissions when their basis changes.

Write a Comparable Buyer RFQ

Give every bidder the same project definition, input pack, scope matrix, deliverable register, responsibility matrix, issue procedure, schedule, and commercial return form.

Ask each bidder to return:

  • Legal entity and contracting office
  • Named discipline leads and proposed checkers
  • Professional authority for the actual jurisdiction where required
  • Relevant redacted samples and references
  • Included disciplines, stages, deliverables, and native files
  • Inputs required from the buyer and external parties
  • Assumptions, exclusions, deviations, and specialist dependencies
  • Review cycles, comment allowance, construction support, and site visits
  • Information-security, access, retention, backup, and deletion controls
  • Programme, capacity, escalation, continuity, and handover plan
  • Fixed fees, rates, reimbursables, taxes, authority fees, and change basis
  • Insurance evidence where relevant

Normalize bids row by row. A lower headline fee may exclude studies, checking, native files, site support, comments, or as-builts.

Use the outsourced solar design services guide for delivery-model choices. Apply the solar design QA checklist to comparable samples.

Test the Provider Before Portfolio Award

Use a paid sample or pilot for material risk. Give shortlisted providers the same controlled inputs and representative problem.

Choose a task that crosses at least two disciplines. Examples include an equipment pad with cable routing or a roof attachment beside a drainage path.

Score:

Pilot gateEvidence
Input controlMissing, conflicting, and provisional inputs are logged before work
Technical methodCriteria, calculations, limitations, and sources are visible
Discipline interfaceActions have owners, dates, and closure evidence
TraceabilityIdentifiers agree across calculations, drawings, schedules, and BOQ
CheckingReviewer comments are specific, independent, and closed
Change controlOne controlled change reaches every affected output
UsabilityThe package supports its stated decision without hidden assumptions

Verify the actual proposed team. A marketing sample may have been produced by different people.

Define acceptance before the pilot starts. Do not create a passing score after reviewing the result.

Normalize Commercial Terms and Exit

Build a price table from the deliverable register. Each line should show quantity, unit, included review cycles, dependencies, fee, schedule, and acceptance milestone.

Separate fixed work from uncertain work. Site visits, authority comments, investigations, travel, specialist studies, and construction changes may need stated rates or allowances.

Define what triggers a change. A revised owner preference is different from correcting a provider error against an unchanged accepted basis.

Require a written change proposal before extra work begins. It should identify the cause, affected outputs, technical effect, fee, schedule, review, and approval owner.

Payment should follow accepted evidence, not file delivery alone. Possible milestones include accepted design basis, checked stage issue, closed comments, accepted IFC package, and verified records.

Do not retain an unreasonable payment until an authority acts outside the provider’s control. Link payment to duties the provider can perform and evidence.

Model total cost across the expected engagement. Include mobilisation, software or file conversion, specialist reviews, authority responses, site support, changes, travel, and final records.

Also price delay exposure caused by missing owner inputs. Both parties should see dependencies before signing.

Protect continuity and exit

Define what happens if named staff leave, the provider misses capacity, or the contract ends. Require notice, replacement approval, knowledge transfer, and current registers.

Set file ownership and permitted use in the contract. Include native files, neutral exports, calculation notes, models, libraries, source records, comments, settings, and transmittals where agreed.

Test one exit export during the pilot. Another qualified team should be able to identify the current issue, inputs, assumptions, open actions, and next decision.

Define data return, retention, deletion, backups, confidentiality, and access removal. Legal duties and owner record requirements may limit immediate deletion.

An orderly exit does not transfer professional responsibility automatically. The incoming provider must review and accept the scope it will own.

How to Evaluate Heaven Designs

Heaven Designs publishes a multidisciplinary solar engineering services catalogue. Treat it as a provider statement, not independent verification.

Disclosure: SurgePV and Heaven Designs have a commercial relationship. Heaven Designs must pass the same discipline, professional, sample, QA, capacity, security, revision, support, price, insurance, and exit gates as every alternative.

Request discipline-matched evidence through the published sample page. Verify its project stage, site type, voltage, disciplines, jurisdiction, and issue status.

Confirm named staff, checkers, professional boundaries, capacity, subcontractors, software, security, revision support, and field response in writing. Compare at least two alternatives under identical gates.

No related-party relationship should alter the score, contract, acceptance, or escalation process.

Keep SurgePV Within Its Software Boundary

SurgePV can support solar design calculations, workflows, and records within documented functions. It does not become the project’s engineer, authority, utility, contractor, equipment supplier, or commissioning party.

Users must verify software inputs and outputs against controlled project evidence. Preserve the software version, equipment data, assumptions, and exports used for each issue.

Do not present a software result as professionally accepted or approved for construction. Named responsible people must authorize its actual use.

Final Acceptance Checklist

Before accepting a stage package:

  1. Confirm the project definition, boundary, stage, and permitted use.
  2. Close or accept each input and assumption through a named owner.
  3. Verify the adopted requirements and current authority route.
  4. Reconcile calculations, models, drawings, schedules, specifications, and BOQ.
  5. Close discipline interfaces, vendor data, comments, deviations, and changes.
  6. Confirm author, checker, approver, professional, and authority responsibilities.
  7. Verify construction support, commissioning, redline, and as-built obligations.
  8. Test file access, native formats, version records, backups, and exit exports.
  9. Record open risks, defects, expiry dates, operating limits, and next decisions.

Acceptance does not guarantee approval, construction quality, yield, or performance. It confirms that the agreed evidence exists for the stated decision.

Frequently Asked Questions

What do solar engineering services include?

Scope may include screening, layouts, energy assessment, electrical and protection design, grid studies, structural, civil, geotechnical, fire, controls, drawings, specifications, BOQ, construction support, commissioning, and as-builts. The contract should name each discipline, stage, deliverable, interface, reviewer, and exclusion.

Are solar design and solar engineering the same?

Not necessarily. Design can include proposals, layouts, and product configuration. Engineering usually adds documented criteria, analysis, checking, technical responsibility, and controlled outputs. Buyers should compare the actual scope and responsibility instead of relying on either label.

Which project stages should an engineering scope define?

Define screening, concept, permit or approval, interconnection, tender, detailed design, IFC, construction support, commissioning, and as-built stages where relevant. State each issue’s purpose, input maturity, required decisions, reviewer, revision rules, and prohibited uses.

Can one provider cover every solar engineering discipline?

Possibly, but do not assume it. Verify named energy, electrical, grid, protection, structural, civil, geotechnical, fire, controls, and commissioning leads where required. Confirm their competence, professional authority, availability, checking, and interface responsibilities.

Which inputs should a solar engineering team receive?

Provide controlled site, survey, resource, load, utility, equipment, environmental, geotechnical, structural, civil, fire, access, construction, operations, authority, commercial, and schedule information. Record each source, date, revision, status, assumption, owner, verification method, and closure date.

What should a solar engineering deliverable register contain?

List every calculation, model, study, drawing, schedule, specification, BOQ, data sheet, submission, inspection plan, test procedure, record, and native file. Add format, stage, purpose, author, checker, approver, dependencies, issue date, revision, and acceptance rule.

How should professional and authority responsibilities be assigned?

Verify the actual jurisdiction, discipline, project type, voltage, capacity, site, and authority route. Name who prepares, checks, signs, seals where required, submits, answers comments, approves changes, inspects, tests, accepts, and retains each output.

Can a solar engineering provider guarantee approval or performance?

No. Authorities, utilities, equipment, construction, weather, operations, and site conditions affect outcomes outside the provider’s control. A provider can follow the agreed basis, correct included errors, support reviews, and manage included changes without guaranteeing approval, schedule, yield, or performance.

Is Heaven Designs automatically the best solar engineering provider?

No. SurgePV and Heaven Designs have a commercial relationship. Heaven Designs must pass the same discipline, professional, sample, QA, capacity, security, revision, support, price, insurance, and exit gates as every alternative.

About the Contributors

Author
Keyur Rakholiya
Keyur Rakholiya

CEO & Co-Founder · SurgePV

Keyur Rakholiya is CEO & Co-Founder of SurgePV and Founder of Heaven Green Energy Limited, where he has delivered over 1 GW of solar projects across commercial, utility, and rooftop sectors in India. With 10+ years in the solar industry, he has managed 800+ project deliveries, evaluated 20+ solar design platforms firsthand, and led engineering teams of 50+ people.

Editor
Rainer Neumann
Rainer Neumann

Content Head · SurgePV

Rainer Neumann is Content Head at SurgePV and a solar PV engineer with 10+ years of experience designing commercial and utility-scale systems across Europe and MENA. He has delivered 500+ installations, tested 15+ solar design software platforms firsthand, and specialises in shading analysis, string sizing, and international electrical code compliance.

Get Solar Design Tips in Your Inbox

Join 2,000+ solar professionals. One email per week - no spam.

No spam · Unsubscribe anytime

Book Free Demo