Dieser Prozess dient dem elektronischen Rechnungsdatenaustausch zwischen Netzbetreiber und Lieferanten in der Versorgungsindustrie für die Sparten Strom und Gas im Falle der Rechnungslegung an den Lieferanten. Die Übertragung der Rechnungsdaten hat für beide Energierichtungen zu erfolgen, also sowohl Verbrauchs- als auch Erzeugungsrechnungen mit Rechnung an Lieferanten müssen in dieser Form übermittelt werden. Das Schema ebutilities-Invoice 03.10 muss verwendet werden. Ergänzend zu den gesetzlichen Regelungen sowie den Schema-Vorgaben gelten folgende Regelungen:

Encoding
Bei der Erstellung der XML Daten ist das UTF-8 Encoding zu verwenden.

Rechnungslegung
Alle Rechnungen zur Netznutzung müssen in elektronischer Form übermittelt werden. D.h., neben der Verbrauchsabrechnung müssen auch Teilbetrags- und Stornorechnungen elektronisch gesendet werden.

Bei Teilbetragsrechnungen darf beim Element „PaymentPosition“ nur der Qualifier „TZBA“ übermittelt werden. Die Elemente „ConsumptionItem“ und „IndividualItem“ sowie andere „PaymentPosition“ dürfen nicht befüllt sein.

Die „MeteringPointInfo“ muss generell befüllt sein.

In der Beziehung Netzbetreiber-Lieferant ist der „LegalInvoiceType“ NSIG (ohne Signatur der E-Rechnung) bzw. DSIG (mit Signatur der E-Rechnung) anzuwenden. Es darf zusätzlich keine Papierrechnung versendet werden. 

Das Element "IndividualItem" ist in der Beziehung Netzbetreiber - Lieferant generell nicht mehr zulässig. Rechnungen, die in dieser Form gelegt werden, können mit dem ResponseCode 812 (unzulässige Zusatzpositionen) des Prozesses BI_REJ abgelehnt werden.

Submessungen
Die „BillingQuantity“ der Energiemenge für die Gesamtmessungs-„MeteringPosition“ wird positiv dargestellt. Die „BillingQuantity“ für die Submessungs-“MeteringPosition“ ist negativ darzustellen – beide überlagert (summiert) müssen mit der resultierenden „BillingQuantity“ in den „ConsumptionBillingPosition“ übereinstimmen.

Der Zählpunkt der Submessung darf in den „MeteringPointInfo“ nicht angeführt sein.

Empfehlung: Um in den „MeteringPosition“ die Submessung anhand der Gerätenummer erkennen zu können, sollte die „DeviceNumber“ mit „SUB“ beginnen.

Darstellung zeitabhängiger Preise
Das Element "TimeDefinition" ist im Bereich der ConsumptionBillingPosition immer dann zu verwenden, wenn die Maßeinheit des Einheitspreises (PricePerItem) einen expliziten Zeitanteil enthält (z.B. €/Monat, €/Jahr, €/Tag oder eben insbesondere für die Leistung: €/(kW/Jahr), bzw. €/(kWh/h/Jahr),…)

• Im Falle rein zeitabhängiger Preise ist als Definition „1 PCE“ für BillingQuantity und BillingUOM zu verwenden (PCE wird hier generell als physikalisch neutrale Einheit gewertet)

• generell soll immer gelten: NetAmount ~= BillingQuantitiy * TimeDefintion-Faktor * PricePerItem Eine allenfalls geringe Differenz zwischen NetAmount und der vollständigen Produktkette der möglichen 2 - 3 Faktoren ist auch hier wiederum ausschließlich über Rundungsabweichungen begründbar.

Produktkatalog
Für die Sparte Strom ist der beiliegende Produktkatalog und der „ProductCodeType“ „VEO“ verpflichtend zu verwenden.

Für die Sparte Gas ist der beiliegende Produktkatalog und der „ProductCodeType“ „FGW“ verpflichtend zu verwenden.

Produktnummern
Die „ProductID“ für die Produktkennzeichnung ist als 4stelliger alphanumerischer Wert (Zeichenkette und keine Zahl!) definiert. „Führende“ Nullen sind daher immer darzustellen. Beispielsweise ist die Produktnummer „1“ nicht definiert und somit ungültig. Die Produktnummer „1“ ist nicht äquivalent zu „0001“ zu sehen.

Produktnummernzuordnung
Alle Produktnummern sind in der Beziehung Netzbetreiber - Lieferant in den  „ConsumptionBillingPosition“  abzubilden.

Doppeltarife (Sparte Strom)
Für Doppeltarife muss die Produktnummer so gesendet werden, dass die Tarife aus der Produktnummer zu erkennen sind. An der 3. Stelle der Produktnummer muss für NT die Ziffer 7 und für HT die Ziffer 8 verwendet werden.

OBIS Kennziffer
Der „MeterCodeType“ OBIS muss für alle „MeteringPosition“ übermittelt werden. Die OBIS Kennziffern werden in Anlehnung an die die aktuell gültigen Grundlagen „Zählwerte, Datenformate und standardisierte Lastprofile“ abgebildet. Im Segment AA (Messart) wird für Zählerstände der Wert „8“ übermittelt.

ZusatzinformationenSparte Strom:
Das Element „AddInformationCode“ ist mit folgenden Informationen zu befüllen:

• SBR für das erworbene Strombezugsrecht
  
• SEB für die Einheit dieses Bezugsrechtes
  
• SSP für das Synthetische Lastprofil (optional)
  

• GMIN für die Mindestleistung
  
• GMAX für die vertraglich vereinbarte Höchstleistung
  
• GHOE für die vom Netzbetreiber der Rechnung zugrunde gelegte Höhe
  
• GTMP für die Temperatur
  
• GSP für das Synthetische Lastprofil (optional)
  

Für die Angaben der Leistung sind Dezimalzahlen mit Dezimalstellen in kWh/h (ohne Trennzeichen und Einheit) vorgesehen.

Für die Temperatur gelten nur 2stellige ganzzahlige Werte (z.B. „06“ für „Messung außen“, „15“ für „Messung innen“ sowie „TK“ für temperaturkompensierte Messgeräte. Für die Angaben der Höhe sind nur ganze Zahlen (ohne Trennzeichen und Einheit) vorgesehen.

Typ der Kundeninformation
Für das Attribut „CustomerInfoTyp“ gelten für die Sparte Strom folgende Werte: 

• Allgemein
  
• ElWOG_Info_Netzbetreiber
  
• ElWOG_Ablesung
  

• Allgemein
  
• GWG_Info_Netzbetreiber
  
• GWG_Ablesung 
  

• Allgemein
  
• Kundenservice
  
• Beschwerdemanagement
  
• Stoerung 
  

Zugrundeliegende Menge für Teilzahlungsbetrag

Im Falle eines Teilzahlungsbetrags muss das Element "PaymentPlanSource" verpflichtend übermittelt werden.

Variante 1 - TZB Berechnung auf Grund vorherigem Verbrauch:

DateFrom ... Ab-Datum des zugrundeliegenden Verbrauchs

DateTo ... Bis-Datum des zugrundeliegenden Verbrauchs

Quantity ... zugrundeliegender Verbrauch für die Berechnung des TZB

TotalGrossAmount ... Teilzahlungsbetrag brutto

Count ... Anzahl der vorgeschriebenen TZBs bis zur nächsten Turnusabrechnung

Variante 2 - fixe TZB-Höhe (z.B. auf Grund von Vereinbarung mit dem Kunden):

Manually TRUE

TotalGrossAmount ... Teilzahlungsbetrag brutto

Count ... Anzahl der vorgeschriebenen TZBs bis zur nächsten Turnusabrechnung

PaymentPositions
In der elektronsichen Rechnung des Netzbetreibers an den Lieferanten dürfen die PaymentPositions SOFG (z.B. für die Information von weiteren offenen Rechnungen) und AKON nicht übermittelt werden. Rechnungen, die in dieser Form gelegt werden, können mit dem ResponseCode 812 (unzulässige Zusatzpositionen) des Prozesses BI_REJ abgelehnt werden.

Zählpunktscharfe Kommunikation

In der Beziehung Netzbetreiber-Lieferant darf ein Beleg ausschließlich einem Zählpunkt zugeordnet sein. Dem Lieferanten ist es weiterhin vorbehalten gewisse Zählpunkte für den Kunden zu bündeln.

Eine Belegart je Rechnung

In der Beziehung Netzbetreiber-Lieferant darf ausschließlich eine Belegart einer elektronischen Rechnung zugeordnet sein. Ein gemeinsamer Versand von Rechnung und Teilzahlungsbetrag ist beispielsweise nicht möglich. Rechnungen, die in dieser Form gelegt werden, können mit dem ResponseCode 812 (unzulässige Zusatzpositionen) des Prozesses BI_REJ abgelehnt werden.

Anpassungsstorno

Die Erstellung eines Anpassungsstornos ist in der Beziehung Netzbetreiber-Lieferant nicht zulässig. Es muss ein Storno inkl. erneuter Ausstellung der korrigierten Rechnung durchgeführt werden. Sollte ein Anpassungsstorno überittelt werden, kann dieser mit dem ResponseCode 809 (Storno fehlt) des Prozesses BI_REJ abgelehnt werden.

Angeforderte Teilzahlungen

Jeder Teilzahlungsbetrag muss als DocumentType 386 vorgeschrieben und damit konkret angefordert werden. Im Gegenzug ist jeder Teilzahlungsbetrag über XML-Belege wieder zu neutralisieren (spätestens erfolgt die komplette Auflösung bei Beendigung des Lebenszyklus der Lieferantenbeziehung für einen Zählpunkt).

Dies erfolgt entweder im Rahmen der regulären Abrechnung (DocumentType 82) in Form von TZBG oder über eine explizite Stornierung (DocumentType 83).

Um die Trennung der Belegsicht von der Zahlungssicht nochmals zu verdeutlichen, steht TZBG zukünftig für "Teilzahlungen gefordert" und nicht "Teilzahlungen geleistet".

Leistungszeitraum

Der Leistungszeitraum des Teilzahlungsbetrag muss dem Verbrauchszeitraum entsprechen, den er auch betraglich abbildet. Das heißt es darf keine zeitliche Überlappung geben bzw. darf pro Leistungszeitraum nur ein TZB übermittelt werden.

Konsistenz der verrechneten Menge

Die verrechneten Mengen dürften nicht von den über das Format ConsumptionRecord übermittelten Mengen abweichen.

Vorhandene Verbrauchsdaten (z.B. Smart Meter-Zeitreihen bzw. NonSmart-Zwischenablesungen) müssen für Abgrenzungen (z.B. Netzpreisänderungen) verwendet werden.

Eine Überleitung von den Ablesedaten hin zu den verrechneten Mengen muss auf der XML-Rechnung stimmig dargestellt werden. Gesetzliche Anforderungen hinsichtlich der Darstellung des Zählerstandes können damit - zumindest in Summe - erfüllt werden. Um die Nachvollziehbarkeit zu erreichen sind zwingend Produktcodes für beispielsweise folgende Konstellationen zu verwenden:

- Code für das Delta zwischen physikalischem Netzbezug und verrechnet Restmenge bei gemeinschaftlichen Erzeugungsanlagen

- Codes für redzuzierte Netzpreise bei Energiegemeinschaften

- Code für die Darstellung von Einspeisemengen

Eine Rechnung ohne ConsumptionBillingPosition ist nicht zulässig.

Konsistenz der Umwandlungen

Die angeführten Faktoren müssen bei einer vollständigen Kettenmultiplikation von der MeteringQuantity zur BillingQuantity führen. Es dürfen keine redundanten Faktoren angeführt werden (für die Sparte Gas muss beispielsweise Zustandszahl und Brennwert angeführt werden, der gesamte Umrechnungsfaktor muss aber weggelassen werden).

Eine minimale Abweichung des Ergebnisses ist nur auf Grund der angewendeten Rundungsregeln denkbar und darf keinen substanziellen Widerspruch darstellen.

Darstellung von Prozenten

Für die Darstellung von Prozenten wurde das neue Feld "PriceUOM" in den "ConsumptionBillingPositions" bzw. "IndividualBillingPositions" eingeführt. Damit kann ein Prozentzuschlag oder -rabatt dargestellt werden. Ein entsprechendes Beispiel ist in der Schemadoku ersichtlich.

Für die Abwicklung des Datenaustausch stehen drei Möglichkeiten zur Verfügung:

1. Prozessumsetzung in der eigenen IT-Landschaft: EDA Messenger oder EDA e-mail. Für weitere Infos kontaktieren Sie bitte eda@ebutilities.at.
   
2. Nutzung eines IT Dienstleister (SaaS): EDA Messenger, welcher durch den IT Dienstleister betrieben wird. Für weitere Infos kontaktieren Sie bitte Ihren IT Dienstleister
   
3. SelfStorage-Dienst der Verrechnungsstellen für Lieferanten: EDA Messenger, welcher durch die Verrechnungsstellen betrieben wird
   

Der energiewirtschaftliche Datenaustausch ist grundsätzlich für alle Marktteilnehmer (ausgenommen Verteilernetzbetreiber) kostenlos.

Fristen entsprechend der gesetzlichen Vorgaben zur Rechnungslegung

siehe Schemadokumentation und Beschreibung

Aufrechte Rahmenvereinbarung über die umsatzsteuerliche Behandlung von Leistungen aus Netzzugangsverträgen insbesondere über die Anwendung des in Rz 1536 der USt.-Richtlinien 2000 angeführten Vorleistungsmodells

Aufrechter Liefervertrag im Abrechnungszeitraum

Änderungen gegenüber der Version 01.00:

- PaymentPositions SOFG und AKON sind nicht mehr zulässig

- die Kommunikation der XML-Rechnung erfolgt ausschließlich zählpunktsscharf

- in einer Rechnung darf nur mehr eine Belegart übermittelt werden

- ein Anpassungsstorno ist nicht mehr zulässig

- TZBG stellen die Belegsicht und nicht die Zahlungssicht dar

- Klarstellung Leistungszeitraum von TZBs

- durchgehende Konsistenz der verrechneten Menge

- durchgehende Konsistenz der Umwandlungen

- Klarstellungen und Ausformulierungen bei zeitabhängigen Preisen

- Schemaänderung: zukünftig sind statt 6 Nachkommastellen 12 Nachkommastellen im Schema beim PricePerItem zulässig. Diese Maximalanzahl wurde gewählt um für allfällige zukünftige Anforderungen gewappnet zu sein - aus jetziger Sicht ist keine Anforderung mit mehr als 7 NK bekannt

- Schemaänderung: neues Feld für Prozentrabatt und Zuschläge

- Ablöse Workaround für TZB-Höhe durch Element

- Ausschließlich ConsumptionBillingPosition sind zulässig

- Wegfall Übermittlung Gas-Umrechnungsfaktor, sondern Zustandszahl und Brennwert