How lighting distributors manage photometric product data
Lighting distributors store manufacturer IES files as SKU assets, then extract lumens, CCT, CRI, efficacy and DLC status into filterable fields per variant.
Lighting distributors typically manage photometric data in two layers: they store the manufacturer's IES file (an ANSI/IES LM-63 text file, or increasingly a TM-33 XML/JSON file) as a downloadable asset on each SKU, and they separately extract the numbers buyers filter on (lumens, wattage, efficacy, CCT, CRI, beam angle, dimming type, DLC status) into structured attribute fields in the ERP or PIM. The file serves the lighting designer running a layout; the extracted attributes serve the contractor searching the site, and the work is keeping the two in agreement for every variant.
The gap most distributors live with is that the file exists but the attributes do not. A high bay page links a good .ies download while the Lumens and CCT facets on the category page are blank, because nobody pulled the values out of the file, the spec sheet, and the DLC listing into columns.
What an IES LM-63 file holds, and what it leaves out
An LM-63 file is plain ASCII. Wikipedia's format list records editions from 1986 through 2019 and 2025, and notes the format carries luminous intensity distribution data.
Per the AGi32 Photometric Toolbox documentation of the LM-63 format, the file opens with optional keyword lines such as [TEST], [TESTLAB], [ISSUEDATE] and [MANUFAC], then a data block with number of lamps, lumens per lamp, a candela multiplier, vertical and horizontal angles, photometric type, ballast factor, input watts, and the candela grid itself. The same page notes some manufacturers do not use the keyword scheme at all.
For a distributor, that means an IES file reliably gives you:
- Total luminaire lumens (from the lumen and multiplier fields, depending on whether the file uses absolute or relative photometry)
- Input watts, so you can compute efficacy as lumens divided by watts
- A candela distribution from which beam angle and BUG rating can be calculated
It does not give you CCT, CRI, dimming protocol, voltage, mounting, or listing status in any dependable field. Those live on the spec sheet, the order-code matrix, and the DLC record. If your enrichment plan assumes "parse the IES file and we're done," you will fill three or four columns and leave most of the filters buyers actually use empty.
Where TM-33 fits in lighting product data for distributors
The newer format is ANSI/IES TM-33-23. The IES store listing describes it as an XML-based format for transferring luminaire optical data, includes a JSON document format, and lists LM-63-19 among its normative references. Wikipedia's list notes TM-33 supports spectral power distribution data alongside luminous intensity, which is what makes it interesting for product data: a TM-33 file can carry color information that LM-63 cannot.
Suppliers may send either format, so ingestion should accept both. Store whichever files the manufacturer publishes, record the format in an asset attribute (photometric_file_format: LM-63-2002, LM-63-2019, TM-33-23), and treat extraction from TM-33 as a bonus source for CCT, not an assumption.
Getting IES files into the ERP and PIM as attributes
The ERP usually holds the order code, a short description, a price, and sometimes wattage. The PIM, if there is one, holds the attribute schema and the asset links. Neither does the extraction. That work pulls from four places:
| Attribute | Best source | Fallback |
|---|---|---|
lumens_delivered | IES file data block | Spec sheet table |
input_watts | IES file data block | Spec sheet, ERP |
efficacy_lm_per_w | Computed from the two above | DLC listing |
cct_k | Order-code matrix on spec sheet | TM-33 file, DLC listing |
cri | Spec sheet | DLC listing |
beam_angle_deg | Computed from candela grid | Spec sheet |
dimming_type | Spec sheet driver options | Installation guide |
dlc_status | DLC QPL record | Spec sheet badge |
Tools exist for the file side. Lighting Analysts' Photometric Power Tools batch-validates and edits large sets of IES files and cleans up inconsistent keywords and filenames. Its Instabase search engine indexes over half a million photometric files from more than 500 manufacturers and lets designers filter by luminaire lumens, BUG rating, CCT and CRI. Designers already filter photometric data by those fields; your PDP should let a contractor do the same.
For the attribute model behind those fields, our lighting attributes guide lists the core set by fixture type.
DLC, ENERGY STAR and NEMA dimming: listing data that moves
Listings are the attributes most likely to go stale.
DLC. The DesignLights Consortium finalized SSL V6.0 on November 3, 2025. Per the DLC transition page, V5.1-qualified products must be updated by October 9, 2026 or face delisting on December 15, 2026, and V6.0 introduces a controls category from 0 to 6, with category 0 ineligible for Premium. A dlc_status field that says only "Yes" is about to be wrong for some share of your catalog. Store dlc_version, dlc_tier (Standard or Premium), dlc_product_id, and a dlc_checked_date, and confirm against the live QPL.
ENERGY STAR. The ENERGY STAR light fixtures page says the program ended for most common fixtures, with recessed downlights still able to earn the label. A fixture badge copied from a five-year-old spec sheet is a liability; re-verify before you publish it as a filter.
NEMA dimming. NEMA SSL 7A sets compatibility requirements when a forward phase-cut dimmer is combined with dimmable LED light engines, per Lighting Controls Academy's summary of the 2015 revision; the standard was originally developed by the NEMA Lighting Controls Committee. For the PDP, that suggests a dimming_type enum (0-10V, Phase-cut forward, Phase-cut reverse, DALI, Non-dimming) plus a boolean nema_ssl_7a_compatible populated only when the manufacturer states it. Do not infer it from "dimmable."
Keeping variants straight
This is where photometric data breaks. One fixture family can ship in multiple lumen packages, CCTs, optics, and drivers. Some manufacturers publish one IES file per lumen package and optic rather than per CCT, so a 4000K and a 5000K variant may share a file and differ only on the spec sheet.
The rule that holds up: model the IES file as an asset that can attach to many SKUs, and model CCT, CRI and driver at the SKU. Never copy a lumen value from one variant's file onto a sibling without checking the order-code matrix. DLC's own SSL V5.1 requirements call out separate handling for color-tunable products and dimmable products, a reminder that "same family" does not mean "same performance."
A worked example
For illustration: a distributor carries a high bay family with three lumen packages (15L, 20L, 24L), two CCTs (40K, 50K), two optics (wide, narrow), and two drivers (0-10V, non-dimming). That is 3 x 2 x 2 x 2 = 24 orderable SKUs. The manufacturer publishes six IES files (three lumen packages times two optics).
The extraction pass reads six files for lumens, watts and candela, computes efficacy and beam angle six times, then fans those values to 24 SKUs by matching lumen package and optic. CCT and dimming come from parsing each order code against the spec sheet's ordering matrix. DLC status gets looked up per product ID, because a manufacturer may list only some packages. If the 50K variants have lower measured lumens in the spec table than the shared file, the file value is wrong for them and should be flagged rather than published. At 24 SKUs this is an afternoon; across tens of thousands of lighting SKUs it is a standing workload.
What goes wrong
- Nominal versus delivered lumens. Spec sheets mix lamp lumens and delivered lumens. Store
lumens_deliveredand label its source. - Stale files. A manufacturer re-tests and reissues; your stored file is the old one. Check
[ISSUEDATE]where present. - Free-text dimming. "Dimmable" in a description is not a filter. Normalize to the enum.
Deciding who does the work
Your PIM or ERP is the right place to store all of this. The question is who reads 30,000 spec sheets and keeps DLC status current through the V6.0 transition. Teams usually choose between in-house category managers, an offshore data-entry vendor working through a template, or an enrichment layer. Anglera is the last kind: it extracts values from the source documents, quality-scores each one, and flags conflicts like the shared-IES-file case above for review instead of guessing. It works alongside whatever PIM or ERP you run, typically goes live in about 30 days from a flat export, and keeps the attributes maintained as files and listings change.
If you're scoping a lighting catalog, the lighting distributors page shows the attribute set we fill, and Schema Foundry covers how a new field like dlc_version gets defined and backfilled across a catalog. Start with one family, check the variants against the files, and you'll see quickly where your gaps sit.