Product Carbon Footprint Data Exchange: ISO 14067, PACT and BOM Roll-Ups

Most companies can report a corporate carbon footprint, yet almost none can say what one specific part number emitted before it arrived at the dock. That gap is the real obstacle behind Scope 3 reporting: purchased goods and services typically dominate a manufacturer’s inventory, and the numbers are usually spend-based estimates rather than measurements. Product carbon footprint data exchange is the machinery that closes the gap, by letting a supplier’s calculated footprint travel, with its methodology and data quality attached, to the customer whose bill of materials (BOM) consumes it.

This matters now because regulation is turning footprints into compliance data. Batteries, the Digital Product Passport under the EU Ecodesign for Sustainable Products Regulation, and customer procurement rules all ask for product-level numbers that someone can defend. A spreadsheet emailed once a year will not survive that scrutiny.

You will leave with a working mental model of three layers: the calculation standard (ISO 14067 and its relatives), the exchange protocol (the PACT technical specifications and the Pathfinder Network), and the engineering that sits in your PLM system (BOM roll-up, allocation, versioning, and passport output). There is runnable code and a worked, clearly illustrative example.

What this covers: how a PCF is defined and calculated, what the PACT data model carries, how the API exchange works, how to roll supplier PCFs up through a multi-level BOM, what goes wrong in practice, and how it connects to the Digital Product Passport.

Context and Background

A product carbon footprint (PCF) is the sum of greenhouse gas emissions and removals attributed to one unit of a product across a defined part of its life cycle, expressed in kilograms of CO2 equivalent (kgCO2e). The GWP weighting that converts methane or nitrous oxide into CO2e comes from the Intergovernmental Panel on Climate Change (IPCC) assessment reports; the PACT data model, for example, carries an explicit field recording which IPCC characterization factors were used (such as AR6). Two people computing a footprint for the same item with different GWP vintages will not get the same answer, which is the first hint that “a number” needs “a context” to be useful.

The standards stack

Three families of documents govern how the number is produced.

ISO 14067:2018 is the international standard for the carbon footprint of products. According to the ISO catalogue entry, it sets principles, requirements and guidelines for quantifying and reporting a product’s carbon footprint, is consistent with the life cycle assessment standards ISO 14040 and ISO 14044, and also covers a partial carbon footprint. It addresses climate change only, and it explicitly excludes carbon offsetting, communication of the footprint, and social, economic or other environmental impacts. The catalogue lists it as reviewed and confirmed in 2024, with a revision flagged as planned, so treat the 2018 edition as current while watching for a successor.

The GHG Protocol Product Life Cycle Accounting and Reporting Standard is the corporate-reporting-oriented sibling, widely used as the product-level companion to the Scope 3 standard. The two documents overlap heavily on life-cycle stages, allocation hierarchy and data quality, and differ mostly in reporting rules and in how certain choices such as biogenic carbon are treated. In practice, a calculation can claim conformance to either or both, and the PACT data model has a field for recording which cross-sectoral standards were used.

The PACT Methodology (formerly the Pathfinder Framework) is the third layer, and the one most relevant to exchange. It was created by the WBCSD-hosted Partnership for Carbon Transparency to narrow the interpretation choices that ISO 14067 and the GHG Protocol leave open, so that two companies following it produce comparable numbers. The published specification describes it as building on existing standards such as the GHG Protocol Product standard. Version 3.0 of the methodology adds properties for biogenic emissions and removals, including land-use-related items.

Why exchange, not estimation

Spend-based and average-data factors are fast, but they are blunt. A spend-based factor assigns the same emissions to two aluminium housings with identical price, even when one was cast with hydropower and the other with coal-fired grid electricity. Supplier-specific primary data is the only way to reflect a supplier’s decarbonisation work, which is exactly the signal a procurement team wants to reward.

The difficulty is not computing a footprint; it is moving thousands of them, between companies running different software, in a way that preserves meaning. Without a shared schema, each customer sends a questionnaire in its own format, each supplier answers it in a different spreadsheet, and the data is untraceable by the time it reaches the PLM system. The PACT technical specifications exist to replace that with a typed object and a REST interface. For the automotive-specific variant of the same problem, see our analysis of the Catena-X automotive data space reference architecture, which carries PCFs as one of its use cases.

For authoritative background, the PACT technical specifications are published openly, and the ISO 14067 catalogue entry gives the scope statement quoted above.

Reference Architecture: Calculation, Exchange, Consumption

The most useful way to think about a PCF programme is as three decoupled layers connected by one object. Calculation produces a footprint; exchange moves it; consumption folds it into your own product’s footprint and, eventually, into a passport. Separating them prevents the most common architectural mistake, which is to bolt carbon fields onto the BOM table and call it done.

Direct answer. A product carbon footprint data exchange architecture has three layers: a calculation layer applying ISO 14067 or the GHG Protocol product standard, an exchange layer using the PACT ProductFootprint data model over an OAuth-secured REST API, and a consumption layer that rolls supplier footprints up through the BOM. The ProductFootprint object is the contract between the layers.

Figure 1: Three-layer reference architecture for product carbon footprint data exchange, from calculation through the PACT exchange layer to BOM consumption in PLM.

The diagram shows a supplier-side calculation engine feeding a conformant PACT solution, which serves footprints to a customer-side solution. The customer ingests them into a PCF store linked to the PLM BOM, where a roll-up engine produces the customer’s own footprint and publishes it onward. The same pattern repeats at every tier of the supply chain, which is what makes the model scale: each company only needs to talk to its direct counterparties.

Layer one: calculation

The calculation layer is where life cycle inventory data meets emission factors. A supplier collects primary activity data (electricity per unit, process fuel, scrap rate, inbound freight), selects secondary emission factors for what it cannot measure, applies allocation where a process serves several products, and computes the cradle-to-gate total. Cradle-to-gate means from raw material extraction up to the factory gate; it is the boundary that makes supplier footprints additive in a customer’s BOM, because the customer then adds its own manufacturing, packaging and outbound steps.

Primary data means measured or supplier-specific values for the process in question. Secondary data means generic values from databases such as ecoinvent or national inventories. The PACT data model records the secondary sources by name and version (its documentation uses the example of ecoinvent 3.9.1) so a reader can tell later whether two numbers used the same background data.

Layer two: exchange

The exchange layer is deliberately thin. The PACT developer documentation describes a conformant solution as exposing an HTTP REST API: an authentication action, a list action, a get action, and an optional events action. Events use CloudEvents in structured content mode. A company does not have to build this; most adopt a solution provider that is PACT conformant, and the Pathfinder Network is the term for the ecosystem of interoperable providers, which lets two companies on different vendors exchange data without a bilateral integration project.

Layer three: consumption

Consumption is where most of the engineering effort actually lives, and where PLM comes in. Each received footprint must be matched to a BOM item, converted to the BOM’s unit of measure, checked for validity, and either used as is or replaced with a fallback. The roll-up engine then multiplies by quantities, adds in-house steps, and produces a new ProductFootprint. This is the topic of the later sections, and it is why the data model carries product identifiers as typed URNs rather than free-text part names.

Why a typed object matters

The thesis of this article is that the exchange protocol is the easy part, and the hard part is the identity and unit mapping between a footprint and a BOM line. A footprint is only useful when it points at the right thing: the right part number, at the right revision, in the right declared unit, with the right validity window. Teams that skip that mapping end up with a carbon column populated by lookup tables that nobody maintains. Teams that treat the footprint as a first-class versioned object tied to BOM items get an audit trail essentially for free.

The PACT Data Model in Detail

The PACT technical specifications are versioned. At the time of writing the published page for version 3 is titled version 3.0.3 and its changelog dates the release to 18 November 2025, with 3.0.0 having been released on 30 April 2025. It is based on PACT Methodology 3.0. Earlier 2.x specifications remain in use in the field, and the developer documentation itself still refers to 2.x in places, so any real integration should negotiate a specVersion rather than assume one. Treat field names below as drawn from the version 3 specification and verify against the version your counterparty runs.

The ProductFootprint object

A ProductFootprint wraps a carbon footprint with identity and lifecycle metadata. The required and recommended fields include:

id: a UUID identifying this specific version of the footprint.
specVersion: the major.minor.patch of the specification used.
precedingPfIds: when a footprint supersedes earlier ones, their ids; if defined, non-empty.
created: the timestamp of creation. The specification says it should not be used to derive validity.
status: either Active or Deprecated.
validityPeriodStart and validityPeriodEnd: when absent, the footprint is considered valid for three years after the end of the reference period.
companyName and companyIds: who owns the footprint, with company identifiers as URNs.
productDescription, productNameCompany, productIds and productClassifications: what it describes, with product identifiers and classifications as URNs.
pcf: the CarbonFootprint object itself.
extensions: an array of DataModelExtension objects for sector-specific data.

The URN approach to identifiers is worth pausing on. Rather than a free-text part name, productIds carries something like a buyer part number or a standard identifier in URN form. The v2 specification gives a rule of thumb: use a registered URN namespace if one applies, then a widely used one, and otherwise the form urn:pact:<domain-of-issuer>:<type>:<value>. The practical effect is that the supplier’s part number and your own can both be attached, which is what allows deterministic matching to a BOM line.

The CarbonFootprint object

The pcf object is where the numbers live. In the version 3 specification it includes, among others:

declaredUnitOfMeasurement and declaredUnitAmount: the functional basis, such as one kilogram or one piece. A footprint of 4.1 kgCO2e means nothing until you know it is per piece rather than per kilogram.
productMassPerDeclaredUnit: the mass of one declared unit, and zero where mass is not relevant. This is what lets you convert between per-kilogram and per-piece footprints.
referencePeriodStart and referencePeriodEnd: the time window the activity data covers.
geographyCountry, geographyCountrySubdivision and geographyRegionOrSubregion: where it was produced, using ISO 3166 codes where applicable.
boundaryProcessesDescription: a recommended free-text description of included processes.
pcfExcludingBiogenicUptake and pcfIncludingBiogenicUptake: the headline values in kgCO2e per declared unit. Having both is how the model handles the biogenic carbon accounting disagreement between methodologies.
fossilGhgEmissions, fossilCarbonContent, biogenicCarbonContent, recycledCarbonContent: component breakdowns used for mass-balance style checks.
Land and biogenic fields such as landUseChangeGhgEmissions, biogenicCO2Uptake (zero or negative) and biogenicNonCO2Emissions (zero or positive), reflecting the additions in methodology 3.0. Some of these are flagged in the specification as conditionally required for biogenic-relevant products.
aircraftGhgEmissions and outboundLogisticsGhgEmissions, plus packaging fields such as packagingEmissionsIncluded and packagingGhgEmissions, so transport and packaging effects can be separated.
Carbon capture fields, such as ccsTechnologicalCO2Capture, technologicalCO2Removals and ccuCalculationApproach with the values Cut-off and Credit.
ipccCharacterizationFactors: required, for example ["AR6"].
crossSectoralStandards: required; allowed values include ISO14067, ISO14083, ISO14040-44, GHGP-Product, PEF and earlier PACT versions.
productOrSectorSpecificRules: an array, empty if none apply, identifying rule operators such as PEF or EPD International.
exemptedEmissionsPercent: the cut-off, so you know how much was left out.
allocationRulesDescription, secondaryEmissionFactorSources (name and version), and primaryDataShare.
dqi and verification.

Several of these fields are the difference between a number you can trust and a number you can only display. exemptedEmissionsPercent tells you whether the supplier cut off 1 percent or 10 percent of emissions as immaterial. allocationRulesDescription tells you how a shared process was split. ipccCharacterizationFactors tells you whether to harmonise GWP values before summing.

Data quality and verification

The dqi object carries data quality ratings. In the version 3 text the fields include technologicalDQR, geographicalDQR and temporalDQR, each a decimal between 1 and 5, based on the PACT Methodology’s data quality matrix. The methodology draft also lists completeness and reliability among the dimensions, so check the exact field set of the version you implement. The methodology draft says primaryDataShare and the quality indicators must be defined for reference periods that include or follow the start of 2025.

The verification object records assurance. Its coverage field takes one of three values: PCF calculation model, PCF program, or product level. It also carries providerName, completedAt, standardName and optional comments. The three coverage values are an important honesty mechanism: a verifier who reviewed the calculation model once has not verified every product that model later produces, and the field makes that distinction machine-readable.

Extensions

DataModelExtension has specVersion, dataSchema, documentation and data. The design intent, as described in the WBCSD announcement of the second version, is an industry-agnostic core that sector groups extend; the Smart Freight Centre was named as developing a logistics extension at that time. The practical implication for a PLM architect is to store extensions as opaque, schema-referenced JSON next to the core fields and not attempt to flatten them into relational columns.

Figure 2: Simplified entity model of the PACT ProductFootprint, its CarbonFootprint core, data quality indicators, verification record and extensions.

The figure shows the nesting: identity and lifecycle fields on the outside, the CarbonFootprint core inside, and quality, verification and extension objects hanging off it. Notice that the lifecycle fields are about the record (version chain, status, validity), while the CarbonFootprint fields are about the number (unit, period, boundary, method). Keeping those two concerns separate in your own schema avoids a frequent bug where a corrected calculation silently overwrites a footprint that downstream customers already consumed.

Lifecycle: versions, deprecation, and validity

The specification states that a footprint with status Deprecated must not be changed. Corrections are issued as a new footprint whose precedingPfIds lists the ids it supersedes, and the older ones move to Deprecated. This append-only discipline is what makes audit possible: a customer can later prove which version of a supplier’s number was in force when it published its own footprint.

Validity is a quiet trap. A footprint with no explicit validity window is considered valid for three years after the reference period ends, per the specification. Three years of carbon change is long for a fast-decarbonising grid. Your policy may legitimately be stricter than the protocol, for example refusing footprints whose reference period ended more than twelve months ago for high-impact categories, and your roll-up engine should enforce it explicitly.

How the Exchange Works: Authentication, Pull, and Request Flows

The PACT developer documentation describes the interface compactly. A conformant solution exposes an HTTP REST API with three mandatory actions and one optional action. Understanding them is enough to decide how much to build and how much to buy.

Authenticate

Authentication is mandatory and uses the OAuth 2.0 client credentials grant (RFC 6749, section 4.4). A client sends its credentials as HTTP Basic authentication to the token endpoint and receives a bearer access token. The documentation says token endpoint discovery should use /.well-known/openid-configuration and its token_endpoint value, with a fallback of /auth/token that must still be exposed when discovery is missing or misconfigured. Credentials (an id and a secret) are exchanged out of band between the two parties; the documentation even suggests email as an acceptable bootstrap, which tells you how young the ecosystem’s tooling still is.

Failure modes here are mundane but frequent: an expired token must produce the TokenExpired error (HTTP 401) so the client can refresh, while a valid token lacking rights must produce AccessDenied (403). Build your client to distinguish the two, otherwise you will retry a permission problem forever.

ListFootprints and GetFootprint

ListFootprints returns the footprints a customer is entitled to see from a given supplier. The documentation lists the path as /footprints with an optional limit parameter; a filter parameter is optional in the specification, and the reference example API does not implement it. Pagination follows the specification’s own mechanism, which means the client must be prepared to follow continuation links rather than assume a single page. GetFootprint retrieves one footprint by id at /footprints/<footprint-id> and returns the latest version of that ProductFootprint. Confirm the exact path prefix and version segment against the specification version your counterparty implements; the documentation pages I reviewed describe 2.x behavior, while the current specification is 3.0.x.

The key operational property is that access is per customer. A supplier typically has many footprints and many customers, and it is the supplier’s solution that decides which of its footprints a particular client credential may list. That is the supplier’s commercial control point and a common source of “why can’t I see my part” support tickets.

Events: requests and publication

Events is optional and lives at /events. According to the documentation it supports four CloudEvents types:

org.wbcsd.pathfinder.ProductFootprint.Published.v1, a notification that a footprint was published or updated.
org.wbcsd.pathfinder.ProductFootprintRequest.Created.v1, a customer asking a supplier for a footprint.
org.wbcsd.pathfinder.ProductFootprintRequest.Fulfilled.v1, the supplier’s positive response.
org.wbcsd.pathfinder.ProductFootprintRequest.Rejected.v1, the supplier’s refusal.

If a solution does not implement Events it must return a NotImplemented error. Without Events, the integration is pull-only: a customer polls ListFootprints on a schedule. With Events, the customer can request a footprint for a part that has none, and the supplier can push a notification when a number changes. The second capability matters more than it sounds, because a silent supplier revision is the main way your own published footprint becomes stale.

Figure 3: Request and pull sequence between a customer solution and a supplier solution in a PACT-style product carbon footprint data exchange.

The sequence shows the usual order: authenticate, send a request event for an unmatched part, receive a fulfilled event, then pull the footprint and store it. A rejected request leaves the BOM line on a fallback factor, which must be flagged in the roll-up so nobody mistakes a gap for a measurement.

A minimal client

The following Python sketch shows the pull path. It is illustrative: the base URL, the exact path prefix and the pagination mechanics must be adapted to your counterparty’s implementation and to the specification version, and production code needs retries, secret management and schema validation.

import base64
import requests

class PactClient:
    def __init__(self, base_url, client_id, client_secret):
        self.base = base_url.rstrip("/")
        self.cid, self.secret = client_id, client_secret
        self.token = None

    def _discover_token_endpoint(self):
        # Spec guidance: prefer OIDC discovery, fall back to /auth/token
        try:
            r = requests.get(f"{self.base}/.well-known/openid-configuration", timeout=10)
            r.raise_for_status()
            return r.json()["token_endpoint"]
        except Exception:
            return f"{self.base}/auth/token"

    def authenticate(self):
        basic = base64.b64encode(f"{self.cid}:{self.secret}".encode()).decode()
        r = requests.post(
            self._discover_token_endpoint(),
            headers={"Authorization": f"Basic {basic}"},
            data={"grant_type": "client_credentials"},
            timeout=10,
        )
        r.raise_for_status()
        self.token = r.json()["access_token"]

    def _get(self, url, **params):
        for attempt in range(2):
            r = requests.get(url, params=params,
                             headers={"Authorization": f"Bearer {self.token}"}, timeout=20)
            if r.status_code == 401:          # TokenExpired
                self.authenticate()
                continue
            r.raise_for_status()
            return r
        raise RuntimeError("authentication failed twice")

    def list_footprints(self, limit=100):
        url = f"{self.base}/footprints"      # verify path prefix for your spec version
        while url:
            r = self._get(url, limit=limit) if "?" not in url else self._get(url)
            for pf in r.json().get("data", []):
                yield pf
            # Follow the continuation link if the server sent one
            url = r.links.get("next", {}).get("url")

def is_usable(pf, today, max_age_days=365):
    from datetime import datetime, timedelta, timezone
    if pf.get("status") != "Active":
        return False
    end = datetime.fromisoformat(pf["pcf"]["referencePeriodEnd"].replace("Z", "+00:00"))
    return today - end <= timedelta(days=max_age_days)

Two design choices in the sketch are worth defending. First, is_usable applies a business policy on top of the protocol’s three-year default validity, as discussed earlier. Second, the client yields footprints lazily and leaves persistence to the caller, because ingestion should store the raw JSON untouched and derive any relational view from it. Storing the original payload is what lets you re-run a roll-up later and prove what you saw.

Choosing a topology

There are three practical topologies. Point-to-point, where each customer integrates directly with each large supplier, works for a handful of strategic relationships and collapses beyond that. A conformant solution provider hides the plumbing and gives you a single integration that reaches any other conformant participant, which is the premise of the Pathfinder Network. Sector data spaces, such as Catena-X in automotive, add sovereignty controls, contract negotiation and a certified onboarding process on top of the same underlying data model; the Catena-X ecosystem publishes its own PCF endpoint specification, which is derived from the PACT work. If you operate in a sector with an established data space, you will likely use its connector layer for sensitive supplier relationships and PACT-conformant tooling elsewhere.

Rolling PCFs Up Through the BOM

A PCF roll-up computes the footprint of an assembly from the footprints of its children, plus the emissions of the steps performed at the assembly level. The principle is simple. The engineering is in unit conversion, scrap, allocation, missing data and revisions.

The core equation for an assembly A with children i is:

PCF(A) = Σ [ q_i × (1 + s_i) × PCF_i ] + E_own(A) + E_transport(A) + E_packaging(A)

where q_i is the BOM quantity, s_i is the scrap or yield-loss uplift for that component, PCF_i is the child’s cradle-to-gate footprint per declared unit converted to the BOM unit, and the remaining terms are the emissions you add at your own gate. Everything is expressed per one declared unit of A.

A worked example (illustrative numbers)

The following figures are invented to demonstrate the arithmetic. They are not measurements of any real product. Consider a motor controller, one piece, with these BOM children.

Item	Source	Qty	Scrap uplift	Footprint basis	kgCO2e per unit of A
PCB assembly	Supplier PCF (primary)	1	0%	4.10 per piece	4.10
Power module	Supplier PCF (primary)	1	0%	6.30 per piece	6.30
Aluminium housing	Secondary factor 8.0 per kg	0.30 kg	12%	8.0 per kg	2.72
Connector set	Secondary, spend-derived	1	0%	0.80 per set	0.80
Wiring harness	Secondary, average data	1	0%	0.60 per piece	0.60
Packaging	Secondary factor	1	0%	0.12 per set	0.12
Inbound transport	Allocated freight	1	0%	0.35	0.35
Plant electricity	0.9 kWh at 0.45 kgCO2e per kWh	1	0%	0.405	0.405

The housing line shows the scrap arithmetic: 0.30 kg of finished mass with a 12 percent uplift means 0.336 kg of input, and 0.336 times 8.0 gives 2.688, which the table rounds to 2.72 after rounding the input to 0.34 kg for readability. In a real system keep full precision and round only for display. The total is about 15.40 kgCO2e per controller.

Two lessons come out of the table. First, the two supplier-specific footprints (10.40 of 15.40) dominate the total, so the quality of those two numbers matters far more than the packaging line, and a data-collection programme should spend its effort accordingly. Second, a simple emissions-weighted share of primary data is about 70 percent here if you count the two supplier footprints plus measured plant electricity (10.805 of 15.395). That is a coarse proxy: the supplier footprints themselves contain secondary data, so the true share is lower, and the PACT definition of primaryDataShare should be read in the methodology before you publish one.

Allocation: the hidden assumption

When one process serves several products, emissions must be divided. Suppose a shared assembly line consumed 6,000 kWh in a month, producing the controller (60 percent of machine hours) and a sibling product (40 percent). Allocating by machine hours assigns 3,600 kWh to the controller; allocating by mass or by revenue would give different splits. The ISO 14044 allocation hierarchy, which ISO 14067 inherits, prefers avoiding allocation through subdivision or system expansion, then physical relationships, then economic value as a last resort. Your PCF should record the choice in allocationRulesDescription, because a customer comparing two suppliers cannot interpret the numbers without it.

The practical failure is inconsistency: a supplier that allocates by mass this year and by revenue next year will show a footprint movement that is purely an accounting artefact. Pin the allocation rule in the calculation model, and treat a change as a methodology revision that produces a new, versioned footprint.

The roll-up engine

A robust engine treats the BOM as a graph, resolves each node to the best available footprint, and propagates both the value and its quality metadata upward. Because the BOM is a graph rather than a table, the same where-used and traversal machinery used for change impact applies; see our piece on PLM graph database impact analysis and where-used queries for the traversal patterns, which carry over directly to carbon roll-ups and to “which products are affected when this supplier revises its footprint”.

Resolution should follow a priority order: a valid, active supplier footprint matched on product identifier and revision; then a supplier footprint at a coarser level such as the part family; then a secondary database factor selected by material and region; and finally a spend-based or default factor, clearly flagged. Each rung down the ladder lowers confidence, and the engine should carry the rung forward so the output can state what fraction of the total came from which tier.

from dataclasses import dataclass, field

@dataclass
class Resolved:
    kg_per_unit: float
    tier: str              # "supplier", "family", "secondary", "default"
    source_id: str = ""

@dataclass
class Node:
    part: str
    qty: float = 1.0
    scrap: float = 0.0
    children: list = field(default_factory=list)
    own_emissions: float = 0.0

def rollup(node, resolve):
    """Return (kgCO2e per unit, dict of kg by data tier)."""
    tiers = {}
    if not node.children:
        r = resolve(node.part)
        total = r.kg_per_unit
        tiers[r.tier] = total
    else:
        total = node.own_emissions
        tiers["own"] = node.own_emissions
        for ch in node.children:
            sub, sub_tiers = rollup(ch, resolve)
            factor = ch.qty * (1.0 + ch.scrap)
            total += factor * sub
            for k, v in sub_tiers.items():
                tiers[k] = tiers.get(k, 0.0) + factor * v
    return total, tiers

The function returns the total and a breakdown by data tier. The breakdown is the deliverable that auditors and procurement teams actually use: it says “62 percent of this number rests on supplier-specific data and 9 percent on defaults”. A single number without that decomposition invites false precision.

Figure 4: Resolution ladder and roll-up flow that turns supplier footprints, secondary factors and in-house emissions into an assembly PCF with data-tier metadata.

Unit and identity mapping

The most boring problems cause the most errors. A supplier declares its housing per kilogram while your BOM counts pieces; the conversion uses productMassPerDeclaredUnit, and where that is zero (mass irrelevant) you must not divide by it. A supplier changes its part revision, and the footprint’s productIds no longer matches your BOM line, so the match silently falls to a secondary factor. Add a reconciliation report that lists every BOM line by resolution tier and flags lines whose tier dropped since the last run. That one report catches most silent degradation.

Versioning the result

Your own roll-up output is itself a ProductFootprint, with precedingPfIds pointing at its earlier versions and a record of the input footprint ids it consumed. Keep that lineage. When a supplier deprecates a footprint, you can compute exactly which of your published footprints depended on it and decide whether a republish is warranted. Without lineage, you can only guess.

Linking to the Digital Product Passport

The Digital Product Passport (DPP) is the structured, machine-readable record the EU’s Ecodesign for Sustainable Products Regulation foresees for many product groups. Carbon footprint is one candidate data element, and battery rules already require carbon footprint declarations for certain battery categories under the EU Batteries Regulation; the exact scope, calculation rules and dates are set in delegated and implementing acts, so check the current text for your product group rather than relying on a summary.

For architects, the point is separation of concerns. The PCF is a calculated, versioned evidence object with provenance. The passport is a published view that references or embeds selected evidence for a given product instance or model. Our overview of digital product passport architecture covers the identifier, registry and access-control side. The carbon-specific lesson is to store the footprint with its full ProductFootprint metadata and let the passport carry a reference plus the fields the regulation requires, so a verification or deprecation upstream can propagate to the passport view.

Granularity is the open design question. A PCF is typically computed for a product model over a reference period, not for each serial number, while a passport can be item-level. Decide which passport attributes are model-level (the footprint) and which are instance-level (serial, manufacturing date), and avoid generating a distinct footprint per unit unless your regulation demands it and your data supports it.

Trade-offs, Gotchas, and What Goes Wrong

Comparability is weaker than the schema suggests. A shared data model standardises the shape of a footprint, not its comparability. Two footprints with identical fields can differ because of cut-off, allocation, background database vintage or biogenic treatment. Use exemptedEmissionsPercent, allocationRulesDescription, secondaryEmissionFactorSources and the cross-sectoral standards field to detect when numbers are not like for like before you rank suppliers.

Verification is not binary. The three verification coverage levels differ greatly in assurance value. A product-level verification is stronger than a verified calculation model, which is stronger than a verified programme. A procurement policy that says “verified only” without specifying the coverage invites loopholes.

Double counting at tier boundaries. If your supplier’s footprint already includes the transport to your gate, and you add inbound freight again, you count it twice. Agree on boundary definitions: PACT footprints are cradle-to-gate, and logistics are intended to be handled separately using fields such as outbound logistics, but real suppliers vary. Read boundaryProcessesDescription for any high-impact input.

Stale and silent revisions. Because validity defaults to three years, a footprint can stay “active” long after its underlying grid mix has changed. Combine your own age policy with Events subscriptions so that a published update triggers a re-roll-up of dependent assemblies.

Over-trusting primary data. Supplier-specific does not mean accurate. A supplier with immature measurement may report a precise-looking number built on a poor allocation. Carry a data quality score through the roll-up and weight your improvement effort by contribution, not by who claims to have primary data.

Confidentiality. A detailed footprint can reveal process information a supplier regards as sensitive, and a customer’s request for per-part numbers reveals its own product structure. Aggregation levels, access control per client credential, and, in data-space deployments, usage policies are the available controls. Do not assume a footprint is harmless to share simply because it is one number.

Spec and tooling churn. The specification moved from 2.x to 3.0 in 2025, and the methodology added biogenic items that become mandatory for specific cases on a schedule. Your ingestion layer should tolerate multiple specVersion values and keep unknown fields. A strict parser built against one version will reject valid data from a supplier a version behind.

Mixing GWP vintages. Summing a footprint calculated with AR5 factors and another calculated with AR6 produces a number with no clean methodology. Check ipccCharacterizationFactors and either harmonise or flag mixed sums.

Practical Recommendations

Start from the contribution analysis, not the protocol. Run a rough spend-based or average-data roll-up on your top products, identify the handful of purchased items that dominate, and request supplier-specific footprints for those first. Ten well-chosen primary numbers beat a thousand weak ones, and the pareto shape of most BOMs makes this achievable within a quarter.

Treat the footprint as a versioned, first-class object linked to BOM items by identifier and revision, store the raw payload, and derive everything else. Enforce an explicit validity policy tighter than the protocol default where decarbonisation is fast, and wire Events or scheduled polling so that supplier revisions trigger recomputation. Carry resolution tier and data quality through every roll-up, and publish them with your own footprint.

Buy rather than build the exchange layer unless you are a solution provider. Choose a PACT-conformant provider so interoperability is tested against the specification, and ask about version support, request handling, and verification metadata. Build the part that is unique to you: the mapping to your PLM item and revision model and the roll-up logic.

A short checklist:

Confirm which PACT specification version each major supplier runs and negotiate specVersion.
Map every high-impact BOM line to a supplier product URN and revision.
Store raw ProductFootprint JSON and its lineage; never overwrite, always supersede.
Define a validity and age policy and enforce it in code.
Record allocation, cut-off and background database in every published footprint.
Produce a reconciliation report of BOM lines by resolution tier after each run.
Decide model-level versus instance-level data before building passport outputs.
Track ISO 14067 revision news and PACT methodology updates.

This article is an architectural and data-engineering analysis, not legal or compliance advice; regulatory obligations depend on product category and jurisdiction.

Frequently Asked Questions

What is product carbon footprint data exchange?

It is the structured transfer of product-level greenhouse gas results between companies, so a supplier’s calculated footprint can be consumed in a customer’s own calculation. The exchange carries not only the kgCO2e value but also its declared unit, reference period, boundary, allocation, data sources, quality ratings and verification status. The PACT technical specifications define a common data model and a REST API for this purpose, making exchange possible across different software vendors.

How does ISO 14067 relate to the PACT data model?

ISO 14067 specifies principles, requirements and guidelines for quantifying and reporting a product carbon footprint, consistent with ISO 14040 and 14044. PACT is not a replacement. The PACT Methodology builds on existing standards such as the GHG Protocol Product standard, and the data model has a field listing which cross-sectoral standards, including ISO14067, a calculation used. ISO defines how to calculate; PACT narrows choices and standardises how results travel.

What is the Pathfinder Network?

It is the WBCSD-backed ecosystem of interoperable solution providers that exchange PCF data using the PACT technical specifications. The developer documentation calls it infrastructure for exchanging verified product emissions data and describes the aim as an internet for emissions data. A company joins by using a conformant provider, which has tested its implementation against the specification with partners, rather than building point-to-point integrations itself.

Are supplier PCFs additive in a BOM?

They are additive when they share a consistent cradle-to-gate boundary and declared unit, which is how PACT footprints are designed. You multiply each by BOM quantity, apply scrap uplift, convert units using the declared unit and mass fields, and add your own manufacturing, packaging and logistics. They become non-additive when boundaries overlap, GWP vintages differ, or units are mismatched, so check metadata before summing.

How long is a PCF valid?

Under the version 3 specification, if a footprint does not state a validity period it is considered valid for three years after the end of its reference period. Many organisations apply tighter internal limits, for example one year, for energy-intensive inputs. A footprint with status Deprecated has been superseded and must not be changed, so check status as well as dates.

How does this connect to the Digital Product Passport?

The PCF is the evidence; the passport is a published view. Keep the full ProductFootprint, with provenance, verification and version lineage, in your PLM or compliance store, and let the passport reference or embed the fields a regulation requires. That way, a supplier revision or a deprecation can be traced to every affected passport rather than discovered during an audit.