Prepared and reviewed by Sunlurio Engineering Team
Last Reviewed: 2026-08-16
Two quotations can show the same nominal lamp wattage and still describe materially different solar street lighting systems. Battery and solar-module assumptions, operating profile, optics, pole scope, civil works and technical documents can all differ behind the same headline value.
A useful BOQ review therefore checks more than price and wattage. It identifies the project inputs, configuration assumptions, scope boundaries and supporting evidence needed for a meaningful technical and commercial comparison. This guide is written for EPC contractors, municipal procurement teams, consultants, tender teams and project buyers who need to find missing information before quotation, tender submission or technical approval.
What Should You Check Before Comparing a Solar Street Light BOQ?
Quick Answer: Before comparing solar street light BOQs or quotations, confirm four things: the project inputs; the proposed luminaire, solar module, battery, controller and operating profile; the pole, civil, electrical and installation scope; and the technical documents required at the current project stage. Record whether each item is stated, missing or needs review. Lamp wattage alone does not establish an equivalent system.
The relevant fields vary by application and tender stage. A supply-only quotation, for example, will not carry the same civil or installation scope as a turnkey package. The purpose is not to force every document onto every BOQ line, but to make the assumptions behind each quotation visible.
Secondary CTA - Download BOQ Review Checklist: Use the public checklist to mark review items as stated, missing or requiring clarification.
Start With Project Inputs Before Reviewing BOQ Lines
A BOQ cannot be interpreted properly without its project context. Known inputs should be separated from supplier proposals, and unknown inputs should remain visibly unresolved rather than being filled with convenient assumptions. The following inputs help determine whether quotations are based on the same operating and application conditions.
Project inputs to establish before line-by-line BOQ comparison.
| Project Input | Why It Matters During BOQ Review |
|---|---|
| Country / city | Provides solar, environmental, code and logistics context. |
| Road width / area geometry | Defines the area and the basis for lighting review. |
| Pole height | Must align with layout, optics and structural scope. |
| Pole spacing | Affects layout assumptions and simulation where spacing is defined. |
| Working hours | Defines the required operating period. |
| Backup / autonomy requirement | States the required reserve basis without implying a guaranteed duration. |
| Dimming profile | Changes energy demand across the operating period. |
| Target lighting condition | Provides review criteria where the project specifies them. |
| Climate / environment | May affect configuration and protection requirements. |
| Available drawings / specifications | Identifies authoritative inputs, revisions and unresolved gaps. |
Two dependencies are especially important. The operating profile influences energy demand, which in turn informs battery and solar-module consideration. Road geometry, mounting height and spacing influence the optical distribution and any photometric review. These relationships should be checked by qualified engineering personnel; this guide does not provide an automatic sizing formula.
Where inputs remain incomplete, use the lighting engineering support pathway to clarify the information needed for the next review stage.
Use a System-Based Solar Street Light BOQ Review Framework
A solar street light should be reviewed as an interconnected system. A change in operating hours or dimming can change energy demand; a change in road geometry can change the optical requirement; and a change in pole or civil responsibility can change the commercial scope even when the luminaire remains the same.
Luminaire and optics
Confirm the proposed luminaire configuration and the application-specific fields stated by the project, such as rated power, CCT, mounting interface and relevant protection requirements. Optical distribution, aiming, tilt and mounting assumptions should be clear where they affect the lighting review. A generic product family name plus wattage is usually not enough for configuration-level comparison.
Solar module, battery and controller
Review solar-module rated power and project assumptions alongside battery chemistry, capacity, system voltage, architecture and autonomy basis. The controller review may include operating hours, dimming periods, control strategy, protection and remote-control requirements where applicable. None of these fields should be converted into a universal sizing rule or performance guarantee.
Operating profile and structural scope
The operating profile connects the load requirement with the energy-storage and solar-generation basis. Pole height, material, sections, arms, flange, anchor bolts, surface treatment and design-wind requirement should be identified where the specification calls for them. Civil, wiring and installation responsibilities should also be stated rather than assumed.
Use the solar street light system configurations page for product-family context and the lighting pole configuration page for deeper pole scope. This guide keeps both topics at BOQ-review level.
Why Wattage and Unit Price Are Not Enough
Nominal lamp wattage describes only one part of the system. It does not by itself establish battery reserve, solar-module basis, operating profile, optical distribution, structural scope, installation responsibility or document support. Headline lumen output and unit price are also insufficient when the underlying assumptions differ.
Compare like with like: Normalise the project assumptions, product configuration, operating profile, pole and civil scope, supporting documents, inspection requirements, exclusions and warranty boundary before deciding that two prices represent equivalent offers.
For example, two proposals may show the same luminaire wattage while using different dimming schedules or backup requirements. They may also use different optical distributions, pole inclusions or foundation responsibilities. The commercial difference should be interpreted together with those technical and scope differences.
This is a neutral comparison exercise. It does not assume that a lower or higher price is inherently right or wrong; it asks whether the quoted scope responds to the same project basis.
How BOQ Requirements Trace to Technical Evidence
Document traceability means that a material BOQ requirement can be connected to the corresponding proposed configuration and the evidence needed for the current review stage. The useful review logic is:
- BOQ requirement - identify the stated requirement, scope or assumption.
- Confirmed product configuration - record the candidate or confirmed configuration that responds to it.
- Matched datasheet - use the relevant configuration and revision when a datasheet is required.
- Optical file where applicable - match the IES/LDT file to the selected luminaire and optical configuration when photometric review requires it.
- Photometric simulation where required - confirm that project geometry, target criteria and selected optical data are consistent with the review inputs.
- Stage-appropriate drawing or reference - identify the product, pole, foundation or wiring information required at that stage.
- Inspection or acceptance evidence where contractually required - identify the records, criteria and approval responsibility stated by the contract or project process.
Applicability boundary: This is review logic, not a mandatory chain for every BOQ line. A battery line does not need an optical file, and an early quotation may not include project-specific drawings or simulation. Evidence should be requested where it is relevant to the requirement and project stage.
Photometric files and simulation
An IES/LDT file requirement becomes relevant when a consultant, tender or simulation review needs model- and optic-specific photometric data. The actual file should correspond to the selected configuration and revision. It should not be assumed to be a public download or to exist for every preliminary option.
A DIALux simulation may be required when road geometry, target illuminance, uniformity or consultant review must be checked. Project-specific simulation remains a controlled engineering output based on confirmed inputs; it is not automatically included with every quotation.
Datasheets, drawings and revision control
A generic datasheet does not validate every proposed configuration. Where datasheets and drawings are required, the document title, configuration reference and revision should make the relationship clear. Generic filenames or outdated revisions may weaken traceability and should be reconciled before the document is treated as supporting evidence.
BOQ Review Table: Areas, Risks and Supporting Evidence
Use the table below as a review framework, adapting each row to the project and tender stage. It does not set final technical values or universal pass/fail thresholds.
Core solar street light BOQ review framework.
| BOQ Area | What to Confirm | Why It Matters | Common Risk | Typical Supporting Evidence |
|---|---|---|---|---|
| Luminaire | Configuration reference, rated power, CCT, mounting and stated protection requirements. | Wattage alone does not identify the complete luminaire configuration. | A generic description hides configuration differences. | Configuration-matched datasheet or schedule, where required. |
| Optics | Distribution designation, aiming, tilt and mounting assumptions where applicable. | Optics affect road coverage and photometric review. | A generic beam label or unmatched file may misstate the proposal. | Optic reference and matched IES/LDT file when required. |
| Solar Panel | Rated power, type, project solar basis and installation constraints. | Solar input must be considered with the operating profile. | Different quotations may use different solar assumptions. | Configuration sheet and confirmed project inputs. |
| Battery | Chemistry, capacity, voltage, architecture and autonomy basis. | Battery assumptions affect the operating profile and backup requirement. | Offers may be based on different reserve conditions. | Configuration-matched datasheet or schedule after confirmation. |
| Controller | Operating hours, dimming/control strategy, protection and remote requirement if applicable. | Control settings affect energy demand and system function. | One offer may assume full output while another assumes dimming. | Control schedule or project specification where required. |
| Working Profile | Operating hours, dimming periods and backup/autonomy requirement. | The profile connects project operation to the system energy basis. | Missing profiles make energy assumptions difficult to compare. | Project Input Sheet or approved operating schedule. |
| Pole | Height, material, sections, arms, flange, anchors, surface treatment and wind requirement where specified. | Pole configuration affects mounting and structural scope. | A luminaire price may exclude the pole or assume a different pole design. | Pole schedule, drawing or stage-appropriate reference. |
| Foundation Scope | Included/excluded responsibility, site/soil inputs, anchor assumptions and final design owner. | Civil responsibility changes project scope and local review needs. | Unallocated civil work or assumed dimensions create scope gaps. | Civil-scope notes, site data and controlled reference where applicable. |
| Protection / Wiring | Cables, connectors, earthing, protection and accessories if included. | Electrical inclusions affect installation scope and comparability. | Offers may include different wiring or protection packages. | Scope schedule or wiring reference where required. |
| Engineering Documents | Required document category, stage, configuration match and revision. | Evidence must support the proposed configuration at the relevant stage. | Generic, outdated or absent documents may not support the BOQ. | Document list and revision-controlled technical files by stage. |
| Inspection / Acceptance | Criteria, records, responsibilities and contract stage where specified. | Inspection and handover scope can affect quotation and release requirements. | Offers may price different inspection or handover responsibilities. | Approved inspection or acceptance records when contractually required. |
Secondary CTA - Download BOQ Review Checklist: Use the public checklist as a compact working record alongside the BOQ and project specifications.
Common BOQ Gaps and Clarification Triggers
A structured review should distinguish information that is stated, information that is missing and information that requires technical or commercial review. Missing information is not automatically a failure, especially at an early stage, but it should not be silently converted into a supplier assumption.
A simple status model for BOQ gap review.
| Status | Use It When | Next Review Action |
|---|---|---|
| Stated | The requirement or scope is clear and its source/revision is known. | Check consistency with the proposed configuration and applicable evidence. |
| Missing | A relevant input, responsibility or document requirement is absent. | Record the gap and request the missing information from the appropriate owner. |
| Review | Information exists but is conflicting, conditional or technically unresolved. | Clarify the difference before treating the item as agreed scope or supporting evidence. |
Typical triggers include a wattage-only product line, conflicting road or operating assumptions, an unmatched datasheet or optical file, unclear pole/foundation responsibility, different wiring inclusions, and an alternative configuration that is not identified as such. Material geometry changes may also require review of the affected BOQ lines and engineering references.
Configuration difference: If a proposed configuration differs materially from the BOQ or specification, identify the difference and request clarification rather than presenting it as a silent substitution. The detailed method and status taxonomy for a technical deviation sheet belong to a separate controlled process.
When the gaps require a project-specific commercial or document discussion, use the canonical Tender Documents & BOQ support pathway.
Which Documents Are Public, Request-Based or Engineering-Controlled?
Technical documents should be controlled according to their purpose, configuration sensitivity and project stage. The categories below describe a practical access model; they do not promise that a particular file will be available for every product or project.
Document access levels for procurement planning.
| Access Level | Typical Purpose | Typical Content Boundary |
|---|---|---|
| Public | Early education and project preparation. | Generic guides, checklists and input templates, such as the public BOQ review checklist. |
| Request-based | Selected reference material after basic project information and intended use are understood. | Availability and suitability depend on the requested scope and document stage. |
| Engineering-review-only | Model-, configuration- or project-specific technical review. | Matched datasheets, actual IES/LDT files, project simulation, project-specific drawings or contractual records where applicable. |
The Resource Hub owns public preparation materials. Project-specific document requests should follow the Tender Documents & BOQ or relevant engineering pathway after the scope and required stage are understood.
Document availability: Available documents depend on confirmed project scope, product configuration, tender requirements and document stage. A reference drawing should not be treated as a final construction drawing unless the responsible project process confirms that status.
What BOQ Review Does - and Does Not - Decide
A BOQ review can identify missing inputs, inconsistent assumptions, unclear responsibilities and documents that need to be matched. It can also help a buyer normalise quotations before a deeper technical or commercial decision.
It does not select the final configuration without project engineering. It does not replace the employer's specification, contract conditions, consultant review, local structural design, authority approval or final acceptance. It also does not establish that every requested document is available at the current stage.
Pole and foundation boundary
The BOQ should state whether pole and civil scope are included, what site information is available, how anchor-bolt assumptions are handled and who owns the final design. It should not publish universal foundation dimensions or treat a generic reference as final construction approval.
Use the specialist foundation inputs and responsibility guide for deeper context. Final foundation design remains subject to project conditions and the responsible local or project engineer.
Scope limitation: BOQ review supports procurement clarity and evidence mapping. It does not guarantee lighting performance, tender compliance, consultant approval, contract acceptance or project outcome.
Frequently Asked Questions
What should a solar street light BOQ include?
A useful BOQ should identify the project and document revision, the relevant system configuration, the operating profile, pole/civil/electrical responsibilities and the documents required at the current stage. Luminaire, solar module, battery, controller, working profile and structural scope should be separated clearly enough for comparison. The exact fields are application-specific, so the review should mark each item as stated, missing or requiring review rather than applying one universal mandatory list. Confirm which fields govern the specific tender or quotation stage.
Is lamp wattage enough to compare solar street light quotations?
No. Lamp wattage does not establish equivalent battery reserve, solar-module basis, dimming profile, optical distribution, pole scope, civil responsibility or document support. Unit price and headline lumen output can also be misleading when the underlying assumptions differ. Compare quotations against the same project inputs, system scope, exclusions and evidence requirements before deciding whether the offers are technically and commercially comparable. A normalised comparison should make any remaining difference in scope visible to the buyer.
Should battery capacity and solar panel power be specified separately?
They should be identifiable where the project and procurement stage require configuration-level comparison. Battery chemistry, capacity, system voltage and autonomy basis should be read together with solar-module rated power, project solar conditions, operating hours and dimming. Separate values improve transparency, but they do not create a universal sizing rule or guarantee a particular battery life or number of backup nights. Engineering review is still needed to confirm that the combined assumptions suit the project.
How should working hours and backup days appear in the BOQ?
State the required operating hours, any dimming periods and the backup or autonomy requirement together with the project conditions on which they are based. These are requirements and assumptions, not automatic performance promises. If the profile is unknown, record it as missing or under review because different suppliers may otherwise price different energy bases while presenting similar headline configurations. Keep the requirement distinct from the supplier's proposed control schedule before pricing.
When should an IES file or DIALux report be requested?
Request a matched IES/LDT file when the selected luminaire and optic need model-specific photometric review. Request DIALux or equivalent simulation when project geometry, target illuminance, uniformity or consultant review must be checked. Neither item is automatically required for every quotation. Actual files and project simulations depend on confirmed configuration, inputs, scope and document stage. The BOQ should identify the review need without implying automatic file release for that stage.
Should pole and foundation requirements be included in the BOQ?
The BOQ should make the pole and civil responsibilities clear where they form part of the project scope. Relevant fields may include pole height, material, sections, arms, flange, anchor bolts, surface treatment, design-wind requirement, foundation inclusion and final design responsibility. The BOQ should not prescribe universal foundation dimensions or treat a reference drawing as final construction approval. Site and soil information should remain visible where it affects responsibility and approval.
What should happen when a supplier proposes a different configuration?
Identify the difference, explain which BOQ requirement it affects and request clarification before treating the alternative as agreed scope. Supporting documents should correspond to the proposed configuration where applicable. A material difference should not be hidden through a generic description or silent substitution. The formal deviation status and approval workflow belong to the tender's controlled review process. Record the affected requirement so the buyer can compare the alternative transparently before approval.
Which documents should be matched before final approval?
Match the documents that are relevant to the requirement and approval stage. This may include a configuration-specific datasheet, an optical file where photometric review is required, a simulation based on confirmed inputs, and stage-appropriate drawings or inspection records. The exact list is project- and contract-specific. BOQ mapping supports traceability, but final approval remains with the authorised technical, contractual and local review parties. Revision and configuration references should remain consistent across the matched set.
Primary CTA - Submit BOQ for Preliminary Review: If the review identifies project-specific gaps, use the Tender Documents & BOQ pathway to share the available BOQ and project information. The applicable review scope and document pathway depend on confirmed project requirements.
Secondary CTA - Download BOQ Review Checklist: Use the public checklist for an initial stated/missing/review assessment before requesting project-specific clarification.
