How to choose LCC software: 7 criteria for LCA-integrated costing

LCC software is the tool that calculates and reports life cycle costing (LCC) by placing every cost a product or building incurs across its life cycle into modules and discounting it. The right choice delivers three things a spreadsheet cannot: costs held in the same structure as the environmental LCA, transparent discounting assumptions, and a result that can be defended in front of a verifier or a tender committee. This article sets out seven evaluation criteria for teams building a cost analysis integrated with LCA, and the technical reasoning behind each. The criteria are derived from the requirements of ISO 15686-5 and EN 16627, not from marketing feature lists.

Most teams start LCC in a spreadsheet, and for evaluating one alternative once that is enough. The trouble arrives with scale. Thirty cost items, three alternatives and a fifty-year analysis period produce a file where discount factors are spread by hand across hundreds of cells and replacement years are tracked by eye rather than by formula. Changing one service life cascades through the replacement schedule and the residual value; in a spreadsheet that chain breaks and nobody notices. The more fundamental problem is traceability: a verifier cannot ask which cell came from which quotation, because the sheet does not record it. The criteria below target exactly these breaking points.

1. Module mapping: cost and environment on the same denominator

The first criterion is that every cost item can be assigned to an EN 15804 module. EN 16627 inherits the module structure of EN 15804 (A1-A3, A4-A5, B1-B7, C1-C4, D) one-to-one for economic assessment, so the software should hold costs by module rather than in two coarse buckets labelled ‘investment’ and ‘operation’. When the same life cycle stage lands on the same row on both the environmental and the economic axis, the two tables read side by side and derived indicators such as carbon abatement cost (€/t CO₂e) become meaningful. In a tool without module mapping, LCC and LCA remain two separate studies and the merging is done by hand, every time. A second axis, cost nature (capital, operating, end of life, revenue), should be held separately: management wants that breakdown, the standard wants the module one.

2. The real/nominal distinction and discount transparency

The second criterion is that the discounting logic is stated openly: does the software work in real or nominal terms, and under which timing rule is the discount applied? The real approach strips inflation from cash flows and uses a real discount rate; the nominal approach requires an inflation forecast. ISO 15686-5 defines both routes but forbids mixing them. In a high-inflation environment the real approach is preferred because it removes one source of uncertainty from the model. Software that hides this decision leaves the reader interpreting a number without knowing the assumption behind it. Whether discounting is applied at year end or mid-year should also appear in the report; over long analysis periods the difference reaches a few per cent and can change the ranking of two alternatives.

3. Deriving cost items from the inventory

The third criterion is that cost items can be derived from the LCA inventory. A product's environmental model already contains every material, energy and transport flow with its quantity; the only thing missing for LCC is a unit price. If the software can convert inventory lines into cost items, quantities come from one source and the two models never drift apart. If it cannot, the same quantities are entered twice and six months later nobody knows which copy is current. A good derivation mechanism does not silently synchronise: it flags items with no price and lines whose quantity has changed as warnings, never overwrites a manually edited value, and does not mistake inter-phase product transfers (one stage's output becoming the next stage's input) for purchases and count them twice.

4. Currency and price date

The fourth criterion is that prices are stored together with their currency and date. A roofing membrane may be priced in euros on a 2024 quotation while installation labour comes in lira on a 2026 contract. A real-terms engine needs both values brought to the same base year and the same currency; that conversion must either be done explicitly or not at all. Software that surfaces a currency mismatch as a warning is safer than software that produces a total on a hidden exchange-rate assumption. Displaying exchange rates for reference and feeding them into the engine automatically are different things; the latter injects a currency forecast into the model as an undocumented assumption, and it becomes the first question at verification.

5. Replacement schedule and residual value automation

The fifth criterion is that the number of replacements and the residual value are derived automatically from service life. If the analysis period T exceeds the component's service life SL, the number of replacements is N = ceil(T/SL) − 1; for a 20-year component over a 50-year period, two replacements are scheduled in years 20 and 40. Any life remaining at the end of the period is converted to a residual value by linear depreciation and discounted as an end-of-period credit. Built by hand, these two mechanisms are where models break most often: the service life is updated, the replacement years are not. If the software does not derive them, long-lived alternatives are systematically penalised because the value of their remaining life never enters the calculation.

6. Report separation: costs that never leak into the EPD

The sixth criterion is that cost data stays physically separate from the EPD document. ISO 14025 requires Type III environmental declarations to carry environmental information only; an EPD containing prices or costs is returned by the verifier. Software that keeps both LCA and LCC in one project has to demonstrate that not a single cost line leaks into the EPD output. The cleanest architecture makes LCC a separate report fed by the same model: the same declared unit, the same module breakdown, a separate document. This separation is not only a compliance rule but a commercial safeguard; price is negotiable and should not be frozen into a document that stays valid for five years.

7. Audit trail and verifiability

The seventh criterion is that the path from result back to input can be followed. The source of every cost item (quotation, contract, invoice, estimate), its price date, unit and module assignment must be on record, and the discount rate and analysis period the calculation ran with must appear in the report. Marking a result ‘out of date’ when the inventory changes prevents an old result being presented alongside a new quotation. LCC is requested more and more often in public tenders and green finance applications, and the first question from whoever reads those documents is not the total but where the total came from. A tool that cannot answer that question item by item does not make the result defensible, however fast it calculates.

• Can every cost item be assigned to an EN 15804 module and a cost nature (capital, operating, end of life, revenue)?
• Are the real/nominal choice and the discount timing stated explicitly in the report?
• Can the LCA inventory be converted into cost items, with warnings for missing prices and quantity drift?
• Are currency and price date stored per item, with a mismatch warning?
• Are the number of replacements and the residual value derived automatically from service life?
• Is the LCC report generated separately from the EPD PDF?
• Can every result be traced back to the version of its inputs?