How to write an LCA report: ISO 14044 reporting requirements

An LCA report is the document that records a study's goal, scope, data, method and results clearly enough for a reader who did not perform the study to reach the same result. The reporting clause of ISO 14044 defines this as presenting ‘the results, data, methods, assumptions and limitations transparently and in sufficient detail’; the test is whether the reader can understand the complexity and the trade-offs of the study. In practice a good report satisfies three people at once: the manager who will take the decision, the critical review panel that will examine the model, and the engineer who will update the study five years later. This article sets out the mandatory content under ISO 14044, the requirements added by report type, and a section template that works.

Reader first: internal use, third party, comparative assertion

ISO 14044 sets its reporting requirements in three tiers, and the tier depends on who the report will go to. For a study used only inside the organisation the general requirements apply: results and conclusions presented consistently with the goal and scope, with transparency about data and methods. If the report goes to a third party (a customer, a programme operator, a public authority) the standard asks for an additional list: functional unit and reference flow, justification of the system boundary, cut-off criteria, data quality requirements and assessment, allocation rules, the LCIA method and the source of its characterisation factors, limitations. If a comparative assertion is to be disclosed to the public (‘our product emits half the carbon of the competing product’), the third tier applies: critical review is mandatory, the review is performed by a panel, and the report includes the panel's statement, its comments and the responses to them.

Mandatory content: from goal and scope to limitations

The report mirrors the study's four phases in the same order. The goal section states plainly why the study was done, which decision it will inform, the intended audience and whether it contains a comparative assertion; those four sentences justify every later choice. The scope section gives the functional unit and reference flow, the system boundary (which modules are included, which excluded and why), the cut-off rules, the allocation approach, the LCIA method and impact categories selected, the data quality requirements and the temporal, geographical and technological representativeness. The inventory section covers the data collection procedure, primary and secondary data sources, the background database with its version, the calculation procedures and the data quality assessment. The impact assessment section gives characterised results by category; where normalisation or weighting has been applied it states that these are optional and cannot support a comparative assertion. The interpretation section covers significant issues, the completeness, sensitivity and consistency checks, conclusions, limitations and recommendations.

A recommended section template

The order below covers the mandatory items of ISO 14044 and follows the layout verifiers and programme operators are used to. Renaming the sections is fine; dropping their content is not.

• Executive summary: the question, the functional unit, the headline result, the largest contribution, the most important limitation (one page)
• Goal: why, which decision, who will read it, whether there is a comparative assertion, commissioner and practitioner
• Scope: product system, functional unit and reference flow, system boundary and flow diagram, cut-off rules, allocation, LCIA method, data quality requirements
• Life cycle inventory: data collection, primary data tables, secondary data and database version, calculation, data quality assessment (pedigree matrix)
• Impact assessment: result tables by category and by module, source of the characterisation factors
• Interpretation: significant issues (contribution analysis), completeness, sensitivity and consistency checks, uncertainty
• Conclusions, limitations and recommendations
• Critical review: panel statement, comments and responses (where required)
• Annexes: full inventory, data sources, allocation rationale, scenario parameters

Tables and figures: which visual proves what

Every figure in an LCA report exists to prove a claim. The system boundary diagram shows at a glance which processes are inside and confirms the scope text. The inventory table lists every input and output per functional unit with quantity, unit, data source and data quality score; it is the table a verifier spends longest on. The module-based result table (A1 through D in EN 15804 studies) distributes impact categories across modules. The contribution analysis chart shows which process or flow carries what share of the total and visualises the ‘significant issues’ step of the interpretation. A tornado chart is used for sensitivity results and a Monte Carlo distribution (P10, P50, P90) for uncertainty. In comparative studies a single figure should show whether the uncertainty ranges of the two alternatives overlap; if they do, a claim of ‘significant difference’ cannot be made.

Annexes for the critical review

Under ISO 14044, critical review checks that the methods are consistent with the standard and scientifically and technically valid, that the data are appropriate and reasonable for the goal, that the interpretation reflects the limitations, and that the report is transparent and consistent. The annexes that make the panel's work easier are the documents that do not fit the report body but support every claim: the complete inventory list, the database name, version and activity identifier for every secondary dataset, the rationale behind allocation decisions, the source of scenario parameters (transport distance, recycling rate, service life), and the full results of the sensitivity runs. Once the review is complete, the panel's statement, its comments and the practitioner's response to each comment are added to the report; the standard treats that dialogue itself as part of the report.

What is most often missing

The same omissions recur in reports that verifiers and review panels send back. There is a system boundary diagram, but no explanation of why the excluded processes were excluded. The background database is named, but not its version and system model (cut-off, APOS, consequential); the same activity can shift by tens of per cent between two versions. Data quality is described as ‘good’ without a pedigree matrix score. The interpretation section repeats the results but does not document the completeness, sensitivity and consistency checks separately. Comparative studies do not demonstrate that the two alternatives share the same functional unit, boundary and data quality. And almost always: the limitations section is one sentence long.