LCA for Product Variants and Versions: A Practical Guide

Configurable products create a data-control problem: which information belongs to the shared product platform, which belongs to a variant, and which must remain attached to a historical revision? A workable LCA structure answers those questions before calculation begins.

TL;DR

Build one controlled base assembly, then branch only the components, processes, suppliers, packaging, or use assumptions that differ. Keep released versions separate from prospective scenarios, record the methodology and dataset versions used for every result, and never assume that internal variant modelling automatically permits one external declaration.

Define the objects before building the model

Teams often use variant, version, and scenario interchangeably. That makes comparisons difficult and can cause an earlier result to be overwritten by a proposed design. Use explicit working definitions:

Object	Working definition	How to use it in LCA
Product family	Related products sharing a substantial base design or manufacturing system	Organise reusable components and processes without assuming one shared external declaration
Variant	A distinct configuration offered or produced	Represent the inventory differences from the shared base assembly
Version	A controlled revision that was or is actually produced	Preserve its BOM, effective date, evidence, methods, and released result
Scenario	A prospective change that has not replaced the controlled product version	Compare possible materials, suppliers, routes, or designs without rewriting history
Representative product	A selected configuration used to represent a defined group under an applicable approach	Document why it is representative and test relevant variation
Average product	A model intended to represent a stated product mix	Record the products, period, data, and weighting included in the average

The distinction between versions and scenarios is especially important. A released version records what existed. A scenario asks what might happen. If a scenario is approved for production, create a new controlled version rather than silently changing the old model.

The LCA Capability Roadmap identifies incomplete descriptions of model structure, proxy data, allocation, assumptions, observations, and interoperability as limitations on model interpretation and reuse.

Start with a shared assembly, then branch deliberately

Create a base assembly containing genuinely common parts and processes. Variants should reference that shared structure and add or replace only the inventory that changes. This avoids duplicating identical data while keeping differences visible.

A distinct BOM representation is normally useful when a change affects environmental inventory or interpretation, including:

• material type or recycled content;
• component mass or quantity;
• supplier or production geography;
• manufacturing route or energy input;
• transport distance or mode;
• packaging;
• expected use profile;
• end-of-life assumptions.

A naming correction that changes none of the inventory may remain a metadata correction. By contrast, a new size may require a variant even when its component list is unchanged, because quantities, packaging, production inputs, or use assumptions can differ. Do not invent a universal percentage threshold for this decision. The significance of a change depends on the product, method, reporting purpose, and applicable rules.

Create controlled versions instead of overwriting results

Each released result should point to an identifiable product configuration. At minimum, retain the product identifier, BOM revision, effective date, calculation date, methodology, database version, supplier evidence, assumptions, review notes, and status.

Makersite documents a BOM workflow that supports adding a newer BOM version, synchronising updated component data, recalculating upstream emissions when supplier product-carbon-footprint data changes, and recording a change comment for the version through its BOM version workflow.

Shared components need dependency control. When a supplier updates the footprint for a component used in several assemblies, identify every referencing product. Review those products rather than updating only the assembly that triggered the request. The resulting calculations should become new or recalculated records with clear status; historical released results should remain recoverable.

Lock the methodology alongside the BOM

A BOM version alone cannot reproduce an LCA. Record the functional unit, system boundary, allocation approach, cutoffs, impact-assessment method, background database and version, electricity assumptions, transport, end-of-life treatment, and data period.

This matters because result changes do not always come from product redesign. In one industrial modular-LCA case study, monthly results varied by ±14% around the yearly result, while changes to background datasets, LCIA methods, and environmental-label rules altered results by 20%. Its dashboards handled more than 10^5 LCA values. These are case-specific findings, not general uncertainty or error margins, as shown in the industrial modular-LCA study.

For a fair variant comparison, hold the methodology constant while changing the inventory. If the database or method must change, calculate and label that as a separate methodological update. Otherwise, a team may attribute a difference to a component when it actually came from a new dataset or characterisation method.

Compare changed components and life-cycle stages

Do not stop at the total kg CO2e or total impact result. Compare:

1. the changed component or process;
2. the affected life-cycle stage;
3. the supplier or background dataset used;
4. the difference from the controlled baseline;
5. any secondary effects, such as altered transport or packaging.

This makes the result actionable. A lower-impact material may be offset by greater mass, a different manufacturing route, or longer transport. Stage-level and component-level comparisons expose that trade-off; a single total does not.

Use the following decision pattern to keep records consistent:

Event	Recommended treatment
Proposed material or supplier change	Scenario linked to the current controlled version
Approved production revision	New BOM version with an effective date
Correction to an input error	Corrected result with the reason recorded; preserve the earlier record
New supplier footprint data	Review every assembly referencing the supplied component
Annual production-data update	New calculation period attached to the applicable configuration
New size or configuration	Variant when inventory or assumptions differ
Naming-only change	Metadata correction when inventory and interpretation are unchanged

Keep internal modelling separate from declaration grouping

A product family can share an internal model without qualifying for one EPD or other external declaration. The International EPD System separates programme-level instructions from product-category requirements in the applicable PCR, and existing PCRs and declarations remain associated with the rule versions used during development or verification until updated through the programme’s procedures. The reporting approach must therefore follow the relevant programme instructions and PCR requirements.

In one discussed EPD Hub case, One Click LCA community guidance recommends selecting a representative product, modelling minimum and maximum cases, and assessing variation using A1–A3 GWP-fossil. That is case-specific variant guidance, not a universal grouping rule or materiality threshold.

Treat internal portfolio modelling and external reporting as separate decisions. Internally, a modular model can support many configurations. Externally, the applicable PCR, programme rules, and human verifier determine whether and how those configurations may be represented together.

Maintain the model through scheduled and event-driven reviews

Run a scheduled review when annual supplier, production, energy, transport, or sales-mix data becomes available. Trigger an event-driven review when a part, supplier, site, process, packaging specification, use assumption, method, dataset, PCR, or reporting rule changes.

Dawn supports assembly variants and version control and lets manufacturers manage reusable product and supplier data in the same system as BOM-based LCA studies. Excel/CSV part imports, assemblies, variants, versions, suppliers, and living product and LCA data can be maintained together. Product carbon results can be read from the applicable LCA study, while EPD-style tables remain outputs for human review and external verification rather than certified declarations issued in the app.

Sources

• Makersite BOM creation and version workflow
• Industrial modular-LCA study
• LCA Capability Roadmap
• International EPD System general programme instructions
• One Click LCA community guidance on modelling product variants