NemHandel eDelivery – what do we know at this point? And how should you proceed?
NemHandel has transitioned to the new eDelivery-based infrastructure as a method for exchanging OIOUBL documents. Here, we provide a comprehensive technical and commercial overview of eDelivery.
NemHandel eDelivery – in short
In order to better align with the Peppol standard, the Danish Business Authority (Erhvervsstyrelsen) will upgrade OIOUBL to version 3. This upgrade will follow the same concept as Peppol, known as eDelivery or the four corner-model.
In May 2023, the Danish Business Authority (Erhvervsstyrelsen) released the reference implementation, which represents Denmark’s version of the four-corner model. The deadline to transition to NemHandel eDelivery was October 31, 2023. During the transition period, the existing method of exchange, OIORASP, can still be used until April 2024. In this transitional phase, mySupply operates a dual setup, supporting both protocols, as deliveries using OIORASP remain possible after October 31, 2023. We thus check both networks before dispatch to ensure that documents reach the correct recipient.
The NemHandel reference client, commonly used for sending, expired on October 31, 2023. Therefore, users intending to send electronic OIOUBL invoices need to find an operator that support eDelivery.
The transition to NemHandel eDelivery is a major release, meaning that backward compatibility is broken. Consequently, it is no longer possible to send in previous formats, and all documents applicable to the Accounting Law must be updated.
The four corner-model – in short
The Danish NemHandel eDelivery model is based on the four corner-model inspired by Peppol.
Corner 1 is the sender.
Corner 2 is sender’s operator.
Corner 3 is recipient’s operator.
Corner 4 is recipient.
When Corner 1 needs to send a document to Corner 4, Corner 2 performs a search in the Nemhandel registry. Corner 3 then receives on behalf of Corner 4, which receieves the document in their finance system.
The model provides enhanced security as it operates on the AS4 transport protocol. As mentioned, the model draws inspiration from the Peppol network, which is an open network where the sender doesn’t necessarily need to know the recipient’s service provider. Service providers perform searches in the network to identify the correct recipient.
Example:
You can compare eDelivery making a phone call. When we pick up our phone and make a call, we enter the number, and telecom operators ensure that the call reaches the recipient. Similarly, in eDelivery, Corner 1 calls Corner 4, but before that happens, there is a search and exchange between two operators to ensure that the call goes through.
Migration plan
The Danish Business Authority (Erhvervsstyrelsen) has made the following migration plan during the transition to eDelivery.
OIORASP will continue as a standalone protocol until October 31, 2023, after which it is required that the recipient is at least registered in the eDelivery network. However, OIORASP can still be used until its end-of-life in November 2024.
All recipients must have their profiles, as they exist in OIORASP, registered in eDelivery.
When a new operator is implementing NemHandel, the requirement is solely for eDelivery and not for a dual setup (OIORASP and eDelivery simultaneously). This applies only to existing operators.
Which document types will come?
As stated in the article ”Accounting Law – what do we know? And how should you respond?” the rollout of NemHandel eDelivery introduces additional specific document requirements that standard accounting systems must be able to meet.
The system must be able to:
- send and receive OIOUBL 3 invoice and credit note
- send an Application response when receiving an OIOUBL invoice
- send and receieve Peppol invoice and credit note
- send Message Level response when receieving a Peppol invoice
- send Invoice Response when receiving a Peppol invoice
There are two types of receipts – a technical one and a commercial one. A technical receipt (Message Level Response) means being able to reject an invoice if it fundamentally does not comply with the rule set. A commercial receipt (Invoice Response) is an indication of whether you intend to pay the invoice or not. For instance, it could be a rejection if the price is incorrect.
Application Response is also divided into a technical receipt and what is referred to as an invoice response.
Although there is a requirement for standard accounting systems to be able to send a receipt, there is not an immediate requirement to do so.
The invoice sender must be registered to receive an Application Response for technical rejections. However, it is not a requirement for the invoice sender to be registered to receive an Application Response for business-related rejections. But it is expected.
OIOUBL 3 document packages
When talking about OIOUBL 3 document packages, there are documents that are directly covered by the regulation (invoice and credit note), but there are also documents that are not covered by the Accounting Law but are a derived consequence thereof.
Package 1 is at this stage the only package we are certain of. The other packages are our best guess as to which documents may be included in OIOUBL 3.
With the introduction of Package 1, there is a proposal for mandatory registration of invoice responses, which is a registration of the invoice sender for receiving commercial electronic responses. There is an emphasis on greater alignment with the Peppol OIOUBL 3 documents.
One of the document types in Package 1 is product data sheet. To our knowledge, this is a sub-catalog where supplier-specific information is omitted, but the master data relevant to describing products is included. The reason for introducing this document type may be due to the increased focus on circular economy, green economy, and the heightened requirements for ESG reporting, which will apply to all major companies from 2024.
| Document package | Document type |
| Package 1 | |
| Invoice | |
| Credit note | |
| Invoice response | |
| Application message (Technical) | |
| Product data sheet | |
| Varemodtagelseskvittering | |
| Despatch advice | |
| Order package | |
| Order | |
| Simple order confirmation | |
| Order confirmation | |
| Order changes | |
| Order cancellation | |
| Order agreement | |
| Catalogue package | |
| Catalouge | |
| Catalogue inquiry | |
| Catalogue item update | |
| Catalogue prices | |
| Catalogue response | |
| PunchOut |
It has also been announced that there will be upcoming releases for the document types we know today. This includes goods receipt confirmation, order package, and catalog packages. However, we do not have a date for this yet.
We have also been informed that UTS (supply specification) and associated reminders, that exist today, will continue even though there is no equivalent in Peppol. At this time, we do not know whether they will continue unchanged or what the procedure will be.
Package 1 – timeline
From November 2023, there will be the first consultation round for the overall design principles and changes. The initial release of the document package is scheduled for March 2024, and the final release will be published in April 2024. There will be a short deadline for implementing the document package, which mandates support for OIOUBL 3 in NemHandel from May 2024.
From May to November 2024, the existing OIOUBL version will be phased out, and from November, it will no longer be possible to exchange the existing OIOUBL invoice via NemHandel.
| Consultation round 1 Overall design principles and changes | November 2023 |
| Release candidate Release of the first document package | March 2024 |
| Final release Final release of the first document package | April 2024 |
| Support for OIOUBL 3 Mandatory support for OIOUBL 3 amongst the NemHandel participants | May 2024 |
| End-of-life OIOUBL 1.13 End-of-life for the current OIOUBL version | November 2024 |
mySupply is ready to help
We are always ready to help manage your electronic end-to-end document management process. We have all the latest knowledge and participate in all major committees, ensuring we are at the forefront of new guidelines.
For all customers, we handle everything related to eDelivery. We ensure that customers do not feel the transition of infrastructure. In the rollout of new document types, we conduct a gap analysis to stay ahead of differences.
For customers where we perform conversions to and from OIOUBL 2.1, we update to OIOUBL 3 to comply with new formats. We also continuously handle all other OIOUBL 3 documents that are not required in accounting systems
For non-existing customers, we are always ready to discuss your current solution, ensuring that you are prepared for eDelivery
Feel free to contact us for more information.
