IES/LDT Files Explained: What EPC Teams Should Request and How to Verify

IES/LDT files are plain-text “light distribution fingerprints” for a luminaire—used by lighting software to predict lux, uniformity, and sometimes glare risk. If you’re an EPC team pricing street lighting, industrial yards, schools, or commercial retrofits, these files are not “nice-to-have.” They’re how you reduce design risk, protect the savings model, and defend your audit trail when a client (or an engineer) asks, “Show me how you got these results.”

In Africa I’ve seen the same pattern repeat: a tender gets won on a beautiful lighting layout and aggressive kWh savings… then the site gets built and the ground reality says otherwise. The root cause is often boring: wrong photometry, wrong variant, wrong scaling, or an old file quietly reused across a product family. Garbage in, garbage out—and the “garbage” is usually hidden in a small text file nobody checked.

This article is not theory. You’ll get a practical request checklist you can paste into tenders, plus a step-by-step verification workflow with pass/fail checks and red flags. Treat it like a field SOP.

If you want the bigger end-to-end workflow (audit → modeling → procurement control → acceptance testing), start here: Sunlurio EPC Lighting Solutions.

What Are IES/LDT Files and Why EPC Teams Need Them?

IES and LDT files are text-based photometric data files that describe how a luminaire throws light in 3D, so design software can simulate illuminance, uniformity, and visual comfort—and so EPC teams can back procurement/compliance claims with testable inputs. When you’re responsible for the outcome (and the arguments later), you need the same “source of truth” the designer used.

In EPC work, photometry isn’t academic. It touches three things that decide whether your project is profitable or painful:

1. Savings model accuracy (risk reduction). Your baseline vs proposed energy model is built on fixture count and wattage. Fixture count is built on predicted lux/uniformity. Predicted lux is built on photometry plus assumptions. If photometry is inflated or mis-scaled, you under-design and your “guarantee” becomes a negotiation.
2. Design validity (technical defensibility). A client engineer, consultant, or procurement committee will challenge “Why this spacing?” or “Why this optic?” With IES/LDT you can show your working, not just a pretty PDF.
3. Audit defensibility (paper trail). When acceptance testing finds dark spots or glare complaints, your best friend is documentation: which file, which revision, which variant, which assumptions, and why you accepted it.

Also, IES/LDT files are where “silent changes” happen. A manufacturer might update optics, LED bins, or drivers and keep the marketing sheet looking the same. If you don’t control file versioning, you don’t control your model. That’s how disputes start.

And yes—this matters for solar street lights too. Even though PV sizing feels separate, the lighting spec (lux, uniformity, roadway class) still depends on photometry. If the light distribution is wrong, you’ll chase it later with higher wattage, longer runtime compromises, or extra poles. None of those are free.

If your team wants a repeatable EPC workflow (and not just “one project luck”), keep the master reference here: Sunlurio EPC Lighting Solutions.

What is the IES/LDT files definition and what do they contain?

IES/LDT files are standardized photometric text files that describe a luminaire’s 3D light distribution using candela values across vertical and horizontal angles, along with lamp lumens, geometry, photometric type, and metadata like test lab and dates. Lighting software converts those intensity values into predicted lux, uniformity, spacing guidance, and sometimes glare indicators—so errors inside the file directly distort designs and energy savings claims.

At the core is the 3D light distribution concept: the file lists luminous intensity (candela) measured at many angles. Think of it like slicing the light output into angular “rings” and “planes,” then recording how strong the light is in each direction. That’s why polar plots and isolux diagrams exist—they’re visual translations of the same numeric grid.

What’s typically inside (high level):

• Candela distribution over angles/planes (the real meat).
• Lumens information (luminaire or lamp lumens, depending on absolute/relative approach).
• Photometric type / measurement setup (how the luminaire was oriented and tested).
• Geometry (dimensions, luminous opening hints, sometimes rough shape data).
• Electrical inputs may be present or implied via metadata (but don’t trust it blindly).
• Metadata (manufacturer, catalog number, test standard reference, lab, dates, revision).

Then the software does the rest: it places the luminaire in a scene, applies mounting height and aiming, calculates contributions at grid points, and outputs lux levels, uniformity ratios, and spacing recommendations. Some tools also estimate discomfort glare metrics, but glare usually needs more context than photometry alone (we’ll get there).

Here’s the EPC trap: energy savings guarantees depend on fixture quantity and wattage decisions. If you feed a wrong file (wrong optic, wrong scaling, or “family reuse”), the model predicts higher lux than reality, you specify fewer fixtures, and the project becomes underlit. The client doesn’t care that the text file was wrong—they care that their yard is dark.

What are the IES vs LDT files differences EPC teams should know?

IES and LDT both carry photometric distributions, but they differ in regional prevalence, formatting conventions, metadata structure, and how easily mistakes slip in—so EPC teams should accept either when test traceability is clear, and request both when cross-checking or multi-region stakeholders are involved.

Here’s a compact EPC-style comparison you can drop into internal docs:

Item	IES (North America common)	LDT / EULUMDAT (Europe common)	EPC Practical Pitfalls
Format	Plain text, IESNA standard variants	Plain text, EULUMDAT structure	Re-exported “IES-like” files from software can look valid but aren’t raw test output
Region prevalence	Often requested by US/NA consultants and tools	Common in EU specs and many global manufacturers	Multi-country tenders may involve both reviewer expectations
Structure / metadata richness	Can include labels and metadata blocks; varies by version	Structured fields, often consistent metadata slots	Missing lab/test date is common in both—treat as a risk flag
Common pitfalls	Confusion around absolute vs relative; wrong lumens scaling	Wrong tilt/orientation assumptions; “family reuse”	Same fixture can model differently if data differs—flag for verification

When is either format acceptable?

• Accept IES or LDT if: it matches the exact variant, has traceable test info (lab/standard/date), and passes sanity checks.
• Request both if: the project is high-stakes (airports, highways, hospitals), multi-party review is expected, or you already see inconsistencies (cut sheet claims vs file numbers).

And a reality check I always tell junior engineers: You can model “the same fixture” two ways if the IES and LDT don’t match. That’s not a software problem—that’s a verification problem. If two files that supposedly represent the same optic/wattage produce noticeably different spacing or peak intensity, pause. Ask for clarification, test report linkage, and file revision control. Don’t “average” them and hope.

What EPC Teams Should Request in Tenders and Submittals?

If you want predictable lighting performance and defendable savings, your tender must request photometry like a controlled engineering input—not like a marketing attachment. Most EPC teams lose here because they ask for “IES files” casually, and suppliers respond with whatever is convenient: wrong optic, old revision, generic family file, or worst of all… a PDF screenshot of a polar plot. That’s not an input; that’s decoration.

Below is procurement-ready “request language” you can paste into RFPs and tender documents. Use it. It will annoy some bidders, yes. But it also filters out the ones who can’t support performance claims.

If you’re building this into a tender-ready system (templates + SOP + deliverables), anchor the process here: Sunlurio EPC Lighting Solutions.

What is an IES/LDT file request checklist for EPC projects?

Use this checklist to request IES/LDT photometric files that are traceable to the exact product configuration being bid, including variant identifiers, test report linkage, geometry and mounting assumptions, and absolute/relative photometry clarity—so your model and savings guarantee don’t rest on guesswork.

Tender / RFP request language (copy-paste friendly):

• Photometric file requirement: Provide IES and/or LDT photometric file(s) for the exact catalog configuration bid, including optic/distribution, CCT, CRI, and drive current (or power setting). No generic “series” photometry unless variant mapping is provided.
• Variant traceability: Provide the spec sheet and a unique product identifier (catalog number / SKU) that maps explicitly to the photometric file name(s).
• Test report summary: Provide a summary including test laboratory name, test standard reference, test date, and file version/revision. If the lab report number exists, include it.
• Geometry and mounting assumptions: Provide luminaire dimensions, luminous opening orientation, and any tilt/aiming assumptions used in the photometric measurement. Confirm intended installation orientation for the project (e.g., pole-mounted area light, flood, roadway).
• Absolute vs relative confirmation: Confirm whether photometry is absolute or relative and state how lumens should be handled in simulation (scaling required or not).
• High-value optional (recommended): Provide luminaire maintenance assumptions separately (LLF components should be project-defined; do not bake maintenance into photometry without declaring it).

A small note from the field: Ask for drive current / power setting explicitly. Some LED luminaires have multiple driver options or programmable power. If the photometry was tested at one setting and you bid another, you just created a silent performance gap.

• Tender/RFP Photometry Request Language Pack (Word + TXT)
• Variant Mapping Table Template (Excel)

What should EPC teams do about IES/LDT files for “family” products and variants?

Manufacturers often reuse one photometric file across multiple wattages or optics inside a product family; EPC teams should accept reuse only when scaling rules are clearly documented and traceable, and reject silent reuse that hides performance differences across variants.

This “family reuse” is probably the #1 tender trap I see. The supplier says, “Same housing, same LED board,” and then they attach one IES file for everything: 60W, 80W, 100W, wide optic, medium optic… all the same file name, same test date. That is not automatically fraud—sometimes the optic truly is identical and only wattage changes. But silent reuse is unacceptable, because optics and power levels change intensity distribution, not just total lumens.

What’s acceptable:

• The supplier provides one base photometry file and documents a scaling rule tied to tested lumens or power settings.
• They provide a variant mapping table that clearly shows which variants share photometry and why.
• They provide a test report reference that supports the base photometry and states the tested configuration.

What’s not acceptable:

• One file used across multiple optics/wattages with no explanation.
• A “new” model number but same photometry and no revision note.
• The cut sheet claims multiple distributions, but the photometry plot looks identical.

Variant mapping table EPC teams should require (recommended minimum):

Model / Catalog No.	Optic / Distribution	Wattage / Power Setting	CCT / CRI	IES/LDT Filename	Test Date	Notes (Scaling / Shared File Justification)
(supplier fills)	(supplier fills)	(supplier fills)	(supplier fills)	(supplier fills)	(supplier fills)	(supplier fills)

If a bidder refuses this table, that’s already information. In my experience, it means either they don’t control their photometry library… or they don’t want you to look too closely.

What are IES/LDT files submission requirements to reduce risk?

Set clear accept/reject submission rules: enforce naming conventions, ban “PDF-only photometry,” require raw test-output photometry (not re-exported from design tools), and demand revision control—so the file you model is the file you can defend.

Here are requirements that reduce downstream disputes dramatically:

• File naming convention (mandatory):
  Format example: [ProjectCode][FixtureCode][Optic][Wattage][CCT]_[Rev].
  Example: KGLA-LOT1_AreaLight_Wide_120W_4000K_R02.ies
• No PDFs-only rule:
  Photometry must be provided as editable text files (IES and/or LDT). Polar plots in PDFs are welcome as supporting docs, not replacements.
• Raw photometry requirement:
  Provide raw photometric files generated from laboratory test output, not files re-exported from lighting design software. (Re-export can round values, strip metadata, or change tilt conventions. Happens more than people admit.)
• Revision control:
  Any change to optics, LED package, driver, lens, or mechanical geometry that affects output must trigger a new file revision and a change note.
• Submission completeness:
  Photometry + spec sheet + test summary + variant mapping (if applicable) + assumption sheet for mounting orientation.

Accept/reject criteria can be blunt:

• Accept if files are traceable, variant-correct, pass sanity checks, and revisions are controlled.
• Reject / resubmit if metadata is missing, variant mapping is unclear, photometry type is ambiguous, or files appear reused silently.
  

  How to Verify IES/LDT Files Before Modeling and Award?

Verification is where EPC teams create real value: you’re not just buying luminaires, you’re buying predicted performance—and predicted performance is only as good as the photometry you accept. I like to treat verification in two phases: (1) quick triage (minutes), (2) deeper checks (an hour) for shortlisted bidders or high-risk areas.

Below is a workflow you can repeat. It’s not fancy, but it catches most problems before they become change orders.

If you want to roll this into an internal QA gate (procurement + design + commissioning), keep the hub here: Sunlurio EPC Lighting Solutions.

What quick sanity checks should EPC teams run on IES/LDT files?

Sanity checks are fast pass/fail steps: open the file, confirm identifiers, validate lumens and wattage reasonableness, check symmetry and angle grids, and confirm units/orientation—so you don’t model the wrong variant or a mis-scaled file.

Steps list (triage SOP):

1. Open the file in a plain text editor (yes, like a human). Confirm it’s not corrupted or stripped.
2. Confirm identifiers: manufacturer name, catalog number, optic/distribution label, CCT/CRI/power setting (if present). If missing, treat as a risk.
3. Check lumens/wattage reasonableness: compare file lumens (or lamp lumens fields) to cut sheet claims. If the gap is large with no explanation, flag it.
4. Check geometry values: dimensions should not be zero, negative, or absurdly tiny/huge for the claimed output. A “0 x 0” luminaire with 20,000 lm is… come on.
5. Check symmetry expectation: if the luminaire is marketed as symmetric (area light Type V / wide), photometry should look symmetric. If it’s asymmetric (roadway Type II/III), symmetry should not magically appear.
6. Check angle grids: ensure vertical angles cover expected range (often 0–180) and the step counts look realistic. Strange grids can indicate an export artifact.
7. Check units and orientation assumptions: confirm photometric type and “tilt/orientation” conventions match how the luminaire will actually be installed (downlight vs flood vs area).

A practical tolerance tip: Cut sheets are rounded and optimistic sometimes. But the file and the claims shouldn’t be living on different planets. If the file implies a very different lumen package than the cut sheet, pause and ask for the lab report summary.

• IES/LDT Sanity Check Checklist (Excel/PDF)
• Pass/Fail Red Flag Triage Sheet (Excel)

How should EPC teams verify absolute vs relative photometry in IES/LDT files?

Absolute photometry means the candela values are tied to the tested luminaire’s total lumens, while relative photometry means candela values are normalized and must be scaled by lamp lumens or multipliers—so EPC teams must detect which type they have to avoid double-scaling (inflated lux) or no-scaling (deflated lux).

Let’s keep it simple with an example that bites EPC savings models:

• Suppose a file is relative and represents a “per 1,000 lm” normalized distribution (or similar convention).
• Your designer imports it and also manually sets luminaire lumens from the cut sheet.
• If the software already scales using the lumens field and you also apply a multiplier, you get double-scaling. Suddenly the layout looks amazing: fewer fixtures, higher uniformity, big savings. Then site commissioning happens… and reality is 30–40% lower.

The reverse happens too: treating an absolute file as relative and scaling it down, resulting in over-design (too many fixtures), higher CAPEX, lower savings competitiveness.

Decision rule box (use this in your team):

Decision Rule: Absolute vs Relative

• If the file indicates luminaire lumens that match a tested product output and notes/fields suggest “absolute photometry,” then do not apply external lumen scaling (use the file as-is; apply LLF separately as maintained illuminance).
• If the file indicates lamp lumens / normalized values or the vendor explicitly states “relative photometry,” then apply the correct lumen scaling exactly once using the documented lumens and multipliers—then lock that assumption in your model notes.

If you’re unsure (and sometimes you will be), don’t guess. Ask for a one-line written confirmation from the supplier: “This file is absolute/relative; in simulation, set luminaire lumens to X and apply no additional scaling / apply scaling once.” That email becomes part of your defensibility file. It sounds small, but it saves fights.

Recommended Deliverables and Templates EPC Teams Can Standardize

Standard templates reduce mistakes, speed up reviews, and make your process repeatable across countries, teams, and contractors. When you standardize deliverables, you stop reinventing verification every project—and you make it harder for weak bidders to slip through.

Below are reusable artifacts your team can adopt. If you do nothing else, implement the one-page checklist and the submittal package structure.

What should an IES/LDT file review checklist include?

A useful IES/LDT review checklist is a one-page, pass/fail template with notes columns that covers file identity, revision control, photometry type, lumen/watt consistency, distribution sanity, import test outcomes, and risk actions—so reviewers can verify quickly and leave an audit trail.

1-page verification checklist (template suggestion):

Section	Pass/Fail	Notes
File identity & traceability (manufacturer, catalog/SKU, optic, wattage, CCT, filename matches)
Revision control (test date, lab, version/revision present)
Photometry type (absolute/relative confirmed; scaling decision documented)
Lumens/watts consistency (cut sheet vs file; efficacy check)
Distribution sanity (symmetry, beam shape, application fit)
Geometry plausibility (dimensions reasonable; orientation/tilt assumptions)
Import test results (polar plot reviewed; reference scene sanity check)
Risks & actions (missing data, requests sent, hold points)

If you want it stronger, add a “Hold Award Until Closed” checkbox. Because some issues are not “nice to resolve later.” They’re structural.

• 1-page IES/LDT Verification Checklist (Excel/Google Sheet + PDF)
• Photometry Review SOP (1-page printable PDF)

If you want to position these templates as part of a wider service (not just freebies), point readers back here: Sunlurio EPC Lighting Solutions.

Conclusion: A Simple Verification Workflow EPC Teams Can Repeat

If you want a repeatable EPC process, use a short SOP that moves from request discipline to file control and documented assumptions—because the goal isn’t just a good design, it’s a defensible outcome. Over time, this becomes part of your bid advantage: you reduce rework, reduce disputes, and your models stop being fragile.

Here’s the 6–8 step recap I’d put on a wall in the office (or at least in the tender folder):

1. Request photometry properly in the tender: exact variant, traceability, test summary, absolute/relative confirmation, and “no PDFs-only.”
2. Identify the files: confirm catalog number, optic, wattage/power setting, CCT/CRI, and filename conventions. Build the variant mapping table if it’s a family product.
3. Sanity check in text: metadata present, lumens/watts plausible, geometry not nonsense, angle grids reasonable, symmetry expectations aligned.
4. Confirm absolute vs relative and document scaling rules. Apply scaling once if needed—never twice, never zero.
5. Import test in your simulation tool: review polar plot/isolux, verify peak direction, run a quick reference scene at typical height/spacing.
6. Consistency check against cut sheet claims: lumens/watts/efficacy reconcile, distribution matches application label, unusual asymmetry explained.
7. Spec match to project requirements: maintained lux targets, uniformity, mounting/tilt assumptions, LLF approach documented separately.
8. Document + file-control: store the exact file revision used, link it to the submittal package, and keep a clean audit trail for acceptance testing and client queries.

If you implement only one habit from this article: treat photometry like a controlled engineering input, not a brochure attachment. That one shift reduces risk more than most people expect—especially when margins are tight and clients are skeptical.

If you want the full repeatable “audit-to-acceptance” structure behind this workflow, go from here: Sunlurio EPC Lighting Solutions.