Product Carbon Footprint Software: How to Get From Nine Assessed Products to Fourteen Hundred

Why product footprints stall at nine products

An automotive customer's supplier portal now has a field for cradle to gate kilograms of carbon dioxide equivalent per part number. Your account manager forwards it. There are 1,400 part numbers on that customer's list. Your sustainability specialist has completed nine full assessments in eighteen months, each one a careful study in a modelling tool, each one taking two to four weeks because it required chasing engineering for a bill of materials, chasing purchasing for supplier data, and making a hundred small judgement calls about which background dataset represents your aluminium extrusion.

The maths does not work and everyone in the room knows it. So the company does what companies do: it produces a number for the flagship product, extrapolates for the rest with a mass based proxy, and hopes nobody audits it. That is fine until a customer's own assurance provider asks how the figure for part 4471 was derived, and the honest answer is that it was scaled from part 4470 by weight.

What has actually happened is a category error. The company treated product footprinting as a study, which is what LCA has always been, when the customer is asking for a data product. A study is a document with a specialist's name on it. A data product is a number that regenerates when the bill of materials changes, carries its own provenance, and can be produced for anything in the catalogue on request. Those are different engineering problems, and only one of them scales.

Problem 1: the specialist is the bottleneck and the work is the wrong shape for them

Your LCA specialist is expensive and genuinely skilled. Watch where the time actually goes. A small part goes into judgement: allocation choices, system boundary decisions, which background dataset best represents a specific alloy or a specific moulding process. The large part goes into clerical work: exporting a bill of materials, retyping part masses, hunting for the density of a polymer grade, matching a supplier's declared factor to the right component, and rebuilding the whole model when engineering changes a fastener.

Every hour spent on the clerical part is an hour not spent on the judgement, which is the part only they can do. Automation here is not about replacing the specialist. It is about moving them from one product a week to reviewing a hundred generated results a week and intervening where the model is uncertain. The design goal for the build is explicit: the machine assembles, the specialist adjudicates, and every adjudication is stored so the machine does not ask twice.

Problem 2: the bill of materials in PLM is not the bill of materials you ship

This is where automation attempts die. Engineering holds a design bill of materials in PLM with revisions, effectivity dates, phantom assemblies, and configurable variants. Manufacturing holds a different structure in ERP with routings, scrap factors, and alternate parts. Purchasing holds approved manufacturer lists where the same component may be bought from three suppliers in three countries with three different production footprints.

So the question which bill of materials do we footprint has no single answer, and any tool that requires you to answer it once has already failed. A product built in Poland from Chinese components has a different footprint from the same part number built in Mexico, and if you are subject to the EU carbon border adjustment mechanism or a customer contract with regional requirements, that distinction is the whole point.

What a custom build does that a modelling tool cannot: it treats the footprint as a function of part number plus plant plus effectivity date plus supplier selection. It reads the manufacturing structure with its routings and scrap factors, resolves the actual supplier for each purchased component from real purchase history rather than from the approved list, and can therefore produce a defensible answer to what did the units we shipped last quarter actually cost in emissions, which is the question a customer is really asking.

Problem 3: material to dataset mapping is the asset, and it is a judgement made once

Every automated footprint runs on the same underlying operation: take a material or process description from your engineering data and connect it to a background dataset with an emission factor. Your PLM says PA66 GF30 black, or aluminium 6082 T6 extruded, or a supplier part number and nothing else. The background database says something structured but different, in ecoinvent or a Sphera dataset or an industry average from a trade association.

That connection is a professional judgement with a rationale attached, and it is the single most valuable thing the project produces. Once your specialist has decided that PA66 GF30 from this supplier region maps to a specific dataset with a specific rationale, that decision should apply to every product in the catalogue containing it, forever, until someone deliberately revises it with a recorded reason.

What the build must include is that mapping as a first class, versioned, governed table with an owner, a rationale field, a confidence level, and full history. When you re run the catalogue after a database update, you want to see exactly which products moved and why. Language models help with the first pass here, proposing candidate matches for thousands of unmapped material strings and clustering the ones that are obviously the same thing written four ways by four engineers. They do not get to approve their own suggestions. Every mapping is confirmed by a named human, and the reason we insist on that is simple: the number goes to a customer with your company's name on it.

Problem 4: supplier specific data arrives as PDFs that do not match your part numbers

Primary data from suppliers is what moves a footprint from generic to credible, and what customers increasingly demand. The reality of collecting it is a survey emailed to 300 suppliers, of whom perhaps a third reply, in a mixture of spreadsheets in their own format, a PDF from a consultant, a certificate referencing a different product name, and an email saying we do not have that.

Matching those responses to your components is genuinely tedious work, and it is the second place automation earns its keep. Extraction reads the declared value, the reference product, the standard claimed, the reporting period, and the boundary, then proposes a match to your part numbers for human confirmation. Data quality is stored alongside the value, because a supplier specific figure verified to ISO 14067 and a spreadsheet cell someone typed are not the same evidence and your report must be able to say which is which.

Where SimaPro, Sphera, One Click LCA, Makersite and Ecochain actually stop

SimaPro is an excellent modelling environment and the standard tool for practitioners doing rigorous studies. That is exactly what it is for. It is a specialist workbench, not a pipeline that reads your PLM nightly and republishes 12,000 figures. Sphera brings deep datasets and enterprise sustainability breadth, with the corresponding implementation weight and licence commitment. One Click LCA is strong in construction and building products, where the standards and the data structures are specific to that sector, and less natural if you make discrete manufactured goods with deep configurable bills of materials.

Makersite and Ecochain are the closest in intent to what we are describing, and both are credible: Makersite in particular is built around connecting product data to impact and cost at scale. The gaps we consistently find are not about capability in the abstract. They are about your data. Whether the tool can read your specific PLM structure with your variant logic and your effectivity rules. Whether it can resolve supplier by actual purchase history rather than by approved list. Whether your material mapping decisions remain yours, exportable, and reusable if you change vendor. Whether a per plant, per period result is possible or only a per product average. And whether the commercial model survives your catalogue size, since per product pricing structures get uncomfortable somewhere north of a few thousand SKUs.

Our honest position: evaluate Makersite and Ecochain seriously before commissioning a build. If either reads your product data as it actually exists, buy it. The build case appears when your PLM and ERP structures are non standard enough that the connector becomes a custom project regardless, which for manufacturers with configurable products and post acquisition system sprawl is common.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering bill of material extraction, the governed mapping layer with machine assisted first pass matching, calculation with background dataset integration, and per product results with full audit trail runs $60,000 to $140,000 and ships in 10 to 16 weeks. A full platform adding supplier data collection with document extraction, scenario comparison for design engineers, customer facing exchange and portal output, and regulatory reporting support runs $160,000 to $400,000 phased over 6 to 12 months.

What drives cost up specifically here: configurable products, because a footprint per configuration rather than per part number multiplies the calculation surface. Multiple PLM or ERP systems from acquisitions. Background database licensing, which is a real third party cost you pay regardless of who builds the software and which you should confirm early. Cradle to grave scope, since use phase and end of life modelling introduce assumptions that need their own governance. And any need for third party verification, which raises the evidence bar on everything.

What keeps cost down: cradle to gate only for the first release, one product family, and accepting generic background data initially while the supplier collection process runs in parallel.

Build versus buy, and when buying is the right call

Do not build if your catalogue is small and stable, perhaps under 50 products with slow changing bills of materials. Commission proper studies in SimaPro, publish them, and revisit in three years. Do not build if your customer requests are occasional and satisfied by a handful of figures. Do not build if you are a building products manufacturer whose customers work in construction data formats, where One Click LCA fits the ecosystem your customers already use.

Build when two or more of these are true. Your catalogue runs to thousands of products with real variant complexity. Customers are asking for part level figures in their portals as a condition of doing business. Your engineering data lives in a PLM structure that no vendor connector reads without a custom project. You need per plant or per period results rather than one number per part. Design engineers want footprint feedback while they are choosing a material, which requires the calculation to be fast and embedded rather than a study commissioned after the fact.

How to choose a developer for product footprint software

Ask them how they will get the bill of materials, in detail, before discussing anything else. A developer who has done this will ask whether you use the design or manufacturing structure, how variants and effectivity are represented, whether scrap factors are in routings, and how they should resolve which supplier actually shipped the component. A developer who says they will import a spreadsheet has not understood that the spreadsheet is the problem you are paying to eliminate.

Ask what they will do with the mapping table. The correct answer is that it is your intellectual property, versioned, exportable, with rationale and approver on every row. If mapping is buried in code or in a vendor's cloud, you have rented your own judgement back from them.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else. At Digital Heroes the code is yours from the first commit. Background dataset licences remain with their publishers, and any developer who is vague about that distinction has not built one of these before.