Most tender delays are not caused by price. They are caused by non-auditable documentation.
If a BOQ line cannot be traced to the exact model code + optics (Type II/III/IV) + IES/LDT file + DIALux/Relux evidence, reviewers will raise clarifications—or treat the submission as non-compliant.
This guide shows a reviewer-proof BOQ mapping method for solar street lighting—including a practical template and a pass/fail checklist.
Written by: Engineering Support Team (Street Lighting Tender Deliverables)
Based on: tender submittal reviews, BOQ clarifications, and DIALux/Relux submission packs
Last updated: 2026-02-04
Explore tender-ready deliverables: Engineering Support Hub
BOQ resources: Tender Documents & BOQ
✅ Need a tender-ready pack in 24H? Request Engineering Pack (24H) →
Quick Answer (60 seconds)
An auditable BOQ is a traceable chain:
one BOQ line → one model code → one optic → one IES/LDT file → one DIALux/Relux reference → matching geometry/drawings.
To make BOQ mapping auditable, every BOQ line must answer:
1) What exact model code is quoted? (not “80W solar light”, but a stable, traceable code)
2) Which optic distribution is used? (Type II / III / IV + aiming/tilt notes if applicable)
3) Which IES/LDT file proves it? (filename must match the model + optic)
4) Which DIALux/Relux report page proves targets? (Avg/Min/Uniformity + maintained assumptions)
5) Which drawing/layout matches installation? (pole height, spacing, arm length, arrangement)
If your BOQ cannot answer these, it is not a BOQ—it is a shopping list.
Photometry evidence: IES/LDT Photometric Files
✅ Request Engineering Pack (24H): Submit BOQ / drawings →
Need the full tender submission pack checklist (BOQ + IES + attachments)?
→ Solar Street Lighting Tender Pack Checklist →
Why BOQ Mapping Is a Tender Audit Item (Not an Admin Task)
Tender reviewers evaluate consistency across:
- BOQ line items (models, quantities, specs)
- photometric evidence (IES/LDT)
- simulation outputs (DIALux/Relux)
- drawings / installation assumptions
- compliance documents (test reports, certificates, QA notes)
When these don’t match, the reviewer’s conclusion is simple:
“We cannot audit this submission.”
That triggers:
- clarification requests
- redesign loops
- resubmission delays
- rejection risk
Real reviewer behavior (PDF audit)
Reviewers often search the PDF pack to confirm BOQ model codes appear in photometry files and simulation reports.[/caption]
Reviewers often use Search inside the tender PDF pack to verify whether the BOQ model code appears in photometry files and reports.
If the model code cannot be found (or the IES filename doesn’t match), the audit can fail instantly.
What “Auditable BOQ Mapping” Means (Definition)
An auditable BOQ mapping is a table that connects:
BOQ Item → System Type → Model Code → Qty → Pole height/spacing → Optic type → IES/LDT filename → DIALux/Relux report reference → Notes
So a third party (consultant, engineer, procurement officer) can reproduce the design and confirm compliance.
The Audit Trail Flow (How reviewers validate your pack)
Place this diagram near your BOQ template so reviewers understand your logic instantly.
A traceable chain reduces clarifications and rejection risk.[/caption]
BOQ Mapping Template (Copy This Structure)
Example template (demo only). Each BOQ line is traceable to IES/LDT and DIALux/Relux references.[/caption]
Use this structure in Excel (and export as PDF for submission):
| Item No. | System Type | Model Code | Qty | Pole Height / Spacing | Optic Type | IES/LDT File Ref. | DIALux/Relux Report Ref. | Notes |
|---|---|---|---|---|---|---|---|---|
| 1 | Solar Street Light | SSL-XXX-80W-T3 | 200 | 9m / 45m | Type III | SSL-XXX-80W-T3.ies | Report-A p.6 | 0° tilt; maintained assumptions stated |
| 2 | Solar Street Light | SSL-XXX-60W-T2 | 120 | 8m / 38m | Type II | SSL-XXX-60W-T2.ies | Report-A p.7 | narrow road segment |
| 3 | Pole & Bracket | PL-9M-EN40 | 320 | 9m | — | — | — | hot-dip galvanized |
| 4 | High Mast (optional) | HM-20M-8x400 | 4 | 20m | — | HM-OPTIC.ies | Report-HM p.3 | apron area |
File naming rule (non-negotiable)
Your IES/LDT filenames must include:
- model code
- optic type (T2/T3/T4)
- wattage / lumen package
- CCT (optional but recommended)
If the file name is generic (e.g., “streetlight.ies”), reviewers will question traceability.
Photometry evidence: IES/LDT Photometric Files
Want this template in Excel?
✅ Request the BOQ Mapping Template & Engineering Pack (24H) →
The 5 Mapping Rules Reviewers Expect
Rule 1 — One BOQ line = one searchable model code
Avoid vague text like:
- “Solar street light 80W”
- “All-in-one solar street light”
Use a stable model code, and keep the same code in:
- BOQ
- datasheet
- IES/LDT file name
- packing list (handover)
- test report index (where applicable)
Rule 2 — Optics must be explicit (Type II/III/IV + aiming/tilt)
Minimum acceptable:
- optic distribution type (Type II/III/IV)
- tilt assumption (0° unless tender allows otherwise)
- mounting height/arm notes (if relevant)
Rule 3 — Every optic must link to the exact IES/LDT file
Example:
- BOQ: SSL-XXX-80W-T3
- IES file: SSL-XXX-80W-T3.ies
- DIALux/Relux: references the same filename
Get model-matched photometry: IES/LDT Photometric Files
Rule 4 — Every IES/LDT must link to a DIALux/Relux reference
You must show where targets are proven:
- average
- minimum
- uniformity
- layout geometry (height/spacing/arrangement)
Simulation evidence: DIALux Simulation Outputs
Rule 5 — BOQ must match drawings and installation assumptions
Most rejections come from geometry mismatch:
- BOQ says 9m pole, report uses 8m
- BOQ says 45m spacing, report uses 35m
- aiming/tilt not stated, but report uses a different setup
If assumptions differ, the design evidence is invalid.
A Reviewer-Friendly Submission Pack Structure (What to Submit)
/01-BOQ-Mapping/
- BOQ-mapping.xlsx
- BOQ-mapping.pdf
/02-Photometry-IES-LDT/
- model-coded IES/LDT files
- photometry index (1 page)
/03-DIALux-Relux/
- report.pdf
- option comparison pages (Type II vs III if needed)
/04-Datasheets/
- datasheets by model code
- pole drawings (height, flange, brackets if requested)
/05-Compliance & QA/
- key certificates/test reports index
- manufacturing & QC overview (for trust)
Quality authority: Manufacturing & Quality
Reference evidence: Projects
✅ Need the full pack in 24H? Request Engineering Pack (24H) →
Reviewer-Proof Checklist (Pass/Fail)
1) BOQ model codes are stable and consistent across documents
2) Each street light line includes optic type (Type II/III/IV) + aiming/tilt assumption
3) Every BOQ street light line links to an IES/LDT file (matching filename)
4) DIALux/Relux report references the same IES/LDT filenames
5) Report geometry matches BOQ (pole height/spacing/arm/arrangement)
6) Targets (Avg/Min/Uniformity) are shown clearly (maintained, not day-one only)
7) Maintained assumptions are stated (MF or maintained notes)
8) Packing list/labels can mirror model codes for acceptance traceability
If any item fails, it becomes a clarification point.
Common BOQ Mapping Failure Reasons (And Fixes)
Failure A — Generic BOQ line
Symptom: BOQ uses marketing words; no model code.
Fix: enforce model codes and keep them identical across files.
Failure B — IES mismatch
Symptom: IES filename/photometry doesn’t match the quoted model/optic.
Fix: filename rule + mapping table + one-page photometry index.
Failure C — Report cannot be reproduced
Symptom: report doesn’t show IES filename / geometry assumptions; reviewer cannot re-check.
Fix: add a one-page “Reviewer Notes” summary: IES filename + height + spacing + aiming + maintained assumptions.
Failure D — Geometry conflicts
Symptom: BOQ spacing differs from report spacing.
Fix: lock geometry inputs; if drawings change, revise the whole chain (BOQ ↔ IES ↔ DIALux).
Failure E — Acceptance handover breaks
Symptom: packing list/labels do not match BOQ model codes.
Fix: align packing list structure with the same model code system.
Fastest Way to Make Your BOQ Auditable (If You’re Under Deadline)
If you are short on time, you don’t need perfection—you need a clean audit trail.
Send any of the following:
- BOQ (even draft)
- road width + pole height/spacing assumptions
- drawings or site plan (PDF/image)
- target criteria (if tender specifies)
We will return a tender-ready pack:
- BOQ mapping table
- IES/LDT files (matched to optic types)
- DIALux/Relux report with clear file references
- a one-page reviewer notes summary
✅ Request Engineering Pack (24H) → /engineering-support/#request-now
Related Engineering Support Resources
- Engineering Support Hub
- Tender Documents & BOQ
- IES Photometric Files
- DIALux Simulation Outputs
- Manufacturing & Quality
- Projects
FAQ
Do I need BOQ mapping if I already have a DIALux report?
Yes. The report proves lighting performance, but BOQ mapping proves what exactly was simulated, and how it ties to procurement and acceptance.
What if the tender BOQ format is fixed?
Keep the tender BOQ format, but attach a separate BOQ mapping annex (audit table). Reviewers love this because it reduces clarifications.
Can one IES file be used across multiple models?
Only if photometry is verified for that exact configuration. In tenders, assume one model/optic = one file reference unless evidence proves otherwise.
CTA (End)
If your tender is urgent, send BOQ + drawings (or just road width + pole height range) and we can start immediately.
