LCA Technology common mistakes
LCA Technology · Understand the traps and how to avoid them.
Treating the functional unit as a description of the product (e.g., "1 kg of aluminium") instead of defining the quantified performance the system delivers (e.g., "contain and protect 1,000 L of beverage over 90 days at a specified leakage rate"), then comparing systems that do not deliver equivalent functions.
Candidates carry over a physical unit or a reference flow from a familiar dataset and never separate the function, functional unit, reference flow, and reference product, so the comparison is structurally invalid before any data work begins.
What to do instead
Before modeling, write four explicit lines: function, functional unit (quantity + duration/quality criteria), reference flow in the chosen flow type, and the alternative systems' reference flows. Check that every alternative fulfills the same function statement; if it does not, redefine the functional unit or declare the comparison as non-equivalent.
Choosing allocation by habit (usually mass) without documenting the allocation hierarchy, and mixing allocation approaches across the foreground and background so that burdens are counted twice or not at all.
Allocation is the most conceptually difficult part of the framework, and candidates default to the simplest physical parameter they can compute quickly rather than following the ISO 14044 hierarchy (avoid, then physical relationships, then other relationships).
What to do instead
State in the goal and scope why allocation cannot be avoided, apply the hierarchy in order, and justify the chosen parameter with a physical or economic rationale. Apply one consistent approach to all co-products of a process, disclose it in the report, and run a sensitivity case with an alternative allocation to show the effect on results.
Mixing foreground and background data without recording provenance, so that a specific supplier dataset, a generic industry average, and a proxy from another region are blended in one model with no way to tell which flow came from where.
Candidates focus on getting a complete model and treat data selection as a search task; they pick the first dataset that matches the flow name and move on, ignoring geography, technology, and time representativeness.
What to do instead
Maintain a data provenance table with one row per dataset: source database and version, geography, reference year, technology level, unit, and whether it is foreground measured, foreground calculated, or background. Flag every proxy explicitly, and record the reason for substitution so reviewers can judge fitness for purpose.
Reporting a single impact number without any uncertainty information, or presenting a pedigree-matrix score as if it were a quantified confidence interval.
Candidates conflate data quality indicators with statistical uncertainty and assume that once a dataset is rated "good" on completeness and temporal correlation, the resulting result needs no further analysis.
What to do instead
Separate the two concepts in the report: qualitative data quality ratings (pedigree) and quantitative uncertainty (distribution, standard deviation, or interval). Propagate uncertainty with Monte Carlo or analytic methods, report the resulting interval or distribution, and state which flows dominate the spread.
Using midpoint and endpoint results interchangeably, or summing endpoint damage categories into a single score without disclosing the weighting and value choices behind it.
Endpoint indicators look more decision-ready, so candidates present them as the headline result while forgetting that they embed additional modeling and normative weighting beyond the characterization factors.
What to do instead
Report midpoint results as the primary, more certain level; present endpoint results as complementary and clearly labeled. Name the LCIA method and version, list the included impact categories, and state explicitly which weighting set or normalization reference was applied if a single score is shown.
Selecting an LCIA method because it is the software default or the most familiar name, without checking whether its impact categories, characterization factors, and geographical coverage match the study's goal and scope.
Candidates learn one method name and apply it universally, not realizing that methods differ in category coverage, time horizon, spatial differentiation, and whether they include toxicity or resource depletion at all.
What to do instead
Match method to goal: list the impact categories the goal requires, then confirm the candidate method covers them with factors valid for the relevant region and time horizon. Document the selection rationale, note excluded categories and why, and run a second method as a sensitivity check when the decision is sensitive to method choice.
Building the model without parameters and scenarios, then producing alternative results by manually editing flows and saving copies, so that versions diverge and no one can reproduce which change produced which result.
Candidates treat the software as a drawing tool and underestimate how quickly manual edits make a model unauditable, especially when scenarios differ only in a few quantities.
What to do instead
Parameterize the quantities that vary (transport distance, energy mix share, yield), define scenarios as named parameter sets rather than duplicated models, and keep one model file under version control with a change log. Verify reproducibility by re-running each scenario from the saved parameter set and comparing outputs.
Exporting or importing a model between tools and assuming the transfer is lossless, without checking that units, flow properties, UUIDs, and method mappings survived the conversion.
Candidates trust the exchange format and the import dialog; in practice unit groups, elementary flow categorization, and impact method assignments are the usual casualties of a format conversion.
What to do instead
After every exchange, run a reconciliation: compare product system totals, flow counts, and a sample of characterization results before and after. Check that each flow has a valid flow property and unit group, that elementary flows map to the target method's factors, and record the format and version used (ecoSpold, ILCD, JSON-LD) in the report.
Performing a contribution analysis by listing the largest flows by mass or cost rather than by impact contribution, and stopping there without any sensitivity or scenario analysis.
Candidates equate "biggest inventory flow" with "most important environmental hotspot" and treat interpretation as a summary section rather than an analytical step with required elements.
What to do instead
Rank contributions on the impact result, per impact category, using the characterized results; then test the key assumptions (allocation, dataset choice, transport, end-of-life) with sensitivity runs and document how much the conclusion moves. State conclusions, limitations, and recommendations separately, as ISO 14044 interpretation requires.
Describing a critical review as "internal" or "external" without specifying the review type, the reviewer's independence, the documents provided, or how comments were resolved, and claiming the study is "ISO compliant" without evidence.
Candidates memorize that reviews exist but not the distinction between internal expert review, review by interested parties, and panel review, nor what documentation a reviewer must receive.
What to do instead
State the review type chosen and why it matches the study's intended use and disclosure level, list the documents and data supplied to reviewers, summarize material comments and how each was addressed, and avoid asserting compliance; instead report which requirements were met and where the evidence is documented.
Treating an EPD or product carbon footprint as a generic LCA and omitting the program-operator rules: required PCR/Product Category Rules, declared unit versus functional unit, mandatory impact categories, and module boundaries (cradle-to-gate versus cradle-to-grave).
Candidates learn the general framework first and assume a published EPD is just a shortened LCA, missing that program rules override methodological choices and that the declared unit is not the same as a functional unit.
What to do instead
Identify the applicable program operator and PCR version before scoping, follow its declared unit, module structure, and required indicators, and verify the dataset and LCIA method conform to the PCR. For product carbon footprints, confirm which standard and system boundary apply and report the result with that boundary stated.