1. Introduction

EHF Invoice and Credit Note is called EHF Fakturering 3.0 in Norway. EHF Fakturering 3.0 is based on the Peppol BIS billing 3.0 specification.

EHF Fakturering 3.0 is the implementation of EN 16931 Electronic invoicing according to EU Directive 2014/55/EU for the Norwegian market through Peppol BIS billing 3.0 EHF Fakturering 3.0 is the name used in Norwegian regulation.

i: Since EHF Fakturering 3.0 is based on Peppol BIS billing 3.0 must all issues, bugs or comments to the specification be reported at the Peppol Service Desk as "Request for Change (RFC)".

Since EHF Billing 3.0 is rebranding of Peppol BIS Billing 3.0 must all issues, bugs or comments to the specification be reported at the OpenPeppol Service Desk as "Request for Change (RFC)".

2. Implementation

OpenPeppol has created Peppol BIS Billing 3.0, a Core Invoice Usage Specification (CIUS) as implementation of EN 16931, for cross border using in Peppol. The new Peppol BIS Billing 3.0 support inclusion of national rules based on origin country of seller.

Based on work done in Peppol BIS Billing 3.0, Difi has included Norwegian rules in Peppol BIS Billing 3.0 and does not see a need to implement a different CIUS targeting the Norwegian market. Implementation of EHF Billing 3.0 is therefore done by implementing Peppol BIS Billing 3.0 without extensions or extra rules.

2.1. Standard documentation

Norwegian organizations may download the following parts of EN16931:

3. Description

3.1. Applying "Foretaksregisteret"

Most Norwegian invoices and credit notes need to apply the text "Foretaksregisteret" according to nation requirement:

Dersom selger er aksjeselskap, allmennaksjeselskap eller filial av utenlandsk selskap skal også ordet «Foretaksregisteret» fremgå av salgsdokumentet, jf. foretaksregisterloven § 10-2.

UBL example of applying "Foretaksregisteret" in invoice/credit note.
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- ... -->
    <cac:PostalAddress>
      <!-- ... -->
      <cac:Country>
        <cbc:IdentificationCode>NO</cbc:IdentificationCode> (1)
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>NO111222333MVA</cbc:CompanyID> (2)
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>Foretaksregisteret</cbc:CompanyID> (3)
      <cac:TaxScheme>
        <cbc:ID>TAX</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <!-- ... -->
  </cac:Party>
</cac:AccountingSupplierParty>
1 Identification code shows the invoice country code, here NO = Norway.
2 The two first letters implies a country when using VAT as identifier element.
3 Shows how to imaplement according to rule "NO-R-002" (Foretaksregisteret).

3.2. Value Added Tax (Norwegian MVA)

Norwegian tax categories are mapped according to this table for use with PEPPOL BIS Billing 3.0:

Table 1. Valid VAT categories and rates
VAT category Description Rate as of January 1, 2019

S

Output VAT, regular rate

25%

S

Output VAT, reduced rate, middle

15%

S

Output VAT, reduced rate, raw fish

11,11%

S

Output VAT, reduced rate, low

12%

E

VAT excempt

0%

Z

VAT excempt (Goods and services not included in the VAT regulations)

0%

K

Emission allowances for private or public businesses – buyer calculates VAT

0%

AE

Reversed VAT

0%

G

Export of goods and services

0%
Rounding of amount related to VAT must follow the statement of principal (english translation).
Rates used in the invoice/credit note must follow the official rates defined by The Norwegian Tax Administration. Implementers in need of exempt is required to request such an exempt using RF-1306 before invoicing. In the case of exempt is the rate (not amount) to be changed accordingly due to rules in EN16931. Documentation of exempt must be shared with Difi upon request.

Explanation of some VAT-codes:

  • E (VAT exempt): According to Lov om merverdiavgift shall E be used for products and services that is stated in §3-2 to §3-20.

  • Z (VAT exempt- Goods and services not included in the VAT regulations): According to Lov om merverdiavgift shall Z be used for products and services that is stated in chapter 6.

  • Peppol BIS Billing 3.0 VAT code list operates with a code O (Services outside scope of tax). This code shall be used for products and services for businesses that are except from Lov om merverdiavgift.

Please see the PEPPOL BIS Billing 3.0 documentation for more information about value added tax.

3.3. Payment Information

Payment information need to be provided in element cac:PaymentMeans in an invoice, which contains instruction about how a payment is expected to be (e.g. credit transfer), remittance information, and either payment card information, credit transfer information or direct debit information.

In general, there are fire different types of payments:

  • Card payment - must use cac:PaymentMeans/cac:CardAccount

  • Credit transfer - must use cac:PaymentMeans/cac:PayeeFinancialAccount

  • Direct debit - must use cac:PaymentMeans/cac:PaymentMandate

  • Payment by post- or bank giro - must use cac:PaymentMeans/cac:PayeeFinancialAccount

In the invoice the supplier can specify how a payment is expected to be, by using element cbc:PaymentMeansCode. The allowed payment codes can be found in Payment means code - code list.

See further details and examples of payment means information in PEPPOL BIS Billing specification.

3.3.1. IBAN/BBAN Payments

BBAN is a national bank account number used for national payments, while IBAN is an international bank account number used for international payments. In EHF Billing 3.0 (PEPPOL BIS Billing 3.0), BBAN and IBAN need to be applied as credit transfer, where the payment means code can, for example, be 30 (credit transfer), 54 (SEPA credit transfer) or other codes from Payment means code - code list.

If credit transfer information is provided in the invoice the payment account identifier must be present, regarding BR-50. Payment account identifier is a unique identifier of the financial payment account to which a payment should be made, such as BBAN or IBAN. In the invoice, the supplier can state the BBAN or IBAN by using the element cac:PaymentMeans\cac:PayeeFinancialAccount\cbc:ID.

The payment account identifier can be a BBAN or IBAN number, not the physical text "BBAN" or "IBAN".

Following example illustrates how to use IBAN in the invoice. Note that, only BIC (Bank identifier code) or national clearing code need to be provided in element cac:FinancialInsitutionBranch\cbc:ID, when applying IBAN in an invoice.

UBL example of applying IBAN in an invoice.
<cac:PaymentMeans>
    <cbc:PaymentMeansCode name="credit transfer">30</cbc:PaymentMeansCode>(1)
    <cbc:PaymentID>01245785421</cbc:PaymentID>(2)
    <cac:PayeeFinancialAccount>
        <cbc:ID>NO4970011111222</cbc:ID>(3)
        <cbc:Name>AccountX</cbc:Name>(4)
        <cac:FinancialInsitutionBranch>
            <cbc:ID>DNBANOKK</cbc:ID>(5)
        </cac:FinancialInsitutionBranch>
    </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
1 Payment means type codes from Payment means code - code list
2 Remittance information about the payment, for example KID-number.
3 IBAN (International Bank Account Number)
4 Account name
5 BIC (Bank identifier code) or national clearing code

Following example illustrates how to use BBAN in the invoice. Note that, element cac:FinancialInsitutionBranch shall not be used when applying BBAN.

UBL example of applying BBAN in an invoice.
<cac:PaymentMeans>
    <cbc:PaymentMeansCode name="credit transfer">30</cbc:PaymentMeansCode>(1)
    <cbc:PaymentID>01245785421</cbc:PaymentID>(2)
    <cac:PayeeFinancialAccount>
        <cbc:ID>4970011111222</cbc:ID>(3)
        <cbc:Name>AccountX</cbc:Name>(4)
    </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
1 Payment means type codes from Payment means code - code list
2 Remittance information about the payment, for example KID-number
3 BBAN (National Bank Account Number)
4 Account name

3.3.2. SEPA Payments

SEPA (Single Euro Payments Area) is an electronic Euro payment. There are two different SEPA payment methods in the invoice, from Payment means code - code list we have:

  • 58 - SEPA Credit transfer

  • 59 - SEPA Direct debit

BBAN is not allowed in SEPA payments- use IBAN.
SEPA Credit Transfer
UBL example of applying SEPA Credit transfer with IBAN in an invoice.
<cac:PaymentMeans>
    <cbc:PaymentMeansCode name="SEPA credit transfer">58</cbc:PaymentMeansCode>(1)
    <cbc:PaymentID>01245785421</cbc:PaymentID>(2)
    <cac:PayeeFinancialAccount>
        <cbc:ID>NO4970011111222</cbc:ID>(3)
        <cbc:Name>AccountX</cbc:Name>(4)
        <cac:FinancialInsitutionBranch>
            <cbc:ID>DNBANOKK</cbc:ID>(5)
        </cac:FinancialInsitutionBranch>
    </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
1 SEPA credit transfer code from Payment means code- code list
2 Remittance information about the payment, for example KID-number.
3 IBAN (International Bank Account Number)
4 Account name
5 BIC (Bank identifier code) or national clearing code
SEPA Direct Debit
UBL example of applying SEPA Direct Debit in an invoice.
<cac:AccountingSupplierParty>
    <cac:Party>
        <cbc:EndpointID schemeID="0192">987654325</cbc:EndpointID>
        <cac:PartyIdentification schemeID="SEPA">9512357</cac:PartyIdentification>(1)
    </cac:Party>
    <!-- ... -->
</cac:AccountingSupplierParty>
<cac:PaymentMeans>
    <cbc:PaymentMeansCode name="SEPA direct debit">59</cbc:PaymentMeansCode>(2)
    <cbc:PaymentID>01245785421</cbc:PaymentID>(3)
    <cac:PaymentMandate>
        <cbc:ID>123456789</cbc:ID>(4)
        <cac:PayerFinancialAccount>
            <cbc:ID>NO4970011111222</cbc:ID>(5)
        </cac:PayerFinancialAccount>
    </cac:PaymentMandate>
</cac:PaymentMeans>
1 Unique banking reference identifier of the Seller/Payee, where the schemeID MUST be "SEPA"
2 SEPA direct debit code from Payment means code - code list
3 Remittance information
4 Mandate reference identifier
5 The account to the debited - IBAN

3.3.3. EHF Fakturering (Peppol BIS billing) as a carrier of CO2 values

EHF invoice can also be used to express CO2 values (A1-A3) for each individual product. EHF invoice (Peppol BIS billing 3.0) has two free fields (Additional Item Properties): a name field and a value field. These fields can be used by the supplier to express the CO2 value for the product:

Definitions coordinated with Denmark (ERST) and Byggstand in Norway

Table 2. Definition of CO2 emission data fields added in AdditionalItemProperty
Property Description

EmissionFactor

Emissions per invoiced unit. Unit of measure is always kilogram CO2-eq (CO2e) per unit of InvoicedQuantity.

NetEmissionQuantity

NetEmissionQuantity is the total CO2e amount for the invoice line item (always in CO2e) Calculated as InvoicedQuantity * EmissionFactor Unit of measure is always kg CO2e.

EmissionFactorSource

The source for the CO2e calculation. Can be either an internal source (Internal) or external database(Database). This indicates whether the sender has done their own CO2e calculation or relies on third parties.

EmissionFactorCalculationRate

The multiplication factor for converting the emission factor listed in EmissionFactorSource into emissions per invoiced unit listed in EmissionFactor.

The EmissionFactorCalculationRate is required if the emission factor in the EmissionFactorSource is calculated on a different basis than InvoicedQuantity. For example: * The source specifies emission factor per kilogram (KGM), but InvoicedQuantity is each (EA). In this case EmissionFactorCalculationRate is the (average) number of kilogram per piece. If each piece is 10 kilogram (on average), the EmissionFactorCalculationRate is 10. * The source specifies the emission factor per 100 litre, but the InvoicedQuantity is in litre. In this case the EmissionFactorCalculationRate is equal to 0.01.

This allows EmissionFactor to be calculated from first principles as (the emission factor from EmissionFactorSource) * EmissionFactorCalculationRate.

EmissionFactorCalculationUnit

The EmissionFactorCalculationUnit is required if the emission factor unit code is different from the InvoicedQuantity unit code (e.g. source specifies emissions factor per kilogram (KGM) but InvoicedQuantity is each (EA)). EmissionFactorCalculationUnit is used to specify the base unit used by the source (e.g. KGM).

Unit of measure shall contain a valid unit code (e.g. KGM (kilogram) or LTR (litre)), which must be different from the unit code of InvoicedQuantity.

EmissionFactor

Emissions per invoiced unit. Unit of measure is always kilogram CO2-eq (CO2e) per unit of InvoicedQuantity.
NB!

Base Quantity does not impact the Emission Factor and the Emission Factor Quantity (which are defined per invoiced unit, not per price unit).

UBL XML eksempel EHF faktura
<?xml version="1.0" encoding="UTF-8"?>
<Invoice
xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:ID/>
<cbc:IssueDate/>
<cac:AccountingSupplierParty/>
<cac:AccountingCustomerParty/>
 <cac:LegalMonetaryTotal>
<cbc:PayableAmount/>
</cac:LegalMonetaryTotal>
 <cac:InvoiceLine>
    <cbc:ID/>
    <cbc:LineExtensionAmount/>
        <cac:Item>
             <cac:AdditionalItemProperty>
                  <cbc:Name>EmissionFactor</cbc:Name>
                  <cbc:Value>0.20</cbc:Value>
              </cac:AdditionalItemProperty>
              <cac:AdditionalItemProperty>
                  <cbc:Name>NetEmissionQuantity</cbc:Name>
                 <cbc:Value>1.4</cbc:Value> </cac:AdditionalItemProperty>
            <cac:AdditionalItemProperty>
                <cbc:Name>EmissionFactorSource</cbc:Name>
                <cbc:Value>Database</cbc:Value> </cac:AdditionalItemProperty>
           <cac:AdditionalItemProperty>
                <cbc:Name>EmissionFactorCalculationRate</cbc:Name>
                <cbc:Value>0.25</cbc:Value> </cac:AdditionalItemProperty>
          <cac:AdditionalItemProperty>
               <cbc:Name>EmissionFactorCalculationUnit</cbc:Name>
              <cbc:Value>KGM</cbc:Value>
         </cac:AdditionalItemProperty>
</cac:Item>
</cac:InvoiceLine>
</Invoice>
Obtain environmental information for individual products via external database

For obtaining environmental information stored in external databases, in the form of machine-readable EPDs or Digital Product Passports, the free fields can also be used. The purpose is that the digital files sent do not become too large. The information collected by the client/buyer can be used in the analysis of the company’s behaviour and used for various reporting purposes. The environmental properties of the product in combination with information from the ordering process (EHF order and order confirmation) and the delivery process (EHF despatch advice), can form a more complete data basis of the environmental footprint from production until the product is with the client/buyer.

Below you will find an xml example:
<cac:InvoiceLine>
           <cbc:ID/>
          <cbc:LineExtensionAmount/>
                     <cac:Item>
                                <cac:AdditionalItemProperty>
                                     <cbc:Name>CO2EmissionFactorSource</cbc:Name>
                                     <cbc:Value>[lenke til miljødatabase]</cbc:Value>
                                </cac:AdditionalItemProperty>

4. Appendix

Appendix A: Example files

Example files provided for implementers familiar with example files provided by EHF Invoice and Credit Note 2.0:

Please see comments inside example files for guidance.