Same emissions, two systems: what really bridges your PCF and CBAM

CBAM's definitive phase went live in January 2026. For the first time, EU importers of steel, aluminium, cement, fertilizers, hydrogen and electricity face real financial exposure tied to the embedded carbon in what they buy. Many turned to the product carbon footprints they already had, expecting them to carry most of the load. They do not.

The same physical emissions sit behind both a PCF and a CBAM declaration, yet the data does not move cleanly from one to the other. It is tempting to read this as a formatting nuisance, something a converter could fix. It is not. The gap is structural, and understanding why is the first step to closing it.

Over the past five months, PACT launched a CBAM working group with 44 members and ecosystem partners globally, mapping that gap in detail: 56 specific points of divergence between product level carbon accounting and CBAM's installation level reporting, across seven dimensions.  The result is more useful than a blunt "they do not match." It shows precisely what data already aligns, what needs recalculating, and what has to be collected at source.

The cost of missing data is already being charged

CBAM is only the most immediate of at least five frameworks asking suppliers for versions of the same underlying data, alongside PCFs, CSRD, Digital Product Passports and battery regulations. Each defines its own boundaries and evidence requirements, and each triggers a separate request to the same supplier.

For CBAM, the consequence is priced. When an importer cannot obtain actual supplier emissions, CBAM applies default values, and those defaults carry escalating markups on the applicable carbon price: 10% in 2026, 20% in 2027, and 30% from 2028 for steel, cement, aluminium and hydrogen. That premium reflects regulatory design, not the carbon performance of the product.

The scale is material. In an illustrative steel scenario, an importer relying on defaults could pay roughly 20-80% more in certificate costs than one using verified installation data. That figure is directional rather than a precise liability calculation, and it rests on specific assumptions about shipment, carbon price and default intensity. Your numbers will differ. The direction will not.

Same emissions, two incompatible architectures

The reason a PCF cannot simply become a CBAM number is that the two were built to answer different questions.

Product level accounting, expressed through ISO 14067 and the GHG Protocol and operationalized through PACT, asks: what is this product's carbon footprint cradle-to-gate? It works from the bottom up, following the product through the value chain and attributing emissions to a declared unit, for example a kilogram at the factory gate.

CBAM, which inherits its logic from the EU Emissions Trading System, asks a different question: what are the total emissions at this installation, and how much of them attach to this traded product? It works from the top down, starting at the physical plant and allocating monitored emissions to output products.

Same physical emissions, different organizing logic. From that single mismatch, four consequences cascade: different system boundaries, different allocation rules, different treatment of electricity and heat, and different data quality thresholds. This is not a conversion problem. It is an organizing logic problem, and no amount of reformatting resolves it.

Why no tool will convert a PCF into a CBAM record

This is worth stating plainly, because the market keeps hoping otherwise. You cannot reverse engineer a CBAM declaration from a finished PCF, because the two are built in opposite directions.

A PCF is assembled from the bottom up: it traces inputs through the network and rolls them into a single number per unit of product, with database averages allowed where primary data is missing.

CBAM works from the top down: it starts at an installation's total emissions and carves them down to the product, installation by installation, requiring installation specific data even for upstream precursors. Once a PCF has aggregated its way up to a per unit figure, the installation level detail CBAM starts from is already gone. You cannot run the calculation backwards to recover it.

Electricity makes the point, particularly for aluminium. CBAM mandates the inclusion of indirect emissions (electricity) for aluminium, while steel and cement currently handle this differently. For aluminium in particular, CBAM treats electricity as a product with its own embedded emissions subject to the mechanism, while ISO 14067 treats it as an input to other products. Those are not two formats of the same answer. They are different outputs. Any vendor promising a one click PCF to CBAM converter is offering something that cannot exist.

The honest path is not conversion. It is collecting the right underlying data once, at sufficient granularity, so that each output can be produced from a common base.

What the mapping found

Of the 56 gaps, each fell into one of three types:

1. 14% are reporting gaps: the data already exists in a PCF and needs only relabeling or reformatting.
2. 29% are parametric: the data exists but must be recalculated using CBAM's prescribed emission factors, GWP values or allocation rules.

Together, 43% of the gap is bridgeable from data companies largely already hold.

1. The remaining 57% are structural. Here, CBAM needs data that product level accounting does not currently capture: installation level totals preserved before product allocation, emissions retained per individual gas before conversion to CO2e, energy disaggregated so heat and electricity are tracked separately, upstream contributions traced to specific installations, and provenance metadata on each data point.

That 57% is not a failure of interoperability. It is a specification. It tells suppliers exactly what to begin collecting at source, and it is short enough to act on: five minimum requirements cover most of it.

This work does not start from zero. It builds on existing efforts, and the intent is to converge on a shared set of exchangeable objects rather than add another proprietary format to the pile.

Join us as we explore CBAM

If your organization is exposed to CBAM, or building the tools that will carry this data, now is the moment to help shape the specification and the work that PACT is doing. Contact us at pact@wbcsd.org