EHF Invoice and Creditnote

The government white paper labeled “St.Meld. nr. 36 (2008-2009) Det gode innkjøp” (The good procurement), states among other things:

The previous «Ministry of Government Administration, Reform and Church Affairs» (FAD) considered use of open standards as a vital means to build a well-functioning public administration, with good internal collaboration and a high level of service for both inhabitants and businesses.

The purpose of this document is to describe a common format for invoice messages in the Norwegian market, and to facilitate an efficient implementation and increased use of electronic collaboration regarding the invoicing process based on this format.

The target audience for this implementation guide is both accounting and IT professionals in organizations aiming at performing the invoicing process completely or partially electronic. That means issuing an invoice, a credit note and a reminder. This document may also benefit system suppliers, ERP suppliers and message brokers.

This document consists of the following chapters and contents:

This version is valid from 10. December 2019, and is mandatory from the same date.

Version 2.0.17 is a revision of EHF Invoice and Creditnote 2.0, and this version is backwards compatible to EHF Invoice and Creditnote 2.0. This means that any instance documents valid towards EHF Invoice and Creditnote 2.0 is also valid in version 2.0.17. Please note that valid here reflects the validity against the implementation guide of EHF Invoice and Creditnote 2.0, as this is the normative reference.

EHF is an anagram of the Norwegian expression «Elektronisk handelsformat» (Electronic Commerce Format).

EHF is based on the work performed by CEN BII. This is further adjusted to comply with the Norwegian accounting regulations and current practices for the different business processes in the Norwegian market. Difi pursues the goal to cover the full trading process using EHF documents, both before and after awarding (signing of a contract).

Documents, from the tender catalogue to the credit note will be gathered under the EHF umbrella. During 2013 Difi will prepare for the use of EHF formats in what is known as the post award process, i.e. the part of the business process that starts when a supplier and a customer have signed a contract.

By using the EHF documents the collaboration between the supplier and the customer will be predictable. Elements from the tender Catalogue will be re-used in the Order, and elements from the Order will be re-used in the Invoice. This leads to a holistic use of all the documents under the EHF umbrella.

Difi has chosen to use CEN BII as a base for the EHF formats and the Universal Business Language (UBL) as a foundation for the implemented syntax. Both EHF and UBL are open standards and as such not liable to any licensing fees or royalties.

EHF is managed and maintained by Difi.

The different EHF formats mentioned above contain a number of common information elements (supplier, customer, item etc.). It is important to preserve consistency in those common information elements, and that means that elements with identical content are declared in the same way and as far as possible given the same element tag name.

EHF invoicing formats will for instance re-use elements from the Catalogue and Order to ensure consistency between the messages and to make sure that the information from the business transactions are reflected in the invoicing documents. This makes it possible to implement an efficient and automated control of the invoice and the originating transactions.

The use of empty elements is prohibited in UBL, which is the base for EHF. The reason for this, is that empty elements may be interpreted to have a certain meaning, it could mean that the information was not available at the time of sending as an example. In addition, numeric- and date elements have requirements that would generate validation errors if they were empty.

Open PEPPOL Transport Infrastructure will provide an efficient use and transport of the EHF formats. The objective is to make it easy for parties in different countries to do cross-border trade. Experience shows that it is easy to implement electronic messaging in Norway, because most of the service providers use standard processes.

It must be noted that every document scheduled for this infrastructure must be validated with no fatal errors by Difi’s own validation service. This is likely to be done by the document issuer or by the service provider on behalf of the document issuer.

According to circular P-10/2012 FAD recommends all central government agencies to use this transport infrastructure.

In line with the underlying methodology for the EHF formats (cf. CEN BII) the electronic messages included in a specific format will be exchanged between the parties as a part of an electronic collaboration process – a profile.

CEN BII has defined a profile as “A specification of how one or more Business Processes are executed by specifying the business rules governing its business collaborations and the information content (data model) of the electronic business transactions exchanged.”

If possible, the EHF is using profiles prepared by BII or PEPPOL. Examples of relevant profiles are:

The messages being exchanged within a profile are customized to comply with the requirements given for that particular business document.

A CustomizationID is used to identify the business rules that apply to the document in question, i.e. the whole set of business rules the document issuer founded the document on.

The example CustomizationID below indicates that the contents of the current message is based on business rules determined by BII (urn:www.cenbii.eu:transaction:biitrns010:ver2.0), extended, customized and clarified by PEPPOL (urn:www.peppol.eu:bis:peppol5a:ver2.0) and further extended, customized and clarified in this implementation guide regarding the Norwegian businesses (urn:www.difi.no:ehf:faktura:ver2.0).

The combination of the ELMA registration and the implementation guides referred to in that context eliminates the need for any formal collaboration agreement between the sender and the receiver. The ELMA registration verifies that an actor has declared the ability and the commitment to receive business documents composed according to the specific implementation guide, and any party is free to send the business document to this actor.

Exchanging Catalogue and Order requires no registration in ELMA, and actors are advised to include the use of electronic messages in the purchase contract or to supply an collaboration agreement as an attachment, in order to link the electronic collaboration with the mercantile regulations and thus achieve a regularly revision of the electronic process.

Difi claims the right to exchange the current format with a new one as and when needed. If so, Difi will inform the public via the web site and their registered users via e-mail.

Difi manages the formats in this way:

The electronic messages described in this implementation guide are Invoice and Credit note. The messages make it possible for the supplier to issue an invoice, send it to the customer and receive the agreed payment.

The diagram below shows the roles involved in the invoicing process. In EHF, the customer and invoice recipient is the same entity, as is the supplier and the invoice issuer.

All messages contains ProfileID and CustomizationID. ProfileID identifies what business process a given message is part of, and CustomizationID identifies the kind of message and the rules applied.

Profiles are connected to one business process, and may contain multiple document types. Valid document instances must contain corresponding ProfileID and CustomizationID.

The listing below are related document types connected to the role of receiver in the conversation. Registration in ELMA describes the receivers capabilities.

This version of EHF Invoice and Creditnote is based on UBL XML schema version 2.1. Previous versions of the EHF Invoice and Creditnote used UBL version 2.0.

The invoicing process includes issuing and sending the Invoice and the Credit note from the Supplier to the Customer and the reception and handling of the same at the customer’s site.

The invoicing process is shown in this work flow: 1. A Supplier issues and sends an EHF Invoice to a Customer. The invoice refers to one or more orders and a specification of delivered goods and services. An invoice may also refer to a contract or a frame agreement. The invoice may specify articles (goods and services) with article number or article description. 1. The Customer receives the invoice and processes it in the invoice control system leading to one of the following results: 1. The Customer fully approves the invoice, posts it in the accounting system and passes it on to be paid. 1. The Customer completely rejects the invoice, contacts the Supplier and requests a Credit note. 1. The Customer disputes parts of the invoice, contacts the Supplier and requests a Credit note and a new Invoice.

The diagram below shows the invoicing process with the use of EHF invoice messages. This process is based on the profile 5 in CENBII (BII05 - Billing), which assumes that both the invoice and the credit note are exchanged electronically. The profile also includes the message type «Corrective invoice», but this is not used in Norway. If the customer disputes the invoice, the supplier must issue a credit note and a new invoice.

Negative invoice is an invoice where the total invoiced amount is less than zero. This version of EHF Invoice accepts that, but Difi’s validation service will give a warning message. Earlier it gave an error message.

A negative invoice must not be confused with a credit note. A negative invoice invoices the sale of new goods or services. A credit note resets or repays all or part of a previously received invoice.

Financial advance is not previously invoiced, ref. «Skattedirektoratets uttalelse av 23.05.07 Finansielle forskudd eller forskuddsfakturering og GBS 13 Forskuddsfakturering.», in English: «Directorate of taxes, statement 23.05.2007: Financial advance or advance billing and GBS13 Advance billing». This means that when the goods or services are delivered an invoice must be issued according to the rules in the Accounting regulations § 5-1 and § 5-2 even if the economic considerations already are levied through financial advance. The invoice settles the financial advance. If the economic considerations exceed the financial advance, the buyer must pay the excessive amount. If the economic considerations are lower than the financial advance, a negative invoice occurs, and the seller must repay the negative invoice amount.

In cases of financial advance or on account invoicing a credit note must be issued following the rules of the "Accounting regulations § 5-2-8" and "GBS 1 Issuing a credit note" to settle the previous invoice (if the specified considerations were too high).

The following roles may be specified in the format. The same actor may play more than one role depending on the handling routine.

Price given for an invoice line is price excluded any allowances or charges on line level, but allowances and charges on price-level is included in the price. See further details on allowance and charge in chapter 6.2.

The customer contact, known as Your ref or “ Deres ref” in Norwegian, is mandatory. The element is used for the reference of who ordered the products/services. Example being the name of the person ordering, employee number or a code identifying this person or department/group. Your ref is often used for internal routing at recipient, and hence it is important to fill this element with the correct values according to the need of the recipient. If this information is not relevant for the invoice, the value “NA” (Not Applicable) should be used, this should be agreed with invoice recipient. Information and is specified in the element AccountingCustomerParty/Party/Contact/ID.

The supplier contact, known as “Vår ref” in Norwegian, is recommended in EHF. Name/reference/identificator of the person that can answer any questions regarding the invoice/credit note. Information and is specified in the element AccountingSupplierParty/Party/Contact/ID.

VAT categories used in Norway as of july 1, 2013 are specified in the table below. Use of other VAT categories than those specified below leads to rejection of the XML instance document during validation.

The VAT category must be specified on line level. On the header level both the VAT rate and the category must be specified. In addition the basis for calculating the VAT value, the VAT value itself and the total amount for VAT must be specified on the header level.

Cf. chapter 6.3.3.3 for an XML example regarding VAT.

If special taxes/charges are applicable, each one must be specified on an ordinary invoice line. The only valid tax scheme identifier is «VAT» (code list UN/ECE 5153 subset). If there is no separate line for special tax, the assumption is that the special tax is included in the price.

The customer will issue an order with a unique order number. This unique customer order number must be supplied as the order reference on the invoice.

If the order reference is specified on the header level (OrderReference), the assumption is that the invoice is based on one order only. If order reference is stated at header level, the order reference element on line level is used to state the order line numbers.

If the invoice is based on more than one order, the order number should be concatenated with the order line number on each invoice line in this way “order number##order line number”. Example: The exact syntax should be agreed upon by the two parties.

If reference numbers other than order- or contract reference (see chapter 6.8) is needed, the additional document references should be used (see chapter 6.11).

When no order reference is provided must the Order Reference element be removed entirely to clearly communicate no order reference was provided. When order reference "NA" is provided is this a actual reference.

To reference or match an invoice to a signed purchase contract, the contract number could be specified like this:

If other references than Order number (ref. ch. 6.7) and Contract number is needed, the element Additional document reference (ref. ch. 6.11) may be used.

If the customer wants to automatically post the costs, the accounting information must be transferred to the supplier before or with the order. The supplier should then return the accounting information on the invoice line level.

The accounting cost element is just a simple text element. Posting in accounts payable and general ledger often requires several «dimensions». A structured solution regarding content in the accounting cost string has been demanded from a number of stakeholders.

Below you will a proposal regarding content in the account cost string. The structure of the string will be as follows:

Content in general: <Kontoplan>;Konto=<Accountno>;Avd=<Department>;Prod=<Product>;Prosj=<Project>;MVAkode=<VAT code in GL>;Dim6=<Free to use as needed>;Dim7=<Free to use as needed>

Chart of Accounts must always be the first element in the string. No requirements regarding sequence of the other elements. If norwegian standard Chart of Accounts is used by the invoice receiver, then NS4102 must be the leftmost content of the account cost string. For receivers using standard agricultural Chart of Accounts, version 1, the text ‘Landbruk_kontostreng_v01’ must the leftmost content of the accounting cost string. Any other posting requirements than account number, department, product, project and VAT code, may be implemented by using the Dim6 and Dim7 fields. In agricultural context there is a need for a field called ‘driftsgreinkode’. Dim6 may be used in this case.

Both the invoice and the credit note formats support the use of attachments. The element to hold the attachment information can be repeated multiple times (AdditionalDocumentReference) thus allowing multiple attachments.

Attachments may be used to provide additional information to support the claim represented by the invoice. Additional information can be time sheets, receipts, airfare tickets etc. Attachments are not meant for transferring a pdf-version of the invoice/creditnote. If, however, the “pdf-version” is supplied as an attachment, the element “DocumentType” must specify “Commercial invoice” for an invoice and “Credit note” for a creditnote. Attachments can also be graphs and images. The attachment could be sent as a binary object or as an external address to the object’s storage location (URI).

It is recommended to send additional information included in the format (message) and not as an external address (URI), since many businesses are restricted from pursuing external links. If external link is used, the buyer is committed to download the information contained in the link and store it with reference to the invoice/creditnote document. Such a solution requires according to the Norwegian tax authorities (Skattedirektoratet), an agreement between the parties. Thus use of external links are not recommended.

Additional recommendations:

The need to distribute information not included in the EHF format arises from time to time. To satisfy this need, the element AdditionalDocumentReference is used. As mentioned above, this element can be repeated multiple times. Examples of information to go into this element are packing lists and the supplier’s order number. Important to notice, there is no code list for this element, and the interactive parties must agree on syntaxes and semantics.

EHF Invoice 2.0 facilitates invoicing of consumers (B2C). This means that invoice issuers may use the EHF 2.0 format both for business customers and consumers.

Transmission of an invoice to a consumer from an invoice issuer is performed by use of either secure digital post or the consumers «netbank» assuming that the issuer has an agreement.

E-invoice reference must be placed in the ID element of Additional DocumentReference. DocumentType must be set to « elektroniskB2Cfaktura». If secure digital post is used, the personal identity number (fødselsnummer) should be filled in the ID element.

The buyer’s legal entity is not mandatory when “elektroniskB2Cfaktura” is given as documenttype.

In the consumers market automatic debit (Avtalegiro) is widespread as payment method.

Delivery details may be given at document (Mandatory) or line level (Optional).

Delivery date should allways be sent, exept for delivery by forwarder, post or the like. See further details in The bookkeeping regulation (bokføringsforskriften) § 5-1-4.

Place of delivery is recommended, and should be sent unless the place of delivery does not affect the ability to ensure the correctness of the invoice. Examples of this can be invoices covering services like investigations and legal assistance. See also NOU 2002:20 point 9.4.1.4.

The delivery element contains an identifer (DeliveryLocation/ID) which may be used if the place of delivery is defined through an identifier. Examples are GLN (Global Location Number) or GSRN (Global Service Relationship Number) both issued by GS1. GSRN is used in the norwegian market for identifying measuring points in the energy sector. Ref. appendix 7.

PartyTaxScheme under AccountingSupplierParty is an optional element, but according to EU COUNCIL DIRECTIVE 2001/115/ the PartyTaxScheme must be specified if the invoice or the credit note have a VAT total. That means that the element almost always has to be specified. The specification should be the supplier party’s organization number followed by the letters MVA, like this:

If both BBAN (Basic Bank Account Number) and IBAN (International Bank Account Number) are available when the XML instance document is generated, the sequence should be BBAN first and IBAN last. If account is Norwegian, BBAN should allways be submitted.

Endpoint ID is used for specifying the electronic addresses issuers and receivers are using in their message collaboration. Electronic addresses for norwegian participants in the PEPPOL infrastructure are the legal registration ID of the company and must be registered in ELMA.

Legal registration ID (Company ID) is used for identifying the legal entity the invoice is linked to, ie. the legal entity responsible for the obligation.

Small businesses normally have just one legal registration ID. For these the endpoint ID and the legal registration ID will be compliant.

Major businesses may have several legal registration IDs based on for instance location. If processing of incoming invoices are centralized for all legal entities within the business, the content of the endpoint ID and legal registration ID (Company ID) may be different. In this context it is recommended that all legal entities are registrered in ELMA. Dissemination to a centralized invoice processing function is implemented as part of the registration by the actual accesspoint. (Several invoice receivers share the same endpointID).

The alternative to the solution above is to handle the endpointID as an «invoice receiver address». This means that the invoice receiver manually has to inform the trading partners of the endpointID to use in the message collaboration.

Tax representative party for the seller is relevant for sellers delivering goods and services in Norway without having a permanent establishment in Norway. In such cases the name and address of the tax representative must be included in the invoice.

The receivers invoice handling system must releate to all elements on an invoice (including all optional elements) and at least display all filled elements in the control and verification process of the invoice. Dynamic display of invoice and creditnote based on XML instance documents will be developed by Difi.

Stages in the validation process:

The combination of ProfileID and CustomizationID in an XML document defines the validation rules applied to the document.

CustomizationID may be extended with more elements for specific trade or business validation rules.

Difi’s Validator is an application program used to validate EHF XML-files.

Further information can be found here: https://vefa.difi.no/ehf/knowledge-base/validation/

Attached is structure tables providing a structured overview of the document types.

Attached is complete message table for the document types.

Current code lists for EHF:

This implementation guide builds upon UBL 2.1 Schemas available from OASIS.

These schemas are used when performing syntax validation.

Please see the UBL 2.1 homepage for information about the standard or further resources available.

Validation files based on Schematron may be found in our Github repoistory. Release "2021-02-15" is used for the current version of resources and branch "master" is for development and review.

Difi provides validation artifacts as Schematron and not as XSLT as of release 2016-11-15.

Example files are provided to help implementers. Example files for this implementation guideline is included in the example file archive.

The following industry guides are available (Norwegian only):