6. eDocuments and Green Data (mockups)

As stated in the methodology section, the purpose of the first workshop, with experts from the Nordic countries, was to identify and define the specific datapoints required in the process of climate reporting regarding purchased products (goods and services) and to identify in which eDocument the datapoints are best suited.

Subsequently, the datapoints were clustered and integrated into several versions, to reflect and illustrate the complexity of the datapoints on different levels. The rationale behind it, was for the experts to identify the opportunities, complexity and challenges regarding standardization of the datapoints used in the different levels of the mockups.

The reasoning behind developing a mockup is that it provides:

The mockups therefore serve as a communication tool for the functionalities and opportunities for the recommended datapoints in the respective eDocuments, to stakeholders in the different Nordic countries and the EU. Although, it is important to remember that the final eDocuments’ design is determined by the service providers. Namely, all service providers have their own way to design the eDocument why the main purpose with creating mockups is to provide the stakeholders with a visual image of how it could look like, and guide service providers on how and what datapoints should be implemented. The same relates to some of the functionalities for the setup, as some service providers offer other functions regarding datapoints.

An eDocument can be considered a “container” that holds information related to procurement between a supplier and a customer. For this project, climate data needs to be incorporated into this “container.” However, not all climate data fits into every “container” (eDocument), nor is it expected to by either the supplier or the customer. Therefore, it is important to ensure that the relevant procurement and climate data within the eDocument/container is delivered to the correct recipient and that the recipient knows what data can be expected inside the eDocument. This understanding is crucial for the recipient to automate and efficiently handle the climate data upon its arrival, depending on which eDocument the recipient receives.

Therefore, this project recommends to utilize standardized open and free networks such as Peppol, to facilitate a secure and reliable sharing of eDocuments, in this case “climate data”, and secure that the correct eDocument with the respective climate data are sent to the correct recipient in an understandable, efficient and standardised format.

The mockups were created by grouping the identified datapoints within the relevant eDocument types, to align with specific categories of information.

At the beginning of this project, all eDocuments were considered as optional containers for a datapoint. Nonetheless, later analysis and discussions of the datapoints during the workshops showed that they were best suited to be carried out by the eCatalogue and eInvoice. Some of the new datapoints were deemed relevant to other eDocuments, such as the despatch advice and eReciept, but the eInvoice and eCatalogue has more relevance in carrying the identified datapoints than the others, which is why only mockups for those two were created.

Although the eCatalogue is not widely adopted in the Nordic countries, with the exception of Norway, it was concluded (in collaboration with eDocument experts) that the eCatalogue is best suited to carry all the identified datapoints. This makes it the most comprehensive eDocument for containing green datapoints. The reason behind this is that if other eDocuments were to include the recommended datapoints, they would become too cumbersome and burdensome for their intended functionality.

All datapoints were further clustered and sorted into activity groups to make the datapoints easier to understand and work with. The cluster analysis was based on existing Peppol semantic datatypes where relevant. However, the semantic datatype “Emission Factor” shall be considered as “subgroup” to the group “Additional Items”. The reason for using the "Additional Item Property" group lies in its provision of a standardized XML format for electronic business documents, making it applicable across all types of eDocuments. By doing so, it will also align with the data format used in iXBRL, which is the standard required for sustainability reporting under the CSRD. The XML format allows the data to be machine-readable, enabling the automation of the recommended datapoints to be transferred seamlessly across systems and documents. This ensures consistency and interoperability across different systems and countries. Furthermore, considering that the Additional Item Property group belongs to Universal Business Language (UBL), an ISO standard, the suggested datapoints could potentially be incorporated directly into the EU-Norm.

In addition, the addtional datapoints addressed in this report resides in their existing datagroups, according to Peppol.  

To keep the mockup design familiar and maintain the recognition factor, the mockup of the eCatalogue were inspired by the recognized “Statens og Kommunernes Indkøbsservice” (SKI) catalogue. The SKI-Catalogue refers to a electronic service or product catalogue which is used in connection with contractual agreements between a public institution and a supplier. Further, the datapoints which were selected to be most suitable for the eInvoice were very similar to datapoints identified in another project conducted by the Danish business authority (Erhvervsstyrelsen), where a mockup also was developed for the purpose of testing new green datapoints together with private companies. The eInvoice mockup design was selected from that project.

With the selected design and clustered datapoints, the mockups were created and elaborated upon in workshop 2.

In relation to validating and developing the mockups for the respective eDocuments, it can be concluded from the workshops that the usage of datapoints and regulatory requirements varies within the Nordic countries. This complicates the clustering of the datapoints identified in the specific eDocuments and only amplifies the need for standardization of the datapoints cross-borders and across all eDocuments, considering the scope of the project. In addition to this, there is a need to ensure that the datapoints recommended have uniformed definitions and functions across all eDocuments and countries, to ensure consistency and interoperability. The datapoints and formats developed and used in the mockups therefore need to be compliant with current regulations and requirements across the Nordic countries.

The three levels of mockups, which illustrated the different complexities in terms of the use, maturity and number of datapoints included in each eDocument, cf. the methodology section “Workshop 2”, provided the foundation for the development of the final mockups for the eCatalogue and eInvoice. In collaboration with the experts from Workshop 2, it was concluded that only a few datapoints should be implemented in the respective eDocuments, in order to keep them as simple and non-overwhelming as possible for the users.

This approach of developing mockups was selected to support the goal of the project and to simplify the illustration of how and what green datapoints should be shared. To reach the goal, it is of most importance to understand, as mentioned earlier, the best location of the different datapoints and their functionality, so the eDocuments can provide the necessary value to sustainability reporting for the companies subject to CSRD.

The next sub-section will therefore elaborate on the eDocuments functionality and how the datapoints can be integrated in each eDocument. 

As mentioned earlier, the mockups work as a visualization of how the datapoints can be integrated in different eDocuments. The selected mockups for eInvoice and eCatalogue are presented below.

The datapoints presented does not represent all possible datapoints that can be carried out in the specific eDocuments. Hence, more datapoints can be considered in the future work of incorporating ESG and climate related data in the eDocuments.       
Figure 10 represents a mockup of the eCatalogue, in which the recommended datapoints have been included to support climate reporting. The climate related datapoints have been highlighted with a bold font.

The eCatalogue carries out information about products, goods and services that are up for sale. The intention with an eCatalogue is for the supplier to provide information regarding their product, to secure that a procurement person has all the needed information details available, to make a sustainable decision regarding the company’s procurement needs. The datapoints currently included in an eCatalogue support the financial aspects of decision-making. With the implementation of the recommended datapoints, users will also be able to base their decisions on CO2e emissions and sustainability claims, thereby supporting green electronic-procurement (e-procurement) - especially if these green datapoints are standardized across eDocuments and borders, as outlined in the TO-BE scenario. If standardized and incorporated across eDocuments and borders, it will potentially save resources and time compared to the manual processing of collecting climate data today (cf. the AS-IS scenario). Since the datapoints ideally are standardized and eDocuments are interconnected, the user does not need to repeat the same information in multiple eDocuments (depending on the service provider), assuming that the catalogue is updated with the most applicable and updated information. Hence, in a potential procurement scenario and when a procurement person requests an eDocument, the information will be distributed throughout the entire procurement process – from browsing products or services in an eCatalogue to the monetary transaction has gone through from the buyer to the supplier.

By standardizing the datapoints it enables the supplier’s system to automate the creation of the catalogue and enables the recipients’ receiving system to recognise the received information.

Furthermore, a indicated for the eCatalogue, the eInvoice is another eDocument which also contains product information and is an important building block of the procurement flow. If the procurement process starts with the catalogue and all required information is provided accordingly, the information needed in the eInvoice, which also exist in the catalogue, can be automated. Moreover, figure 11 illustrates the eInvoice mockup developed throughout the workshops. The new datapoints recommended has been highlighted with bold. On top of that, the eInvoice contains additional information that is not included in the eCatalogue, namely "net emissions," which are calculated by multiplying the number of items ordered ("Amount") by the CO2e factor for one item. This is because the eCatalogue does not have information about the quantity of items ordered, and therefore, net emissions cannot be provided in the eCatalogue.

Furthermore, since eDocuments are used differently, in the matter of which eDocument is involved in the process, across the Nordic countries, this project recommends and advocates for the opportunity, which allows for additional sustainability information in the eInvoice. Allowing additional sustainability information in the eInvoice creates an opportunity for suppliers and buyers, not performed through an eCatalogue, to provide additional sustainability information in the eInvoice. However, the responsibilities or burdens for the seller on supplier side in terms of securing that the information is correct in the relation to their ERP and transaction systems, will increase. Figure 11 illustrates a mockup of an eInvoice with the recommended datapoints relevant for reporting climate reporting. In addition to all the above, the procurement flow in terms of document management is already handled by the Peppol Network, today, meaning no further development is needed in this regard (c.f. the TO-BE section). Furthermore, Peppol also ensures that only legal parties can enter the procurement process making the use of eDocuments trustworthy and secure.

During the workshops and analysis of the datapoints and their location, it was discovered that most datapoints were best suited to be incorporated and located in an eCatalogue and only a few datapoints were suited to be carried by other eDocuments.

Additionally, it was discovered that the eCatalogues are not widely used or adopted by business or authorities in most countries, except for Norway who is running a pilot for adopting eCatalogues. With the different frequency or small utilization of the eCatalogues across the Nordic countries makes it more challenging to promote the catalogue as the recommended eDocument carrying the most essential green data for companies to support their sustainability reporting needs. Hence, promoting the eCatalogue as the main repository for green data and as main method to share the datapoints among different organisations can potentially create inefficiencies or discrepancies, not only in exchanging data across the Nordic countries, but also on a national level.

Promoting and making eCatalogue mandatory through legalization would be a potential solution. On the other hand, it could also impose extra burdens on smaller organisations, which is why it is recommended that other eDocuments need to be able to carry some or all of the most significant datapoints, in relation to climate data reporting needs. The most essential part is, however, not which eDocument is used to carry out the significant datapoints, but it is rather to make sure that the datapoints in the specific eDocument are understood correctly, standardized and applicable for both the suppliers’ and recipients’ systems. In relation to this, a network/framework such as Peppol, can facilitates this, but it should be emphasized that the green datapoints are required to be standardised and fixed, so all parties can optimize or change their involved systems and tools accordingly. When the datapoints have been agreed and standardized, both semantically and technically, integration with other systems and tools will be easier and the organisations do not run risks, in terms of them needing to redo the work of integrating the information.