Toward a Technology Ecosystem for Carbon Accounting – Rocky Mountain Institute
Importance of Accounting
Traditional accounting took around 5,000 years to evolve. Accounting does not just predate writing, it is why writing was invented: the earliest written artifacts, such as this cuneiform clay tablet, were records of commodity trading.
However, carbon accounting at the company level has only been around for about 20 years. And though we are beginning to see more efforts like RMI’s steel emissions accounting guidance, efforts at the product level are only just beginning to take shape. While informed by earlier forms of accounting, a new set of carbon-specific building blocks is needed to allow buyers and sellers, auditors and entrepreneurs, software companies, and sustainability professionals to build and deploy interoperable systems that are as accurate and ubiquitous as those for traditional accounting.
As climate awareness increases along with social and regulatory pressure, over 800 of the largest publicly traded companies have made net-zero commitments to reduce their emissions. For companies to make good on these commitments and know where to focus their reduction efforts, they need emerging carbon accounting systems to understand their current emissions and the broader climate impacts of their decisions.
No company would launch a new product, make a strategic decision, or make capital investments without fully understanding the financial implications. With better carbon accounting, the same can and should be true for emissions. Understanding the carbon implications of decision-making should become an expected and required part of any business process, and creating an ecosystem of interoperable carbon accounting technologies is a means to that end.
These technologies are needed to give teeth to green procurement policies, such as those required by the Inflation Reduction Act, to know if companies are making good on their net-zero commitments, and to guide corporate strategy. We will not achieve meaningful decarbonization without them.
How It’s Done Today
The Greenhouse Gas Protocol, or GHGP, is the most common method of tabulating emissions. First released in 2001, over 92% of the Fortune 500 companies reporting emissions follow it. Although the GHGP is being revised, and innovations such as consequential accounting are advancing the state of the art, the foundations of how to do carbon accounting are becoming established.
However, as with the web in the 1990s, there is no widely used common standard — no data format — for describing and exchanging emissions data. It is as if every phone took pictures in its own format, unreadable by that of anyone else. As a result, different companies cannot readily share emissions data, and when they do, it is difficult to use in decision-making.
Existing platforms for reporting carbon data, such as CDP and EcoVadis, are valuable tools, but they are geared toward annual reporting. Data released through them is inherently out of date by the time it is shared. Additionally, they focus on the organizational level rather than the product and transactional levels, where better data can help companies make operational decisions to lower carbon emissions.
Today, the typical process for exchanging product emissions data is as follows: someone on a company’s procurement or sustainability team figures out who to contact at each of their vendors, often not a mean feat. They then email each vendor to request emissions data. A vendor may or may not have that data, may or may not be willing and able to share it, and may or may not include (or even know) the methodology by which it was collected. Do they include all three Scopes? What boundaries do they use? Do they share the emissions factors they use or the proportion of direct data to be modeled or estimated data? Each vendor is likely to have different answers to those questions, have answers of varying quality, or provide no details at all — as a result, it is difficult to compare data across vendors.
Companies seeking carbon data will typically receive it in assorted formats: some vendors send spreadsheets, others send PDFs, some fill in vendor surveys, and some just copy and paste their data into emails. As the systems used by vendors and buyers cannot communicate with each other and do not use the same formats, they are not interoperable — meaning what in the financial world would be an automated and instantaneous exchange is instead highly manual and can take months. Once data is collected, someone on the receiving end needs to consolidate all this and make sense of disparate, often unstructured data. They are more than likely to then put it into an arbitrarily formatted spreadsheet of their own. When one of the company’s customers, in turn, requests carbon data, the process will be repeated.
Due to all these barriers, getting emissions data from suppliers is often an annual ritual timed around the release of a yearly sustainability report. This is not very useful for business decisions. Can you imagine trying to make a budget but only being able to see your bank balance once a year?
How It Should Work
Instead, imagine buyers logging in to their vendor’s system and simply downloading the data they need. They can do this knowing the data was gathered according to standard methodologies and is being supplied in a standard format, so it can be uploaded into the buyer’s system without having to be converted or poured over.
Likewise, vendors who once had to manually field dozens to thousands of individual requests for data can now provide high-quality data automatically at any time with much less effort. With the data they supply now being more easily compared with that of their competitors, they know they are evaluated on a level playing field and have an incentive to improve their scores.
Now imagine buyers’ and sellers’ systems being connected and data transferred automatically like the direct deposit of a paycheck — and buyers connecting to all their vendors and getting comparable data in the same format from each of them. With the benefit of standard formats, they do not have to use the same software — just software that supports the standard, the way word processing programs from Microsoft and Apple can read the same files (because they both read OpenXML — an open standard).
Using existing business intelligence software or a new generation of dedicated carbon accounting software, buyers could see the emissions consequences of their purchases in real time. They could more easily make low-carbon purchasing decisions, helping them meet net-zero targets and comply with a growing wave of product-level emissions regulations. By aggregating data from multiple suppliers, they could more accurately describe the embodied emissions of their own products and supply that data to their customers, allowing them to qualify for green procurement benefits.
No single piece of technology will accomplish all of this by itself. But as an ecosystem of standards and related technologies coalesces, they combine to make this vision possible. There are, however, several problems that must be addressed:
Comparability
To make better choices, you need to compare things. If a package of Twinkies contains 1,176 joules of energy and a blueberry muffin contains 470 calories (also a measure of energy), which should you choose? It might be a surprise that Twinkies would be the slimming option, which would be clear if the units were the same — one calorie equates to about four joules.
For food labels to be useful in letting you compare options, they need to include the data you are looking for (here, energy) and be in consistent units — calories or joules, but not both. Food labels require a standard — in this case, the FDA’s Food Labeling Guide.
Comparability can provide clarity by telling you to avoid (or eat) the muffin. Having a format does not ensure a vendor will provide the data requested, but just by creating the possibility, a format can act as a carrot and a stick, nudging vendors in the right direction.
🥕 The carrot: That a format asks for or requires certain fields lets the vendor know what is important. You do not get what you do not ask for, often for the simple reason that the other party might not know you want it. Just seeing that a format has space for a piece of data may prompt a vendor to provide it.
🏒 The stick: Conversely, when something is asked for and explicitly not provided, that tells you something too. One way to incentivize the sharing of data is to make conservative assumptions when it is asked for and not provided. This already happens in practice. For example, when someone outside the producing company estimates the emissions of a product, they may use grid intensity to calculate energy-related emissions. If the company has power purchase agreements (PPAs) with renewable energy providers to reduce emissions attributable to energy, those may not be factored in, resulting in an inflated emissions estimate.
For a company whose products have low carbon intensity, making it easy for customers to see this allows them to seek a premium for providing a better product. Moreover, by gaining visibility into their supply chains, companies wanting to make green claims about their products can do so more readily. If the right data is supplied by vendors, those claims are legitimized, auditable, and less likely to be considered greenwash.
Interoperability
According to a former product manager at Google, creator of the Chrome browser, half the people on the Chrome team — half — are working on web standards, which Chrome needs to adhere to in order to support interoperability.
Web standards work because the overwhelming majority of the browser market — Google Chrome, Apple Safari, Mozilla Firefox, Microsoft Edge, and Internet Explorer — support their standards.
This interoperability gives companies the confidence they need to build applications for the open web, benefiting all standards-compliant browsers. Software developers want to be able to build web applications and know all customers, regardless of their browser, will be able to use them. Additionally, the browser companies know that by supporting standards, more applications will run on them, allowing them to expand their user base. This has created a virtuous cycle where the more the browsers adhere to standards, the more software is written for them. The more the software written for them, the larger the market becomes.
Similarly, the adoption of carbon data standards would make it easier to request carbon data and provide it. As it becomes simpler for companies to collect upstream data, it in turn becomes easier for them to provide it to their own customers downstream. As more of the vendors in a company’s supply chain provide data, the laggards who do not can be identified and made to do so. As the flywheel gains momentum, it becomes possible and increasingly easy to make low-carbon purchasing decisions.
Machine-readability
Once computers can automatically connect and exchange carbon data directly, new possibilities arise.
Systems might be programmed to solely allow the purchase of commodities or products that meet low-carbon standards. For complicated supply chains and companies with thousands of vendors, to get visibility automatically and at scale might reveal previously unknown carbon hot spots and, thus, opportunities to drive emissions reduction. It might also allow companies to compare carbon intensity and pricing in a way that lets them prioritize the highest ROI steps toward decarbonization.
Supply-chain management vendors such as SAP and Kinaxis see the opportunity and are taking steps in this direction. With broad availability of standardized, interoperable, machine-readable emissions data, carbon accounting and emissions tracking can be integrated into the broader supply chain management (SCM) software ecosystem, taking us one step closer to the goal of lower emissions through supply chain visibility.