7. Data Integration, Automation and Technical Frameworks

The following section investigates how the identified datapoints in the “The Green Data Points” section can be integrated in current digital setups. Furthermore, considerations regarding what is needed to integrate the identified datapoints are explored. Also, broad considerations around how the datapoints potentially can be integrated in commonly used tools, are considered as well.

As depicted on in the key-objective section, this project explores how Nordic cross-border collaboration can reduce administrative burdens and facilitate green procurement through improved climate data exchange. To reach the objective of this project, solutions on how to integrate the climate related datapoints need to be considered. This section provides reflections and considerations of what relevant service providers of eDocuments should consider and be aware of when integrating the climate-related datapoints.

7.1 Technical Requirements for Climate Data Integration

To succeed with the integration of the identified datapoints from the “The Green Datapoints” section, some groundwork needs to be covered. Groundwork in this case refers to securing the datapoints are correctly defined accordingly to the Peppol standard and are recognized in the sending system. A sending system refers to a system, which is responsible for generating and preparing the datapoints within an eDocument. This can for example be a dedicated ERP system, middleware software or integrations layers, which facilitates this. In addition to the sending system and as referenced in the TO-BE scenario, the sending system shall ensure the data is generated in the correct data format, ensure compliance with Peppol, OIOUBL and other local/national relevant standards, so all Nordic countries can utilize the datapoints. In this project, the datapoints have received a considerable amount of attention in the workshops. The reason for this is that the datapoints form the foundation for the information needed for the receiver, buyers, and ESG managers to report on scope 3, category 1 and to meet the requirements of CSRD, within ESRS E1. The datapoints aim to ensure, as mentioned throughout the report, trustworthiness, reliability and validity within the ESG report and supports general reporting activities. Nonetheless, information and further investigation of the datapoints in relation to their technical specifications are still needed, to ensure their feasibility and correct level of readiness for integration, before specific integration guidelines for the service providers can be developed. In response to that, the datapoints needs to be evaluated in terms of assessing their quality, application and availability (matureness) in general, and investigate how they align and if they are compatible with the CSRD, ESRS and Peppol Standard. Although, efforts have been made to define the semantic definitions for the datapoints (see appendix 3), the semantic definition of the datapoints originating from this project should be considered as a first draft. Therefore, it is recommended to test the datapoints together with companies subject to CSRD and technical experts.

To ensure compatibility of selected datapoints across Nordic countries, it requires all parties involved to agree upon their technical and semantic definitions and specifications, before being able to standardize them correctly. Standardizing the datapoints require that the metadata for each datapoint is agreed upon, by all parties involved. This includes ensuring technical naming, linking related datapoints, and defining fields clearly. This should be in place before being able to do a meaningful integration of the datapoints. Furthermore, another argument to support the importance of standardizing the identified datapoints, is that the datapoints are to be used or can be used in calculations. Lack of standardization leads to inaccuracies, inconsistencies, and increased manual work for ESG stakeholders, as depicted on in the AS-IS and TO-BE sections.

Additionally, the technical definitions need to reflect and declare the characteristics of the datapoints’, the format and length restrictions of the field. This can be done by for example comparing the semantic definition of the datapoints with existing ones in both suppliers and recipients’ systems. This aspect is particularly important to avoid any confusion or inaccuracies. For example, a datapoint like “CO2e factor in kg per unit sold” could be mistaken for a datapoint presenting the CO2e factor for one base unit. These reflections highlight the need for technical guidelines to ensure consistent data integration, processing and how to utilize them correct.

7.2 Technical Guidelines

With the above reflections in mind of what is needed regarding standardizing the datapoints and why, the next part of this section will focus on what potential guidelines shall consider, address and entail (high-level reflections).

First, it is important to take into consideration that large, medium and small enterprises use different levels of systems/tools to manage the datapoints, which creates an incentive/argument for the guidelines to be created without being dependent on a specific system or tool.

The guidelines need to address and present the following:

Align guidelines with calculation methods outlined in the GHG protocol.
How to handle and utilize datapoints.
Address system restrictions, such as software limitations or data accessibility issues. When the datapoints are identified in suppliers’ system eventual restrictions and access methods need to be identified and handled if necessary.
How to update datapoints and evaluate current processes, potential risks, and system dependencies to prevent any unintended overwriting of critical data. If not updated and evaluated properly, the data quality can easily become error-full leading to incorrect or error-full data being sent and received between the parties.
How to choose and navigate the landscape of open and free standards, such as the Peppol Framework. For example, Peppol provides a simple architecture based on a four connections model, which allows the sender and receiver to exchange information without creating a unique point-to-point connection or use the same service provider. Nonetheless, for parties to use an open and free standard with a simple architecture, such as the Peppol Framework, it is required that all parties use a service provider that adheres to the ISO/IEC 19845 standard.
How to secure the datapoints and ensure their conformity with open and free standards, such as the Peppol Framework. This should always be done, even if the e-procurement partners are manually copying the information instead of using an automated process. Initially if doing so, helps minimize the manual workload for the receiving e-procurement partner.

With respect to the last bullet point concerning choosing and navigating the landscape of “open and free standards”, it is worth considering that the open and free standard ”Peppol Framework” provides the methodology and technical specifications, as well as an agreement framework (Peppol’s three pillars) to send eDocuments between e-procurement partners. By selecting a service provider who adheres to the ISO/IEC 19845 standard, hence the Peppol Network, the e-procurement partners will also have sufficient support regarding complying with country specific regulations. Therefore, the e-procurement partners do not need to worry about compliance issues, as the chosen service provider will ensure that the required information is sent to the recipient's system(s) in the proper format, compliant with the specific requirements of each country. Additionally, depending on the chosen service provider, all Peppol-standardized datapoints are supported in the solution. This means that even if a datapoint is not required in the supplier's country, it can still be automatically included for trading partners in countries where it is mandatory due to specific regulations.

7.3 Recommendations

Considering the reflections and considerations made in the above section, it is recommended to leverage existing infrastructures, such as Peppol, to simplify compliance with CSRD and streamline green data sharing. Using existing infrastructures and open and free standards will mitigate the current challenges as reflected in the AS-IS Scenario and ease the burdens of sharing green data. Hence, it will mitigate manual work such as structuring and converting data, to the correct format, following the correct standard. Furthermore, it is recommended that guidelines are developed with the purpose of helping service providers to integrate the new datapoints correctly, comprising how to ensure the conformity, update datapoints, how to use the datapoints according the GHG protocol etc.