EHF Forward Billing 3.0 is used to perform forward billing, "gjennomfakturering" in Norwegian, prior to billing of customer. This specifications adapts PEPPOL BIS Billing 3.0/EHF Billing 3.0 to support forward billing.

1. Overview

This specification is conformant with PEPPOL BIS Billing 3.0, and therefore comformant with EN 16931.

The full specification of EHF Billing 3.0 using UBL syntax is used to expressed the transaction.

Deviations from PEPPOL BIS Billing 3.0 are made to

Table 1. Deviations
Rule Reason

BR-07

Element cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity is mandatory in EN 16931. This rules is removed to make cac:PartyLegalEntity optional, where the existence of the element indicate a business customer, and lack of the element indicate a consumer customer.

PEPPOL-EN16931-R007

Process identifier used in the forward billing transactions belongs to Difi. This rules is removed to deviate the process identifier.

2. Description

This section describes aspects particular to forward billing. Please see the EHF Billing 3.0 documentation for more information.

2.1. Identification

Transactions in forward billing is identified accordingly to allow for deviation and routing.

Identification in invoice
<?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:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0#conformant#urn:fdc:anskaffelser.no:2019:ehf:forward-billing:3.0</cbc:CustomizationID> (1)
  <cbc:ProfileID>urn:fdc:anskaffelser.no:2019:ehf:postaward:g3:08:1.0</cbc:ProfileID> (2)
1 Customization identifier indicating a forward billing transaction.
2 Process identifier indicating the forward billing process.
Identification in credit note
<?xml version="1.0" encoding="UTF-8"?>
<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
            xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
            xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0#conformant#urn:fdc:anskaffelser.no:2019:ehf:forward-billing:3.0</cbc:CustomizationID> (1)
  <cbc:ProfileID>urn:fdc:anskaffelser.no:2019:ehf:postaward:g3:08:1.0</cbc:ProfileID> (2)
1 Customization identifier indicating a forward billing transaction.
2 Process identifier indicating the forward billing process.

2.2. Customer, business

Business customers are provided accoring to EHF Billing 3.0, where the existence of cac:PartyLegelEntity indicate the customer is a business.

Example of customer being a business
<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0192">987654325</cbc:EndpointID> (1)
    <cac:PartyIdentification>
      <cbc:ID>hn0073648</cbc:ID> (2)
    </cac:PartyIdentification>
    <cac:PostalAddress>
      <cbc:StreetName>Storoveien 4</cbc:StreetName>
      <cbc:CityName>Oslo</cbc:CityName>
      <cbc:PostalZone>0542</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyLegalEntity> (3)
      <cbc:RegistrationName>Buyer AS</cbc:RegistrationName>
      <cbc:CompanyID schemeID="0192">877734641</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>
1 Electronic address of the organization receiving the forward invoice/credit note for further billing of customer.
2 Party identification according to EHF Billing 3.0, may be bilaterally agreed.
3 Existence of cac:PartyLegelEntity indicate a business customer.

2.3. Customer, consumer

Business customers are provided accoring to EHF Billing 3.0, where the lack of cac:PartyLegelEntity indicate the customer is a consumer.

Example of customer being a consumer
<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0192">987654325</cbc:EndpointID> (1)
    <cac:PartyIdentification>
      <cbc:ID>hn0073648</cbc:ID> (2)
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>Lisa Johansen</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress>
      <cbc:StreetName>Heimdalsgata 32</cbc:StreetName>
      <cbc:CityName>Oslo</cbc:CityName>
      <cbc:PostalZone>0154</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
  </cac:Party> (3)
</cac:AccountingCustomerParty>
1 Electronic address of the organization receiving the forward invoice/credit note for further billing of customer.
2 Party identification according to EHF Billing 3.0, may be bilaterally agreed.
3 Lack of cac:PartyLegelEntity indicate a consumer customer.

3. Sector usage

This section contains information related to specific sectors using EHF Forward Billing 3.0.

Information in this section does not limit use in sectors not mentioned.

3.1. Energy sector

3.1.1. Background

Norges Vassdrags- og Energidirektorat stated in its report no. 48-2016 «Endring i forskrift om måling, avregning, fakturering av nettjenester og elektrisk energi, nettselskapets nøytralitet mv. - Endringer vedrørende gjennomfakturering - Oppsummering av høringsuttalelser og endelig forskriftstekst», dated May 2016, the basis for carrying secondary law regarding invoicing of grid services to end users via power suppliers ("forward invoicing"), in force from September 1., 2016 [3]. Enforcement of this regulation is now safeguarded by Reguleringsmyndigheten for Energi (REM), in accordance with transfer of authority November 1. 2019.

According to secondary law "Avregningsforskriften" [1], §7-4b, letter b, information exchange when forward invoicing shall be performed based on formats, protocols and timeframes set by Systemstøtte for Ediel. Furthermore, Avregningsforskriften [1] states that EHF Billing (EHF) shall be the standard format for distributing base data for electronic invoices and credit notes on grid owner services, and that meteringpoint ID shall be used to identify the end user in the course of the invoicing transmission.

A national expert group ("Norsk Ediel Ekspertgruppe") with representatives from the Norwegian power industry has supplied existing regulation with business rules for the national forward invoicing EHF-based standard. These business rules were upgraded January 2020, in correspondence with the Difi upgrade to EHF ver. 3.0.

3.1.2. Use of EHF Forward Billing 3.0

All grid owners offering to forward their invoice to the end users via the power supplier must as a minimum be able to do so based on the EHF format, presenting the grid owner’s "original invoice" to the end user as a PDF attachment. As a minimum option the grid owner must be able to distribute this through the EHF (PEPPOL) transport infrastructure to the power supplier’s access point found in ELMA.

The Peppol Network is the chosen interexchange infrastructure because of its automatic message validation properties. Other formats and transmission methods may be agreed bilaterally between grid owner and power supplier.

PEPPOL BIS Billing 3.0 has offered the opportunity to separate the forward billing process from ordinary EHF invoice exchange, simplifying identification and handling forward billing invoices with the receiving power suppliers.

By "original invoice" these guidelines refer to the original invoice from the grid owner, with the settlement information directed at the end user in the payment giro removed. Please note that RME only requires settlement information to be removed on invoices directed to household customers, as opposed to businesses, where the market parties may decide whether to remove/ mask the settlement information or not. According to requirements connected to usage of PDF attachments, it must be clearly specified in the document that the PDF attachment is not the valid invoice. Sending the "grid owner original invoice" as PDF attachment is a simple solution used by many market parties today, as PDFs are time-saving and easily accessible to print and forward to end users demanding paper copies of grid owner invoices.

Settlement information is to be understood as due date, account number and KID (customer identification number).

  • The grid owner’s original invoice is to be forwarded as a PDF attachment:

    • The end user is the customer for the EHF forwarded invoice

    • The power supplier is the payer for the EHF forwarded invoice

    • Settlement information must be removed from the payment giro in the PDF, as the end user is to pay to the power supplier

    • The PDF is to be transmitted in Base64 format, please see examples in appendix .. and .., as well as EHF invoice and credit note [..].

  • The standard solution allows only one meteringpoint ID in each EHF invoice, as the invoice recipient (the end user) must be stated in the header of the EHF invoice.

  • Transmission of contact details for the grid owner is not part of the standard for forward invoicing:

    • Contact information to the grid owner is voluntarily distributed through the EHF forward invoice.

    • This is handled through bilateral agreements between grid owner and power supplier

    • The transmission between the designated EHF access points is presently not encrypted

3.1.3. Meteringpoint ID

Meteringpoint ID is in PEPPOL BIS Billing 3.0 awarded its own formal segment; AdditionalDocumentReference, in combination with schemeID AVE. Along with name, birth date/ organization number and installation address, this identifies the end user invoiced by the grid owner.

Identification of meteringpoint ID
<cac:AdditionalDocumentReference>
  <!--AVE being code for meteringpoint id according to codelist-->
  <cbc:ID schemeID="AVE">707057500011223344</cbc:ID>
  <cbc:DocumentTypeCode>130</cbc:DocumentTypeCode>
</cac:AdditionalDocumentReference>

3.1.4. Indicating original invoice or credit note

To indicate original invoice PDF in forward billing the identifier Original invoice is used to find the attachement. Other attachements not using the identifier are additional attachements.

Example of attached original invoice.
<cac:AdditionalDocumentReference>
  <cbc:ID>Original invoice</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="originalinvoice.pdf">
      QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==
    </cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

Identifier Original invoice indicates the original invoice.

Similarly, original credit note PDF is indicated by the identifier Original credit note to find the attachment.

Example of attached original credit note
<cac:AdditionalDocumentReference>
  <cbc:ID>Original credit note</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject filename="originalcreditnote.pdf" mimeCode="application/pdf">
      QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ== (1)
    </cbc:EmbeddedDocumentBinaryObject>
   </cac:Attachment>
 </cac:AdditionalDocumentReference>
1 PDF content as base64.

3.1.5. Identifying power supplier

The power supplier is in PEPPOL BIS Billing 3.0/ forward billing identified in the segments AcccountingCustomerParty and PartyLegalEntity and must correspond with EndpointID.

Identification of power supplier
<cac:AccountingCustomerParty>
  <cac:Party>
    <!--Kraftselskapets orgnummer og fakturainformasjon-->
    <cbc:EndpointID schemeID="0192">987654325</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID>hn0073648</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>Kraftselskapet AS</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress>
      <cbc:StreetName>Kraftveien 4</cbc:StreetName>
      <cbc:CityName>Oslo</cbc:CityName>
      <cbc:PostalZone>0542</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Kraftselskapet AS</cbc:RegistrationName>
      <cbc:CompanyID schemeID="0192">123456789</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

3.1.6. End user name, birth date/ organization number and installation address

Household end user name is to be submitted in the AdditionalDocumentReference segment, with ID in the format YYYY-MM-DD, indicating a household end user. Corresponding segment DocumentDescription will then provide the household end user name.

Please note that for security reasons only birth date is to be submitted for household end users, not the entire birth number.

Identification of household end user
<cac:AdditionalDocumentReference>
  <!--If ID=YYYY-MM-DD the end user is a household customer, with name submitted in DocumentDescription-->
  <cbc:ID>1985-02-14</cbc:ID>
  <cbc:DocumentDescription>Ola Nordmann</cbc:DocumentDescription>
</cac:AdditionalDocumentReference>

For corporate end users, the AdditionalDocumentReference ID will contain a 9-digit organization number, and consequently DocumentDescription will provide the corporate end user name.

Identification of corporate end user
<cac:AdditionalDocumentReference>
  <!—If 9 digit ID, the end user is a corporate user, with name submitted in DocumentDescription-->
  <cbc:ID>990399123</cbc:ID>
  <cbc:DocumentDescription>Edisys Consulting AS</cbc:DocumentDescription>
</cac:AdditionalDocumentReference>

Installation address may be found in the segment Delivery, beneficial for verifying correct installation for multiple installation end users.

Information on installation address
<cac:Delivery>
  <cac:DeliveryLocation>
    <cac:Address>
      <cbc:StreetName>Anleggsadressen 12</cbc:StreetName>
      <cbc:CityName>Oslo</cbc:CityName>
      <cbc:PostalZone>1144</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:Address>
  </cac:DeliveryLocation>
</cac:Delivery>

The fields are widely used by the energy sector for supplementary verification of correct end user.

3.1.7. Other

According to PEPPOL BIS Billing 3.0 either <cbc:BuyerReference> or <cac:ContractDocumentReference> must be submitted by the grid owner. These segments are however not in use by the power industry. The grid owner submitting NA in one of these segments is deemed sufficient, and the power supplier may ignore contents of these two segments.

3.1.8. Example files

The following example files are made available:

Appendix A: UBL 2.2

This implementation guide builds on UBL 2.2 Schemas, available from OASIS.

These schemas are used when performing syntax validation.

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