The "cradle to gate" approach adopted in this report foresees that firms will share carbon footprint data with their customers. Communicating carbon footprint data along the supply chain is therefore the fifth building block for carbon footprints. This will require interoperability of software solutions, not only for the exchange of data between large firms, and for the exchange of data between farmers and their buyers, but also between various data sources (e.g. government databases, suppliers, smart farm equipment) and farm level calculation tools. This chapter also discusses the importance of a harmonised data format as a tool for interoperability.
Measuring Carbon Footprints of Agri‑Food Products
Eight Building Blocks
Abstract
According to the “cradle-to-gate” principle explored in this report, each firm receives carbon footprint data from its suppliers, adds its own emissions, allocates the resulting emissions among its products, and shares the resulting carbon footprint with its customers. Communicating product carbon footprint data along the supply chain is thus an essential building block.
The starting point is the assumption that actors along the supply chain use digital tools for carbon footprint calculations and emissions accounting. Many large firms already use specialised software for firm-level emissions reporting and in some cases for calculating product carbon footprints for internal use, and the past decade has seen strong growth in the number of technological solutions available for these purposes. One overview of the market counted 88 such solutions as of June 2024 (Verdantix, 2024[1]). As discussed in Chapter 6, there are also several farm level tools for calculating carbon footprints. Communicating carbon footprint data along a supply chain is then a matter of connecting the different software solutions. The question is not unique to food systems, and the discussion here will draw on insights from cross-sectoral initiatives as well as initiatives in other industries. But there are some specific features of food systems which require attention, notably the large number of small primary producers with limited capacity for complex data management tasks.
A recurring theme in this chapter is the importance of interoperability, understood as the technical capability of two or more heterogenous systems to exchange and use information effectively, enabling the connection of diverse digital structures within a larger workflow (Jouanjean et al., 2020[2]). The question of interoperability is broader than just the exchange of product carbon footprint data along the supply chain: it already came up in the previous chapter in the context of exchanging data between LCA databases, and will also make an appearance in the context of other building blocks. For example, a lack of interoperability means that data may need to be manually entered, stored, and converted. This not only requires more effort but also increases the likelihood of errors and reduces traceability; interoperability therefore also matters for ensuring data quality (Chapter 9) and for scaling up carbon footprints while keeping costs low (Chapter 10).
There are several possible obstacles to interoperability. For example, data could be stored in different data formats, using different variable names, using different definitions or calculation methods, expressed in different units, or using different levels of (dis)aggregation. Some of these are actual technical obstacles which prevent data exchange. Others, such as the use of different calculation methods, do not necessarily prevent data exchange but might mean that the resulting data is not meaningfully comparable. Because calculation methods and the like were discussed earlier, the focus in this chapter is on technical aspects of interoperability. Some regulatory and governance aspects are discussed as well.
There are at least three distinct steps in the agri-food supply chain where technical interoperability matters (Figure 8.1). Working backwards through the supply chain, they are:
The exchange of product carbon footprint data between large firms, e.g. between food manufacturers and retailers (or between primary processors and manufacturers, between wholesalers and retailers, and so on). The technical interoperability challenge here is similar to that in other industries.
The exchange of product carbon footprint data between farmers and primary processors, based on the output of farm level calculation tools.
At the farm level, the collection of various data inputs necessary to calculate product carbon footprints. These can include product carbon footprint data from suppliers (e.g. for fertilisers, feed, or electricity), data from farm management software, data from smart farming equipment, and data from government databases.
Note: Transport is not explicitly shown in the supply chain diagram as it occurs in between each stage, but is also in scope.
Source: OECD analysis.
For each of these three cases, several initiatives have made important progress, as discussed below. Some solutions build a specific data exchange platform, while others focus on allowing different solutions to exchange data peer-to-peer; some approaches are sector-agnostic, whereas others are specifically tailored to food systems. An important next step is to ensure that various initiatives are aligned to avoid the emergence of parallel but incompatible ecosystems. In addition, each of the three cases could involve cross-border data exchange and could hence be restricted by data localisation measures, as discussed below.
Consider a retailer calculating the carbon footprint of its products using data from a food manufacturer. Rather than manually exchange data, the two firms seek to automate their data transfer. However, the firms use different emissions accounting software. To automate data transfer, the retailer and the food manufacturer need to make their software systems “talk to each other”.
To understand the technical requirements for this, an analogy can help. Imagine the food manufacturer’s data as consisting of physical components which are stored in its warehouse and need to be transferred to the retailer’s warehouse (Figure 8.2). The retailer sends a data request to the food manufacturer, in the form of a truck with empty boxes labelled with the various data elements needed. Upon arrival, a worker in the warehouse of the food manufacturer verifies the identity of the truck driver, and then takes the requested data elements from the warehouse and places them in the proper boxes on the truck. The truck drives back to the retailer’s warehouse, where a worker in the retailer’s warehouse unloads the truck and stores the data elements internally.
Source: OECD analysis.
In this analogy, the food manufacturer and the retailer could have completely different ways of organising their warehouses. What matters is merely that they agree on which data elements go in which boxes, and under which labels. The food manufacturer and the retailer are not even required to use these labels in their own warehouse, as long as the warehouse workers have a clear “dictionary” to translate the common label into the corresponding term used internally. However, some degree of standardisation of the data elements themselves may be needed, to avoid elements which are too big or the wrong shape to fit into their boxes.
This analogy describes the essence of Application Programming Interfaces (APIs), a widely used type of software code which allows for communication between different systems. APIs typically include instructions for how to access a system (similar to directions to the warehouse of the food manufacturer), security features (similar to the verification of the identity of the truck driver), and information on the agreed variable names and type of content found in those variables (similar to the labels and boxes on the truck). Such an API can allow for data exchange between the food manufacturer and the retailer despite their use of different emissions accounting software.
The Partnership for Carbon Transparency (PACT) has developed technical specifications for APIs to exchange carbon footprint data (WBCSD, 2022[3]). To enable both cross-industry interoperability and industry-specific requirements, PACT provides a core data model common to all industries but also allows for industry-specific “data model extensions.” At the time of writing, PACT is exploring such extensions for the agri-food sector, e.g. to address the reporting requirements of the GHG Protocol Land Sector and Removals Guidance (discussed in Chapter 4).
The PACT approach is already in use by major firms across a range of sectors, including Unilever, Dow, Colgate-Palmolive, and Schneider Electric, and also underlies other sector-specific initiatives, including in the chemicals industry (Box 8.1).
Together for Sustainability (TfS) is an initiative of the chemicals industry which has made significant progress in enabling the automated exchange of product carbon footprint data.
TfS currently counts 53 member firms, including agrochemical firms such as BASF, Bayer, Corteva, SABIC, Syngenta, and Yara, as well as other major firms such as AkzoNobel, Dow, Henkel, Merck, and Solvay. TfS members represent annual sales of more than EUR 800 billion.
Building upon the PACT Pathfinder Framework as well as the ISO and GHG Protocol standards, TfS first developed a product category rule for chemical products. More specific product category rules (e.g. for particular types of chemical compounds) can be built on top of this. The goal is to ensure that all firms in the chemicals sector calculate carbon footprints in a comparable way.
TfS subsequently set up the data exchange platform siGREEN, developed by Siemens, to automate data exchange of product carbon footprints between member firms. The technical aspects of this platform are consistent with the PACT specifications. At the time of writing, this platform is in a pilot phase.
These developments build on initiatives by individual firms in the industry to automate their carbon footprint calculations. BASF was the first firm to develop large-scale automated product carbon footprint calculations, covering its portfolio of 45 000 distinct products through the use of tailor-made carbon accounting software. The underlying methodology aligns with the carbon footprint standards of ISO, GHG Protocol, and TfS, and relies on primary data instead of industry averages. Since this data is already TfS compliant, it can be seamlessly integrated with the siGREEN platform and shared with BASF’s customers.
The work of TfS is relevant to food systems for two reasons. First, many TfS members are major suppliers of agrochemicals, so that product carbon footprint data from the industry are a relevant input in carbon footprint calculations for food systems. This is especially the case for synthetic nitrogen (two major producers, Yara and SABIC, are TfS members). Second, while food systems face some unique challenges, the TfS example carries lessons on the importance of simultaneously harmonising reporting standards and methodologies while building technological solutions for automated data sharing.
Source: Together for Sustainability, “Scope 3 GHG emissions programme”, https://www.tfs-initiative.com/how-we-do-it/scope-3-ghg-emissions (accessed 5 June 2024); interview with Alessandro Pistillo (BASF/TfS).
The previous example illustrated data exchange between two large firms. But a key characteristic of agri-food supply chains is the presence of many small producers: farmers (Figure 8.3). These will typically have a lower capacity to deal with complex data or software issues. They are also less likely to use the same carbon accounting software solutions used by large firms. However, farmers may be using a farm level calculation tool as discussed in Chapter 6. It can be challenging to collect the activity data needed to calculate a carbon footprint using such a tool; the next section discusses this in more detail. Assuming that farmers are able to calculate a carbon footprint, however, how could data be exchanged between farmers and processors?
Farmers have several options for sharing their product carbon footprint with processors.
A first option involves sending their activity data to processors, who would then calculate the emissions score. However, farmers might not agree to this due to concerns about data ownership and privacy.
A second option is for farmers to calculate their emissions themselves (or with the help of, for example, a farm advisor) and send only the final product carbon footprint to processors using a data sharing function integrated in the farm level calculation tool. For example, the Cool Farm Tool allows farmers to share their final footprint with third parties using a share code.
A third option is for farmers to use a farm level calculation tool, export the data from the tool in a specific format and share it with processors themselves.
Source: OECD analysis.
All of these options require the data format to be compatible with other formats and software tools, such as those promoted by PACT, and all require a digital platform for data sharing. But product carbon footprints are just one area where farmers may be asked to share data with other firms in food systems. Such data exchanges are essential to unlock the promise of the digital transformation of agriculture, but farmers have often been reluctant to share their data (McFadden, Casalini and Antón, 2022[4]) (McFadden et al., 2022[5]). Causes include concerns around data privacy, ownership, and security, as well as perceived risks of lock-in (where data is ‘stuck’ with one solution provider, limiting farmers’ ability to switch providers). In other cases, farmers are already required or willing to share data (e.g. for mandatory reporting, or in the context of subsidy schemes, quality assurance, etc) but have no easy or secure way of doing so. For example, farmers may be asked to report the same data in different formats to different entities.
One initiative to address these problems is DjustConnect (https://www.djustconnect.be/en), a platform to facilitate secure and transparent data sharing in the agri-food sector. DjustConnect was developed by the Flanders Research Institute for Agriculture, Fisheries and Food (ILVO), an independent scientific research institute of the government of Flanders (Belgium). It connects farmers with firms interested in using their data. Firms can request data via DjustConnect, but the platform only delivers the data upon the farmer's explicit consent, maintaining data privacy and security. The platform uses standardised data exchange contracts designed to be consistent with EU data sharing rules as well as the “Code of conduct on agricultural data sharing by contractual agreement” agreed by 11 major stakeholder organisations in EU agriculture (including farm unions, the farm machinery industry, and input suppliers). Analogous to a truck on a highway, DjustConnect securely transports data between parties without viewing or storing it.
The DjustConnect platform can be used by farmers to share any kind of data, including potentially the output of farm level calculation tools. An interesting example is the Klimrek tool, a farm level carbon footprint calculator built explicitly on top of the DjustConnect platform. Farmers can easily share the resulting carbon footprint with processors or retailers.
So far, this discussion of DjustConnect has focused on data sharing downstream from the farmer. However, the platform also makes it easier for farmers to access data upstream, e.g. from input suppliers, smart farm machinery, or government databases. This is discussed in more detail below. Recently, DjustConnect has begun connecting with similar farm data sharing platforms across Europe (Agdatahub in France and Tritom in Finland), to facilitate transnational data exchange. There are several other initiatives underway to facilitate data sharing in agriculture, such as the EU initiative to create a “European data space for agriculture” (https://agridataspace-csa.eu/).
To realise a full “cradle to gate” carbon footprint calculation at farm level requires two types of information. The first type is detailed data on farm activities, to calculate the “on farm” component of the carbon footprint. These serve as inputs for farm level calculation tools. Relevant data here may be stored in, for example, farm management software, farm accounting software, government databases, or data from smart farming equipment. The second type is data on the carbon footprint of purchased inputs (feed, fertiliser, electricity, etc.). Some farm level tools already include an estimate of these emissions based on secondary data. However, ideally primary data would be used here. In both cases, the question is how these data could be accessed by farmers.
Again, carbon footprint calculations are merely one example here of a broader problem (Figure 8.4). Farmers are often asked to report data which requires them to collect, combine and forward data from many different sources, resulting in substantial manual work and room for error. A potential solution is software that automates data collection from various sources and formats it appropriately so it can be easily used to respond to various data requests or to feed into farm level calculation tools. This approach would significantly reduce the manual burden on farmers and improve data security and ownership.
The DjustConnect platform mentioned earlier is one example of such a solution. In addition to facilitating the sharing of farm data with actors downstream from the farm, the platform also allows farmers to access data relevant to their farm from a variety of sources, such as government data on agricultural parcels, lab data on water and soil analyses, or data from smart farming equipment (e.g. on applications of fertiliser). In response to a data request, farmers can therefore easily share relevant data from these sources with other actors. Moreover, the Klimrek farm level calculation tool mentioned earlier was explicitly built on the DjustConnect platform. Farmers can give permission to share relevant data with the tool to calculate their carbon footprint and can separately decide whether to share the resulting carbon footprint with others.1
This is not the only possible model for using supplier data in a farm level calculation tool. For example, the UK-based Farm Carbon Calculator tool already uses primary data on the carbon footprint of fertilisers in its calculations. Farmers can select the specific type of fertiliser use, e.g. YaraVera Urea produced by Yara International, and the tool will use the corresponding product carbon footprint provided by Yara to the Farm Carbon Calculator. In this case, data upstream from the farmer “bypasses” the farmer and is fed directly into the calculation tool.
Source: OECD analysis.
In addition to the initiatives mentioned here, another possible tool for facilitating data sharing and addressing broader interoperability issues in food systems is the adoption of a harmonised data format (Box 8.2).
HESTIA (https://www.hestia.earth/), a joint initiative of Oxford University, WWF, and the Login5 foundation, has developed a harmonised data format which can be used to represent a wide range of agri-environmental data, including data from farms, Life Cycle Assessments, and experimental field trials. The data format includes a glossary of terms, minimum data requirements, and basic validation standards. In addition, HESTIA has created a library of models typically used to quantify environmental impacts in LCA, and has set these up so that they can be run automatically on any data in the HESTIA data format.
In a context of carbon footprint calculations, the HESTIA format could be used by farm level calculation tools to ensure a common way of requesting and representing farm activity data. The format could also be used for storing the output of a farm level calculation. For example, tools could provide farmers with the option of exporting in the HESTIA format not only the final result of the calculation but also all the detailed activity data they provided. This would make it easier for farmers to switch between different tools or recalculate impacts. The HESTIA format was initially built on the openLCA data format for LCA databases, and can hence also be used to store or exchange LCA data.
The potential for a harmonised data format goes beyond that, and conceivably touches on each of the building blocks identified in this report. For example, the calibration and validation of sophisticated science-based models requires experimental field trials. Data from such trials can also be represented in the HESTIA format, potentially creating a large set of training data which could be used by researchers to build better models. As another example, the use of a common data format would greatly facilitate quality assurance, by making it easier for a third party to understand which data was used to generate a carbon footprint calculation. As a third example, the detailed representation of activity data in the HESTIA format could help deal with the need for regular updates of methods and standards. Farmers might for example be able to store their historical farm level data in the HESTIA format, so that they can easily re-calculate historical carbon footprints if new calculation methods are introduced. Moreover, because the HESTIA format was designed to capture a wide range of agri-environmental data consistent with LCA databases and models, the format can be used not only for carbon footprint data but also for other environmental impacts.
The HESTIA format can also be used to unlock existing data from various sources. Valuable agri-environmental research findings are currently hard to access as results are stored in research reports, scientific papers, or databases using different formats and nomenclature. HESTIA is transforming such data into its own format, to allow other researchers to build on previous findings. At the time of writing, data from some 800 peer-reviewed studies and reports had already been digitised in the HESTIA format. This includes most of the studies synthesised in Poore and Nemecek (2018[6]). The HESTIA format has also been used to store data from thousands of farms surveyed by CGIAR, CIRAD, and other international organisations, showing how such information can be brought together in a harmonised way.
Source: Interview with Joseph Poore (University of Oxford/HESTIA).
In addition to the technical aspects discussed so far, data exchange along the supply chain also raises multiple legal and regulatory questions concerning data ownership and security, and possible restrictions on sharing data (Stenzel and Waichman, 2023[7]).
For example, detailed product-level data might be competitively sensitive information, in particular when underlying activity data is included. If a supplier provides this information to a customer, the customer might be able to “reverse engineer” the supplier’s cost structure and use this information to renegotiate pricing. Competitors of the supplier, too, could use this information to uncover trade secrets. If product carbon footprint data is too detailed, it could thus threaten firms’ competitiveness, which in turn would make those firms unwilling to share data in the first place.
A different concern is that indirectly unveiling information on costs could lead to tacit collusion, whereby firms in an industry keep prices above the levels that would otherwise obtain, without any explicit coordination. For this reason, competition law often restricts the exchange of information on pricing and costs.2 If detailed product carbon footprint data would achieve the same effect, exchanging this information might similarly violate competition rules. In July 2024, the French competition authority was asked by organisations in the animal feed industry whether they would be allowed to share information with the goal of creating a harmonised method for calculating environmental footprints. The competition authority allowed this but reminded actors of the need to limit the exchange of sensitive information between competitors (Autorité de la concurrence, 2024[8]).3
One possible solution to both concerns is to limit the level of detail in the product carbon footprint data. For example, rather than sharing a carbon footprint which distinguishes different GHGs (methane, nitrous oxide, etc), the exchange of data could be limited to CO2-equivalent emissions. In addition, if each supply chain actor uses a cradle-to-gate approach and shares only the resulting total (including not only its own emissions but also emissions from upstream in the supply chain), this would go some way towards “masking” the cost structure.
Another potential regulatory issue relates to cross-border data flows. Countries are increasingly implementing data localization measures, which often restrict cross-border data flows (Stenzel and Waichman, 2023[7]; OECD, 2024[9]; Del Giovane, Ferencz and López González, 2023[10]). These might restrict firms’ ability to exchange product carbon footprint data.
Yet another set of issues concerns data governance – including questions of who owns the data, who has access to it, and how the value derived from that data is distributed (Jouanjean et al., 2020[2]). Failing to address these questions is an obstacle to the digital transformation of agriculture, as farmers may be unwilling to share data. Some of the initiatives mentioned above were designed explicitly to address such concerns. OECD work has identified other options to build trust, such as voluntary standards to enhance transparency and fairness in data contracts (Jouanjean et al., 2020[2]).
Generally, then, the smooth exchange of product carbon footprint data across supply chains depends not only on the technical infrastructure, but also on regulatory and governance issues (OECD, 2024[9]). Many of these issues are not specific to food systems but apply to other sectors as well, necessitating close cross-sectoral cooperation. Clear governance frameworks would allow for responsible and secure sharing of product level data.
There are three main points along the food supply chain where data exchange needs to be improved to allow sharing of carbon footprint data. These are data exchange between two large firms (such as between food manufacturers and retailers), between farmers and processors, and between the many sources of information relevant to farmers (e.g. government databases, farm management software, data from smart farming equipment, etc.) and farm level calculation tools. For each of these scenarios, initiatives have emerged to facilitate data exchange.
While many of these initiatives are at an early stage, they provide a powerful “proof of concept”, suggesting that at a purely technical level, the challenge of communicating carbon footprint data along the food supply chain is largely solved. The flow of data between different data sources and software solutions is technically feasible, with necessary APIs developed and often available through open-source formats. An important point of attention now is that various initiatives should collaborate closely and build on each other's work to create compatible systems for data exchange. This includes not just initiatives working on data exchange itself, but also other actors, such as farm level calculation tools, LCA databases, and standard setters such as the GHG Protocol.
Data exchange depends not only on solving technical questions but also regulatory and governance questions. Many of these are not specific to food systems and will require clarity from policymakers.
Finally, as noted, the concept of interoperability is not only relevant for exchanging data along the supply chain, but for ensuring that the various building blocks described in this report can work together smoothly. Efforts to facilitate the flow of data can also bring important benefits in terms of other building blocks.
References
[8] Autorité de la concurrence (2024), Développement durable : L’Autorité publie ses premières orientations informelles en matière de développement durable, https://www.autoritedelaconcurrence.fr/fr/communiques-de-presse/developpement-durable-lautorite-publie-ses-premieres-orientations-informelles.
[10] Del Giovane, C., J. Ferencz and J. López González (2023), “The Nature, Evolution and Potential Implications of Data Localisation Measures”, OECD Trade Policy Papers, No. 278, OECD Publishing, Paris, https://doi.org/10.1787/179f718a-en.
[2] Jouanjean, M. et al. (2020), “Issues around data governance in the digital transformation of agriculture: The farmers’ perspective”, OECD Food, Agriculture and Fisheries Papers No. 146, https://doi.org/10.1787/53ecf2ab-en.
[4] McFadden, J., F. Casalini and J. Antón (2022), “Policies to bolster trust in agricultural digitalisation: Issues note”, OECD Food, Agriculture and Fisheries Papers, No. 175, OECD Publishing, Paris, https://doi.org/10.1787/5a89a749-en.
[5] McFadden, J. et al. (2022), “The digitalisation of agriculture: A literature review and emerging policy issues”, OECD Food, Agriculture and Fisheries Papers, No. 176, OECD Publishing, Paris, https://doi.org/10.1787/285cc27d-en.
[9] OECD (2024), “Towards more accurate, timely, and granular product-level carbon intensity metrics: A scoping note”, Inclusive Forum on Carbon Mitigation Approaches Papers, No. 1, OECD Publishing, Paris, https://doi.org/10.1787/4de3422f-en.
[6] Poore, J. and T. Nemecek (2018), “Reducing food’s environmental impacts through producers and consumers”, Science, Vol. 360/6392, pp. 987-992, https://doi.org/10.1126/science.aaq0216.
[7] Stenzel, A. and I. Waichman (2023), “Supply-chain data sharing for scope 3 emissions”, Npj Climate Action, https://doi.org/10.1038/s44168-023-00032-x.
[1] Verdantix (2024), The Buyer’s Guide to Carbon Management Software 2024, https://www.verdantix.com/report/buyer-s-guide-carbon-management-software-2024.
[3] WBCSD (2022), Partnership for Carbon Transparency (PACT) advances emissions transparency with breakthrough in value chain data exchange, https://www.wbcsd.org/news/pact-advances-emissions-transparency-breakthrough-value-chain-data-exchange/.
← 1. Another possibility is to create interoperability directly between different systems, e.g. through the use of APIs. The EU-funded ATLAS project (https://www.atlas-h2020.eu/) is an example. The initiative developed an open-source system to make digital tools in agriculture interoperable. This includes all data-generating farm equipment (in-field sensors, livestock behaviour analysis, on-board machine processing) as well as existing farm management software. Each of the participating systems continues to operate independently on its own technical infrastructure, but with interconnections and standardised data exchange made possible through the technical specifications provided by the ATLAS project. In contrast with the DjustConnect platform, there is no central “hub”, but data is exchanged peer-to-peer. However, to ensure data quality and reliability, a trusted directory of ATLAS participants oversees the membership in the network. Farmers must also give consent to whom their data is shared with.
← 2. See, for example, the European Commission’s 2023 Guidelines on horizontal co-operation agreements (2023/C 259/01), in particular Chapter 6 on information exchange; also see the US FTC and Department of Justice’s Competitor Collaboration Guidelines (2000), Section 3.34e on the likelihood of anticompetitive information sharing.
← 3. Interestingly, the competition authority also underlined the importance of allowing firms to use firm-specific data rather than industry averages: since firms partly compete on their environmental impacts, allowing only industry averages would amount to an agreement to restrict competition.