All About Invoice Types and Requirements in Norway

In Norway electronic invoices are used, so-called XML files in which the invoice information is included.

It is not about PDF files, because they cannot be read directly into an accounting package.
To be able to export and import XML files into invoice software, it must be clear which information is in the XML file is represented.

1. The semantic standard of the basic electronic invoice) defines around 160 basic information elements that are sufficient for the majority of invoices. The representation of those elements in XML is described in CEN / TS 16931-2 and CEN / TS 16931-3 (the implementation of the semantic standard in the UBL and UN / CEFACT syntax, respectively). How electronic invoices are to be sent over an internet connection can be found in CEN / TR 16931-4. CEN / TR 16931-5, finally, describes a method that can be used by specific sectors to expand the set of information elements with sector-specific elements.
2. The standard will be published by CEN and are available on the NEN website. There it can be downloaded for a fee of approximately € 150 to € 250. Then governments, companies and service providers can start with the implementation. The obligation for all contracting authorities to accept electronic invoices in accordance with the standards will start at the end of 2018. So time is tight. Fortunately, around 90% of the invoice elements correspond to existing and widely implemented electronic invoices: UBL-OHNL (the UBL syntax as accepted by Digi poort) and SIUBL (the UBL syntax in the simpler invoicing network). SI specifications will comply with EN and remain available for free (in that sense it is not necessary to purchase the standard). For many parties, implementing the standards means more a migration than a new implementation
3. The standards will apply to the invoice to governments. Experience abroad also shows that companies that have implemented the standards for government clients will also use these for mutual invoicing. Much standard accounting software will have to be made suitable for this. Service providers will offer to convert invoices that have been drawn up in accordance with the standards to UBL-OHNL or SI-UBL, vice versa. Users (companies and governments) do not have to interfere with the implementation themselves. They have to ensure that their software developers and service providers stay on top.
4. Information elements for your billing process. In some cases, this is not the case, for example, if you now work with collective invoices. Aggregate invoices, which refer to all deliveries in a period, must be split per delivery. This has several advantages: checking becomes easier and in the event of a dispute about a delivery, the payment of all other deliveries is not suspended. Periodic invoicing with continuous deliveries (for example electricity or subscriptions) is possible.
5. Specific product or process information that is required in certain sectors can be included in free text fields or in a sector extension. In Norway, the recipient of invoices is bound by the legislation on retention periods: you must make agreements about this with your service provider.
6. For some sectors, specific information is missing in the basic invoice. Although this information can be included as a free text, it cannot be processed automatically. An alternative is to develop a sector extension: an extension of the basic invoice with those specific information elements. CEN / TR 16931-5 describes how to do that. An invoice that contains an extension is identified as such. Such extensions are currently being developed for the temporary employment sector, for the energy and telecom sector and for construction. However, customers are not required to implement such an extension. Suppliers will, therefore, have to keep in their systems in which customers receive a basic invoice (with the specific information in free text) and for which customers that information can be structurally included in the extension. They can also leave that to a service provider. It is therefore strongly recommended to (also) implement the standard as it is published, possibly with a nationally agreed restriction (CIUS). If you use an extension in your sector, you must bear in mind that the release calendars of the basic invoice and the extension may vary.

As a recipient of invoices you must go through the following steps:

• Check whether your software is suitable for processing basic electronic invoices;
• Analyze your received invoices and make agreements with your suppliers to split collective invoices;
• Represent specific information in the correct manner;
• Target your invoice verification process accordingly;
• Contract a service provider so that you;
• Can receive electronic invoices via the Simpler invoicing network;
• Can receive electronic invoices in accordance with both syntaxes (UBL and UN / CEFACT).

As the sender of invoices, you must go through the following steps:

• Check whether your software is suitable for creating basic electronic invoices;
• Analyze your invoices and make them suitable as basic invoices;
• Split collective invoices o represent specific information appropriately;
• Target your invoicing process accordingly in;
• Contract a service provider so that you;
• Can send electronic invoices via the Simpler invoicing network;
• Test the invoice creation and shipping process;
• Inform your customers that you want to send invoices electronically from now on;
• As a service provider, you make your service suitable for processing electronic basic invoices and you connect on the Simpler invoicing network.