4. TO-BE

4.1 Overview of desired state and processes

The following section, "TO-BE", examines the desired future state of the process for exchanging climate data across borders and systems. The AS-IS and TO-BE scenarios as well as the expected requirements for closing the gap were the subject of discussion during the working group’s workshops.

As in figure 4, figure 7 (the “TO-BE” overview) consists of 4 columns, which illustrate a process flow of how climate data ideally can be exchanged between relevant stakeholders in a supply chain. As mentioned, the aim of this project is to identify ways to ease the burdens associated with sustainability reporting for companies, particularly in exchanging climate data, thereby reducing the cost and challenges linked to the requirements of CSRD.

In the TO-BE scenario, manual processes are replaced by automated ones and standardized, machine-readable data can easily be exchanged via a common (public) IT-infrastructure that interacts directly with corporate IT-systems. Moreover, as elaborated on in the AS-IS section, the CSRD will impact most companies directly or indirectly through their customers, partners, or third-party requirements. This means that most companies (even if not directly subject to CSRD) will be required to exchange data at various levels depending on their role in the supply chain, impact, and size. In effect, this can mean that all companies, regardless of size or economic status, must be able to utilize the common IT infrastructure for exchanging product and climate data.

Figure 7: Illustrates the TO-BE scenario, including standardized climate data and automated data transfer between core IT systems.

In relation to this, there are multiple solutions in the market, which can facilitate the exchange of climate data, but these are, in many cases, at early stages of development or expensive for, small companies to acquire, adopt and maintain. In addition, as a result of the workshops and recommendations from reports (Deloitte & Danish Business Authorities, 2023), it was found that the best way to mitigate the challenges and administrative burdens, identified in the AS-IS section, is to utilize the existing infrastructure and building blocks around electronic invoicing cross-borders (organized by public institutions), to exchange product and climate data throughout supply chains.

Some of the reasons for leveraging existing infrastructures, are:

Proven, common infrastructure is already in place, with the necessary building blocks, and existing user-base.
Current setups are highly standardized and secure, either on public or private networks.
Effective data sharing capabilities that are tried and tested.
Ability to facilitate the necessary communication with companies’ IT-systems (e.g., Enterprise Resource Planning (ERP)-systems).
Opportunities to increase use of automation as data and formats are standardized.

Figure 8: Provides an overview of platforms and standards used in each Nordic country, to facilitate the exchange of electronic invoices, today (European Commission, ND).

As can be seen in figure 8 above, all included countries use Pan-European Public Procurement Online (Peppol) Business Interoperability Specification (BIS) Billing, in some form or other, within their respective platforms. This is evident by the point “use of CIUS and Extensions”. This means that all countries leverage the “Connecting Europe Facility (CEF) eDelivery” infrastructure (European Commission, ND), from a Business to Government (B2G) perspective.

This, in turn, means that the eDelivery infrastructure, together with Peppol, can facilitate a secure and standardized cross-border exchange of eInvoice, eCatalogues and other relevant eDocuments containing the necessary climate data. This, of course, necessitates that all platforms are connected to the relevant access points (European Commission, What is eDelivery, ND). This setup is considered scalable and flexible.

The “TO-BE” figure 7 illustrates each company’s ability to send and receive eInvoices and eCatalogues with relevant climate data, through centralized platforms via their existing core IT systems. It is recommended in the “TO-BE" scenario to enhance standardization and the options for automation by leveraging the open-source CEF eDelivery together with a relevant open free standards, such as the Peppol Network/Framework, which can support both B2G and B2B constellations. The standardization should apply to both the internal systems and databases of suppliers, as well as climate data extracted from external databases, which is meant to be exchanged through eDocuments. Datapoints shall be aligned with ESRS standards, GHG protocol, and the ESRS iXBRL Taxonomy to be able to comply with CSRD. Still, before this digital setup will create value for receivers and suppliers, the exchanged eDocuments must include the datapoints necessary for reporting on climate data. Additional relevant datapoints, which this project has identified and finds necessary to be implemented in the eDocuments, to reach the “TO-BE” scenario, can be assessed in the “The Green Datapoints” section.

In addition to leveraging and integrating climate data across systems, it is recommended to leverage digital bookkeeping systems, which should be able to generate, store and receive eDocuments, especially eInvoices. Therefore, bookkeeping systems should be connected to Peppol and centralized platforms such as the Danish "Nemhandel solution" for handling eDocuments (European Commission, eInvoicing , 2024).

4.2 The Desired Processes of Exchanging Climate Data

To make these points clear, an example of the full process of exchanging eDocuments with relevant ESG data is presented below, in 6 steps:

The supplier collects the necessary data from manufacturers (potentially based on contractual agreements) or suppliers and external ESG databases. Data is stored in the suppliers ERP-system.
The supplier creates the requested eDocument in the procurement or ERP system. The system aligns the eDocuments with Peppol BIS Billing 3.0 standard. If the suppliers’ ERP system does not have the capability to conform with the standard, adjustments within the suppliers ERP system must be made. Alternatively, the supplier can make use of a middleware solution to secure the proper standardization and structure of the information according to the standard (Commission, 2024).
The requested eDocument is automatically transferred via the national platform e.g. the Danish platform “Nemhandel”, which relies on eDelivery’s infrastructure, to the recipients’ (customers’) system. The eDelivery infrastructure supports the open standard Peppol and secures a reliable exchange of the eDocument/data.
After receiving the standardized data, the buyer can directly use the provided ESG data in their metrics without needing to convert, calculate, or structure it to fit a “homemade setup”, as both the supplier and recipient receive and collect the data in the same format and according to a specific standard. This way, the data can be displayed directly in the recipients ESG tool. If the ESG tool is not integrated with the ERP system, the data can be shared through an API, as visualized in figure 7. This setup between the ERP and ESG system can be partly or fully automated, depending on the recipients’ preference (and budget).
The final step, before submitting the integrated report, is to ensure the technical reporting requirements of ESRS XBRL Taxonomy. Therefore, the collected ESG data from the eDocuments should be structured according to the taxonomy. By activating the ESRS XBRL Taxonomy in the eDocuments implies that the data carried by the eDocument is structured accordingly, to meet the specific requirements of the taxonomy. All data carried by the eDocuments is therefore e.g., in an XML format and tagged accordingly, which ensures interoperability with other reporting systems that the “buyer” might have.
Finally, the recipient has what they need to comply with the requirements for publishing an integrated report to an auditing firm, the public, and regulatory authorities in a standardized, machine-readable format, making the reports transparent, comparable, and consistent.

Given the desired state outlined in the text above, there will be challenges and risks in convincing the broader market to adopt the proposed state. These challenges will be elaborated on in the "Challenges and Risks" section.

Furthermore, the first step of the TO-BE scenario, which this project is focusing on, is to identify how relevant data for climate reporting needs can be exchanged in a standardized format, and how the standardized datapoints can be integrated in current setups. This will be elaborated on in the following section.