eInvoice; V 1.0
 
<<< zurück

 

Einführung

1. Aufbau der eInvoice-Empfehlung

Die vorliegende eInvoice Empfehlung basiert auf EANCOM® 2002, dem EDI-Standard von GS1 im Rahmen des EAN.UCC-Systems. Ziel der Empfehlung ist, den Anwendern eine Beschreibung zu bieten, wie Rechnungsdaten zwischen Handelspartnern in Europa ausgetauscht werden können.

Zur Datenübertragung wird der Nachrichtentyp INVOIC 010 des EDI-Standards EANCOM® 2002 genutzt. Es wird ausdrücklich darauf hingewiesen, dass diese Empfehlung nicht die komplette Originalbeschreibung der entsprechenden Kapitel und weitere relevante Hinweise der EANCOM® 2002-Dokumentation ersetzt. Es handelt sich vielmehr um eine Beschreibung der zu verwendenden Segmente, Datenelemente und Codes für eine spezielle Aufgabenstellung.

Zur Zeit sind acht Länderprofile in dieser Empfehlung enthalten:

Für jedes dieser Länder wurde ein individuelles Länderprofil mit den relevanten Informationen (Betriebswirtschaftlichen Begriffen/Business Terms) erzeugt. Die Gesamtheit der Informationen der Länderprofile bilden die Informationen, die im europäischen Gesamtprofil enthalten sind. Für jeden betriebswirtschaftlichen Begriff/Business Term wird der relevante Status im jeweiligen Land angezeigt. Für das europäische Gesamtprofil werden keine Statusangaben gemacht, da die Stati in den Ländern unterschiedlich sind.

 

2. Navigation

Diese Empfehlung bietet mehrere Möglichkeiten der Navigation. Für jedes beteiligte Land existiert ein eigenes Länderprofil. Wenn ein Länderprofil über die Länderflagge ausgewählt wird, wird nur die in diesem Land verwendete Information angezeigt. Das europäische Profil ist eine Zusammenfassung aller in den beteiligten Ländern genutzten Informationen. Generell ist diese Empfehlung in englischer Sprache verfasst. Zusätzlich kann im europäischen und deutschen Profil und in der Einführung zwischen englischer und deutscher Sprache gewählt werden.

Weitere Informationen zur Nutzung von EANCOM®/EDIFACT sind im Anhang 1 (Abschnitt 5) des Teils 1 des EANCOM®-Handbuchs zu finden.

Die eInvoice-Dokumentation ist in vier Teile unterteilt:

Abschnitt 1, "Alphabetische Liste der betriebswirtschaftlichen Begriffe"

In diesem Abschnitt sind die betriebswirtschaftlichen Begriffe/Business Terms, die im ausgewählten Profil verwendet werden, in alphabetischer Reihenfolge aufgelistet. In dieser Liste wird eine harmonisierte Definition jedes betriebswirtschaftlichen Begriffs angegeben und, falls vorhanden, werden zusätzliche Kommentare und/oder Abhängigkeiten angegeben.

In der Liste wird zu jedem betriebswirtschaftlichen Begriff/Business Term der Status in jedem Land angegeben. Die Statusangabe ist mit dem zugehörigen Segment im Segmentlayout verlinkt. Die folgenden Abkürzungen werden für die Statusangaben genutzt:

R = Erforderlich - Muss-Angabe (Required)
O = Optional - Kann-Angabe (Optional)
D = Konstellationsabhängig (Depending)

Wird ein betriebswirtschaftlicher Begriff in einem bestimmten Land nicht genutzt, ist das betreffende Feld leer. Der Status "X" wird nur im europäischen Profil genutzt, um eine Verlinkung zum betreffenden Segment im Segmentlayout zu ermöglichen, da auf europäischer Ebene keine Statusangaben gemacht werden können.

Durch das Klicken auf die Länderflagge werden die im ausgewählten Land verwendeten betriebswirtschaftlichen Begriffe angezeigt. Hier werden zusätzlich nationale Kommentare und die zugehörigen Segmente und Datenelemente angezeigt.

Abschnitt 2, "Nachrichtenstruktur"

Die Nachrichtenstruktur ist eine Auflistung aller Segmente wie sie in der EANCOM®-Nachricht definiert sind. Normalerweise wird für jede Information ein einzelnes Segment angegeben. Ausnahmen ergeben sich, wenn die Wiederholhäufigkeit eines Segments limitiert ist und im Segment mehrere Informationen abgebildet werden können (z. B. BGM-Segment). Durch das Klicken auf die Länderflaggen können die Länderprofile ausgewählt werden.

Abschnitt 3, "Nachrichtendiagramm"

Das Nachrichtendiagramm ist eine grafische Darstellung der einzelnen verwendeten Segmente in der Reihenfolge, die durch die EANCOM®-Nachricht vorgegeben ist. Allerdings wird jedes Segment nur einmal angezeigt. Durch das Klicken auf die Länderflaggen können die Länderprofile ausgewählt werden.

Abschnitt 4, "Segmentlayout"

Das Segmentlayout ist eine Darstellung, die die betriebswirtschaftlichen Begriffe (Business Terms) den entsprechenden Elementen der EANCOM® -Syntax gegenüberstellt.

Die rechte Spalte "Beschreibung" enthält den betriebswirtschaftlichen Begriff, die Definition sowie Kommentare und Abhängigkeiten. Der betriebswirtschaftliche Begriff ist mit der Liste der betriebswirtschaftlichen Begriffe verlinkt. Die "Legende" ist diesem Kapitel5 der Einführung verlinkt. Weitere Informationen zur Anwendung von EANCOM®/EDIFACT-Nachrichten, z. B. Statusangeben, Konventionen, Feldlängen usw. sind im Anhang 1 (Abschnitt 5) des Teils 1 des EANCOM®-Handbuchs zu finden.

Durch das Klicken auf die Länderflaggen können auch hier die Länderprofile ausgewählt werden, wenn das betreffende Segment in dem gewählten Länderprofil vorhanden ist. Im europäischen Profil sind die Stati für alle Länder in der Segmentbeschreibung angegeben; in den Länderprofilen nur der Status im ausgewählten Land.

Eine zusätzliche Spalte zur Darstellung des Status eines Datenelements in einem Land wurde im Segmentlayout eingefügt. Hier werden Angaben nur dann gemacht, wenn der Status vom EANCOM®-Status abweicht. Ist der Länderstatus schwächer als der Status in EANCOM® so kann das Datenelement (oder, wenn nur eine Angabe enthalten ist, das gesamte Segment) ausgelassen werden.

Im Normalfall sind die Codenamen in roter Farbe dargestellt, d.h. sie sind innerhalb der Anwendungsempfehlung als restriktiv anzusehen und sollten ohne Absprache mit dem Datenaustausch-Partner nicht geändert/ersetzt werden. Sind Codewerte als Beispiel angegeben, werden sie in blauer Farbe dargestellt, z. B. Maßangaben. In diesem Fall sind alle Werte der entsprechenden Codeliste zugelassen. Durch Klicken auf die Codes oder die Datenelement-/Codelistennummer gelangt man zur Liste der in dieser Empfehlung verwendeten Codes.

Nachrichtenstruktur:

Die INVOIC-Nachricht ist in drei Teile unterteilt:

  1. Kopf-Teil
    Angabe von beteiligten Partnern, Datumsangaben, Rechnungsnummer, Referenzen etc.
  2. Positions-Teil
    Angabe der EAN-Nummern (GTINs) zur Identifikation von Waren und Dienstleistungen, deren Menge, Preis und Wert.
  3. Summen-Teil
    Der Summenteil enthält die Gesamtsummen des Beleges, inkl. Steuerangaben.

Informationen zur Nutzung von Unterpositionen im Positions-Teil sind im Abschnitt 3.8 zu finden.

 

3 Prozessempfehlungen für die Rechnungsstellung

In der Projektgruppe eInvoice wurden einige generelle Empfehlungen bezüglich des Rechnungsprozesses im Zusammenhang mit der Anwendung von EANCOM® erarbeitet. Diese Empfehlungen wurden im Rahmen von EANCOM® 2002, insbesondere Teil 1 gemacht, der wichtige Hinweise zur Anwendung von EANCOM®-Nachrichten gibt.

 

3.1 Informationsfluss

Der empfohlene Informationsfluss im Rechnungsprozess basiert auf Best-Practice-Empfehlungen und sollte wie folgt angewendet werden:

1 - Generelle Empfehlung für den Informationsfluss

1 Bestellung >>> 1 Liefermeldung >>> 1 Rechnung

Die Projektgruppe empfiehlt generell dieses Szenario: Eine Rechnung bezieht sich auf eine Liefermeldung, die sich auf eine Bestellung bezieht.

2 - Empfehlung für Teillieferungen

Bei Teillieferungen werden die gesamten bestellten Waren auf mehrere Lieferungen an einen Ort verteilt, z. B. wenn die Kapazität eines Fahrzeugs nicht ausreicht.

1 Bestellung >>> "n" Liefermeldung >>> "n" Rechnung

In diesem Fall beziehen sich "n" Rechnungen auf "n" Liefermeldungen, die sich auf eine Bestellungen beziehen.

3 - Ausnahmefall zur Teillieferung

1 Bestellung >>> "n" Liefermeldung >>> 1 Rechnung

Die gesamte Lieferung wird in mehreren Teillieferungen durchgeführt (Anlieferung nicht zum selben Zeitpunkt). Ausnahmefall zur Teillieferung mit einer Rechnung zu mehreren Liefermeldungen.

Informationsfluss für die Rechnungsstellung mit Gutschrift

1 - Generelle Empfehlung

1 Bestellung >>> 1 Liefermeldung >>> 1 Rechnung >>> 1 Gutschrift

Die Projektgruppe empfiehlt in diesem Fall, dass sich eine Rechnung auf eine Liefermeldung bezieht, die Liefermeldung bezieht sich auf eine Bestellung. Die Gutschrift bezieht sich auf eine Rechnung.

2 - Empfehlung für Teillieferungen

1 Bestellung >>> "n" Liefermeldung >>> "n" Rechnung >>> "x" Gutschrift

In diesem Fall gibt es zu jeder Liefermeldung eine Rechnung. Die Anzahl der Gutschriften ("x") ist kleiner oder gleich "n". Bei Teillieferungen werden die bestellten Waren auf mehrere Lieferungen an einen Ort verteilt, z. B. wenn die Kapazität eines Fahrzeugs nicht ausreicht.

Nationale Kommentare

In Großbritannien und Schweden werden auf die gesamte Menge der Waren, die in einem bestimmten Zeitraum geliefert worden sind, gegebenenfalls Mengenrabatte gewährt. In diesem Fall kann eine Gutschrift verwendet werden, um die Beträge gegenüber den bereits gesendeten Rechnungen anzupassen.

In Schweden wird ein Abkommen benötigt, in dem die Handelspartner die eingesetzten Standards und andere Regeln für den Rechnungsaustausch definieren. Vor dem Datenaustauschprozess werden Informationen zur Beschreibung der Partner, Lieferadressen, Produkte und Preise sowie der zugehörige Mehrwertsteuersatz bestimmt und zwischen den Systemen der Handelspartner ausgetauscht. Partnerstammdaten und Produktkataloge/Preislisten werden vorab mit den zugehörigen Codes und Beschreibungen ausgetauscht, in den Transaktionsnachrichten wie Bestellungen, Bestellbestätigungen, Liefermeldungen und Rechnungen werden nur noch die codierten Idente verwendet. Vereinbarungen und Konditionen bezüglich der Zahlung werden ebenfalls vorab zwischen den Handelpartnern festegelegt und nicht in den Transaktionsnachrichten übertragen.

 

3.2 Belegarten bei der Rechnung

Die Belegart der Rechnungsnachricht wird im Datenelement 1001 des BGM-Segments codiert und übertragen. In der vorliegenden Empfehlung sind die folgenden Belegarten für den Nachrichtentyp INVOIC zugelassen:

Die Handelsrechnung ist die normale Rechnungsnachricht vom Lieferanten/Verkäufer an den Kunden/Käufer mit der die Zahlung für gelieferte Waren oder Dienstleistungen entsprechend den zwischen Verkäufer und Käufer vereinbarten Bedingungen gefordert wird.

Mit der Gutschriftsanzeige werden dem Begünstigten Gutschriftsinformationen bezüglich Waren- und Dienstleistungen übermittelt.

Mit der Belastungsanzeige wird der betroffene Partner über eine Belastung bezüglich Waren- und Dienstleistungen informiert.

Die Wertgutschrift dient zur Übermittlung von Gutschriftsinformationen bezüglich finanzieller Korrekturen, z. B. Boni.

Die Wertbelastung dient zur Übermittlung von Belastungsinformationen bezüglich finanzieller Korrekturen an den Partner.

Die korrigierte Rechnung ist eine Handelsrechnung, die gegenüber einer früheren Übertragung derselben Rechnung überarbeitete Informationen enthält.

Eine selbst ausgestellte Rechnung ist im sog. Gutschriftsverfahren eine Rechnung die der Zahlungspflichtige anstelle des Verkäufers ausstellt, zum Beispiel wenn Waren aus einem Konsignationslager am Standort des Käufers entnommen werden.

Die selbst ausgestellte Gutschriftsanzeige ist ein (elektronisches) Dokument, das angibt, dass der Kunde eine Gutschrift im Gutschriftsverfahren fordert.

Die Proformarechnung dient als vorläufige Rechnung. Sie enthält im Großen und Ganzen dieselbe Information wie die endgültige Rechnung, löst aber keine Zahlung aus. Die Proformarechnung wird normalerweise an denselben Empfänger (z. B. Käufer) gesendet wie die Rechnung und enthält Informationen aus dem Lieferschein (mit oder ohne Preisangaben, aber ohne Mehrwertsteuer).

 

3.3 Stammdatenabgleich

Daten die sich bei den Transaktionen nicht ändern, wie Lieferbedingungen, Liefer- und Zahlungsabkommen, Preise, Klartextbeschreibung für ILN und EAN sollten Teil des zugehörigen Vertrages zwischen den Partnern sein und in den Systemen der beteiligten Partner zugänglich sein. Jedes Produkt muss mit seiner EAN identifiziert (und barcodiert) sein. In bestimmten Fällen können zusätzliche Informationen, wie Artikeltext, trotzdem übertragen werden, wenn die zugehörigen Stammdaten nicht verfügbar sind, z. B. wenn ein Zentralregulierer einbezogen wird. In Frankreich müssen Informationen zu Artikelbeschreibung und Partnerstammdaten (Name und Adresse) aus gesetzlichen Gründen in jedem Fall zusätzlich zu EAN und ILN immer in Rechnungen übermittelt werden.

 

3.4 Preis- und Betragsangaben

Numerische Datenelement-Werte, wie Preise und Beträge werden als positiv angenommen. Obwohl ein Abzug vom Begriff her negativ ist, wird dieser als positiver Wert dargestellt, z. B. sind in einer Gutschrift alle Werte positiv, die Anwendungssoftware wird jedoch aufgrund des codierten Nachrichtennamens (DE 1001) alle Werte ins Negative umwandeln. Zusätzlich weisen Kombinationen aus Datenelementen und Codewerten darauf hin, dass Werte als negativ verstanden werden müssen, z. B. Datenelement 5463 mit Codewert 'A', Abschlag, in einem ALC-Segment der Rechnung.

Falls ein Wert negativ angegeben werden soll, muss ihm unmittelbar ein Minuszeichen vorangestellt werden, z. B. -112. Das Minuszeichen wird bei der Ermittlung der maximalen Länge eines Datenelements nicht mitgezählt.

In vielen Ländern werden Beträge in Euro angegeben und eine Rundung der Beträge ist nicht notwendig. Wenn Rundungsregeln angewandt werden, so wird nach mathematischen Regeln gerundet.

Beispiele:
0,344 = 0,34
0,346 = 0,35
0,345 = 0,35

Trotzdem wird von einigen Handelspartnern eine oder mehrere Ziffer(n) abgeschnitten anstatt mathematische Rundung anzuwenden, z. B. 0,596 = 0,59 (0,60 gerundet). Es wird empfohlen nur eine der beiden Methoden anzuwenden, wobei mathematische Rundung grundsätzlich die bevorzugte Option sein sollte, da Abschneiden von Ziffern nicht in allen Ländern angewandt werden kann.

 

3.5 Zahlungskonditionen

Zahlungskonditionen können im Kopf-Teil der Rechnung in der Segmentgruppe 8 (PAT-PCD-MOA) angegeben werden. Folgende Zahlungskonditionen werden im Rahmen dieser Empfehlung angewandt:

Es wird empfohlen, dass Zahlungskonditionen und Lieferbedingungen vorab in Verträgen zwischen den Handelspartnern festgelegt werden und nicht in Transaktionsnachrichten wie Bestellung oder Rechnung übertragen werden.

 

3.6 Zu- und Abschläge

Wenn in einer Rechnung Zu- und/oder Abschläge angegeben werden, so sind die bereits in den Preisen und Beträgen enthalten, wenn Nettokalkulation angewandt wird. In diesem Fall ist es nicht notwendig Zu- und Abschläge anzugeben. Werden sie trotzdem übermittelt, so geschieht dies zu Informationszwecken, um die Kalkulation nachzuvollziehen. Wenn Bruttokalkulation angewandt wird, so enthalten die Preise und Beträge keine Zu- und Abschläge.

Die Art der Zu- und Abschläge wird zwischen des Handelspartnern bilateral vereinbart. Sie können im Datenelement 1230 des ALC-Segments als bilateral vereinbarter Text und/oder codiert im Datenelement 7161 angegeben werden.

Zusätzliche Informationen zur Anwendung von Zu- und Abschlägen in Schweden:

Abschläge: In den Bereichen Handel und im öffentlichen Sektor in Schweden wird ein Rahmenabkommen bezüglich Abschlägen vereinbart. Abschläge sollen immer im Vertragspreis enthalten sein. Nur Nettopreise (inkl. Abschläge) werden in Preislisten und Rechnungen übertragen. Es sind nur drei Arten von Rabatten definiert: Mengenrabatt, Rechnungsrabatt und periodischer Mengenrabatt.

Mengenrabatte werden in einer stufenweise aufgebauten Preisliste angegeben, wobei eine niedrigste und höchste Menge für jede Stufe der Preisliste existiert. Informationen zu Mengenrabatten können nur über die Preisliste bestimmt werden. Der Rechnungsrabatt bezieht sich auf die tatsächlich fakturierte Menge und errechnet sich aus dem Wert der gelieferten Waren wie es vorab vereinbart wurde. Der periodische Mengenrabatt wird periodisch gemäß Abkommen bestimmt und über eine Gutschrift reguliert.

Zuschläge: Zuschläge sind, falls vorhanden, immer im Nettopreis enthalten. Wenn Frachtgebühren vereinbart sind, so werden die Netto-Gebühren und die Mehrwertsteuer separat dargestellt.

Anwendung von Zu- und Abschlägen

Die Angabe mehrerer Ebenen für Zu- und Abschlagsinformationen ist in EANCOM®-Nachrichten auf Nachrichtenebene und Positionsebene möglich. Das wird durch die Anwendung der ALC-Segmentgruppe ermöglicht, die normalerweise weitere Segmentgruppen enthält, in denen die tatsächlichen Zu- und Abschläge spezifiziert werden (z. B. QTY-RNG, MOA-RNG usw.).

Wenn eine Nachricht oder ein einzelnes Produkt auf verschiedenen Ebenen Zu- und Abschlägen unterworfen ist, z. B. 10 % auf Bestellmengen zwischen 1.000 und 2.000 Einheiten, 10.000 EUR an Handhabungsgebühren usw., wird empfohlen, jeden einzelnen Zu- oder Abschlag in einer separaten Wiederholung der ALC-Gruppe darzustellen; die tatsächlichen Zu- und Abschläge werden in den Untergruppen der ALC-Segmentgruppe angegeben.

Zusätzlich ist es von enormer Wichtigkeit, die Reihenfolge der Berechnung mehrerer Zu- und Abschläge anzugeben, um ein korrektes Ergebnis sicherzustellen. Dies wird durch die Anwendung des Datenelements 1227 im ALC-Segment ermöglicht.

Beispiel:

ALC+A+++1+ADS' Abschlag für die Bestellung einer vollständigen Palette wird als erstes berechnet
PCD+3:15' Der Abschlag beträgt 15 %
ALC+A+++2+TD' Der Handelsrabatt wird als zweites berechnet.
MOA+204:4000:EUR' Der Rabattbetrag ist 4000 Euro.

Hinweis: Zu- und Abschläge auf Kopfebene einer Nachricht sind unabhängig von denen auf Positionsebene, d. h. eine ALC-Gruppe auf Positionsebene überschreibt NICHT eine ALC-Gruppe auf Kopfebene.

 

3.7 Mengen ohne Berechnung

In machen Fällen werden Rabatte in Form von Freimengen gewährt, z. B. 100 Flaschen Körperlotion werden berechnet und zusätzlich 10 Flaschen ohne Berechnung geliefert. In solchen Fällen gibt es gemäß dem Prozess verschiedene Möglichkeiten der Darstellung in der INVOIC-Nachricht.

Wenn in derselben Positionszeile die gelieferte Menge (QTY+46...) und die Menge ohne Berechnung (QTY+192...) angegeben wird, so ist die Freimenge in der gelieferten Menge enthalten. Wenn hierfür zwei Positionszeilen mit derselben EAN genutzt werden, eine für die gelieferte Menge und eine für die Freimenge, so ergibt sich die Gesamtmenge aus der Addition der Menge der beiden QTY-Segmente.

Die Nutzung von mehr als einem QTY-Segment in einer Position im Positionteil der INVOIC-Nachricht muss zwischen den Handelspartnern bilateral vereinbart werden, da nicht alle Inhouse-Systeme in der Lage sind, mehr als eine Mengenangabe pro Position zu verarbeiten.

 

3.8 Unterpositionierung

Die Identifikation von Produkten geschieht durch die Anwendung des EANCOM®-Nachrichtentyps "Preisliste/Katalog" (PRICAT). Wann immer es möglich ist, sollten alle Produkte oder Dienstleistungen eindeutig durch eine EAN/GTIN identifiziert und als Position im LIN-Segment übertragen werden. In EANCOM® ist es jedoch auch möglich, die wesentlichen Bestandteile eines Produkts durch Verwendung von Unterpositionen zu identifizieren, z. B. ein Behälter, der mehrere unterschiedliche Produkte enthält, die auf Unterpositionsebene identifiziert werden. Unterpositionen sollen nur zur Darstellung unterschiedlicher Produkte zueinander benutzt werden, nicht zur Identifikation des gesamten Produktes an sich.

Jede EANCOM®-Nachricht enthält eine Belegnummer und Positionsnummern, die innerhalb der Nachricht eindeutig sind und das Wiederfinden von Informationen in späteren EANCOM®-Nachrichten sowie dem Aufbau von Verarbeitungsdateien ermöglichen. Innerhalb der EANCOM®-Nachrichten wird der Aufbau komplexer Konfigurationen durch die Verbindung der Positionsnummern in Verbindung mit der Unterpositionskennzeichnung im LIN-Segment ermöglicht. EANCOM® empfiehlt, die Positionsnummern im Datenelement 1082 des LIN-Segments sequenziell zu vergeben und bei jeder neuen Nachricht mit 1 zu beginnen.

Die Unterpositionierung in der INVOIC-Nachricht wird nur in einigen Ländern angewandt, da die Informationen zu standardisierten Displays/Sortimenten oder Dienstleistungen in der Nachricht Preisliste/Katalog angegeben werden kann. Über Unterpositionierung können auch verschiedene Mehrwertsteuersätze zu einem Produktpaket (z. B. Buch und CD) dargestellt werden.

Wenn Unterpositionierung in der INVOIC-Nachricht übermittelt werden sollen, so wird die nachfolgende Struktur empfohlen, um Sortimente und Konsumenteneinheiten darzustellen:

1. Positions-Teil für die fakturierte Einheit
Dieser Positions-Teil muss in der Nachricht ohne Unterpositionsinformation in allen Ländern verwendet werden.

2. Positions-Teil für die Verbrauchereinheit
Dieser Positions-Teil kann in der Nachricht verwendet werden (anwenderabhängig auch muss), um Konsumenteneinheiten in der fakturierten Einheit zu beschreiben (z. B. Schirme, die sich in einem Karton befinden).

3. Positions-Teil für nicht fakturierte Sortimentsinhalte
Dieser Positions-Teil wird nur dann in der Nachricht verwendet, wenn es sich bei der fakturierten Einheit im ersten Positions-Teil um Displays oder Sortimente handelt, deren detaillierte Inhalte gelistet werden; z. B. unterschiedliche Schirmmodelle in einem Karton.

4. Positions-Teil für fakturierte Sortimentsinhalte
Dieser Positions-Teil wird nur dann in der Nachricht verwendet, wenn es sich im ersten Positions-Teil um Displays oder Sortimente handelt die nicht berechnet, sondern deren einzelne Inhalte fakturiert werden; z. B. wenn die enthaltenen Produkte unterschiedlichen Umsatzsteuersätzen unterliegen.

Bezüglich weiterer Informationen zur Unterpositionierung wird an dieser Stelle auf das EANCOM®-Handbuch verwiesen.

 

4. Gesetzliche Anforderungen an Rechnungen

Eine Rechnung erfüllt zwei Funktionen:

  1. Eine Rechnung ist eine vom Verkäufer erstellte Liste von Waren oder Dienstleistungen, die z. B. Preise, Mengen und weitere Angaben enthält und als Zahlungsaufforderung an den Käufer gesendet wird.
  2. Eine Rechnung ist ein Dokument im nationalen Umsatzsteuersystem, dass den vom Verkäufer verlangten Mehrwertsteuerbetrag beweist und dem Käufer den Vorsteuerabzug erlaubt.

In der EU-Richtlinie 2001/115/EG vom 20. Dezember 2001 wurde der Schwerpunkt auf die umsatzsteuerliche Funktion einer Rechnung gesetzt. Im Datenaustausch zwischen Unternehmen ist die Rechnung Bestandteil des Geschäftsprozesses. Zusätzlich zu den steuerrechtlichen Anforderungen enthält eine Rechnung kaufmännische Angaben. Beide Anforderungen werden im Rahmen dieser Empfehlung abgedeckt.

Die EU-Richtlinie hat gemeinsame Mindestanforderungen in der europäischen Union bezüglich der inhaltlichen Angaben in einer Rechnung definiert. Für die Implementierung muss überprüft werden, wie die EU-Richtlinie in nationales Recht umgesetzt wurde und welche Anforderungen bestehen. Gemäß der EU-Richtlinie müssen folgende (Mindest-) Angaben in einer Rechnung enthalten sein:

Regelungen für die Übermittlung von elektronischen Rechnungen:

Die EU-Richtlinie erlaubt grundsätzlich zwei Arten der elektronischen Übermittlung von Rechnungen:

Trotz dieses gemeinsamen europäischen Rahmens existieren verschiedene nationale Umsetzungen bezüglich elektronischer Rechnungen. Darüber hinaus gibt es einigen Ländern weitere Möglichkeiten der elektronischen Übermittlung.

Grundsätzlich ist festzuhalten, dass bei der Übermittlung von Rechnungen von einem Mitgliedsstaat in einen anderen Mitgliedsstaat, die nationalen gesetzlichen Regelungen des Rechnungsausstellers, d. h. der Verkäufers/Lieferanten anzuwenden sind.

Die nachfolgende Tabelle zeigt die Implementierung in den beteiligten Ländern:

Land Anforderungen an elektronische Rechnungen mit Signatur Anforderungen an elektronische Rechnungen via EDI Anforderungen an elektronische Rechnungen über andere Methoden
Dänemark Fortgeschrittene elektronische Signatur Wenn Rechnungen über einen VAN (als Dritten) gesendet werden, sind keine zusätzlichen Sicherheitsmaßnahmen notwendig. Wenn Rechnungen über andere Methoden als VAN versendet werden, sind Verschlüsselungstechnologien (Signatur) notwendig.
Deutschland Qualifizierte elektronische Signatur, basierend auf einem qualifizierten Zertifikat einer natürlichen Person, erstellt mit einer sicheren Signaturerstelleinheit. EDI-Übertragung gemäß EU-Richtlinie (s.o.). Zusätzlich wird ein zusammenfassendes Dokument (Sammelabrechnung) verlangt (versendet in Papierform, Standardfax oder mit qualifizierter Signatur). Nicht zulässig
Frankreich Fortgeschrittene elektronische Signatur EDI-Übertragung gemäß EU-Richtlinie (s.o.). Zusätzlich wird ein zusammenfassendes Dokument verlangt. Dieses zusätzliche Dokument wird nicht übermittelt, das Rechnungstool beim Sender und Empfänger erstellt dieses automatisch. Bei Prüfungen werden diese beiden Listen verglichen.Bei Übertragung mit EDIINT AS2 gemäß der GS 1 Empfehlung sind keine zusätzlichen Dokumente notwendig.  
Großbritannien Keine besonderen Anforderungen Keine besonderen Anforderungen Unter der Voraussetzung, dass die Anwender ein akzeptables Niveau an Authentizität und Integrität nachweisen können, entweder mit Signatur, entsprechenden Sicherheitsmechanismen in der End-to-end-Kommunikationsinfrastruktur oder durch entsprechende interne Prozesse, ist elektronische Rechnungsübertragung zulässig.
Niederlande Fortgeschrittene elektronische Signatur EDI-Übertragung gemäß EU-Richtlinie (s.o.). Zusätzlich wird ein zusammenfassendes Dokument (het afstemmingsoverzicht) in Papierform verlangt. Für dieses Dokument gelten dieselben Regeln wie für eine Papierrechnung. Weitere Übertragungsmethoden sind möglich, insofern sie mit den Finanzbehörden vereinbart sind.
Österreich Fortgeschrittene elektronische Signatur EDI-Übertragung gemäß EU-Richtlinie (s.o.). Zusätzlich wird ein zusammenfassendes Dokument verlangt (versendet in Papierform, Standardfax oder mit qualifizierter Signatur). Nicht zulässig
Schweden Keine besonderen Anforderungen Keine besonderen Anforderungen  
Schweiz(nicht EU) Gemäß EIDI-V (Nationales schweizerisches Gesetz, dass die Übertragung und Archivierung von elektronischen Rechnungen regelt) ist ein qualifiziertes Zertifikat Class 3 notwendig. (siehe Link) Keine speziellen Anforderungen an die Syntax, für Übertragung ist eine qualifizierte Signatur gemäß EIDI-V vorgeschrieben (siehe Link). Nicht zulässig

Zusätzliche Informationen bezüglich EDI-Rechnungen in Großbritannien:

In Großbritannien, wird ein zusammenfassendes Dokument als Teil der Rechnungsübertragung im Rahmen des UN/EDIFACT-Standards gesendet. Hierfür wurde die Nachricht TAXCON (TAX CONtrol) entwickelt, die in einem Batch-Rechnungsdatenaustausch normalerweise nach der letzten INVOIC-Nachricht am Ende der Übertragungsdatei eingefügt wird.

Kurz gesagt, werden in der TAXCON-Nachricht die vollständigen Namen und Adressen und die USt-ID-Nummern der Partner übermittelt, damit in den INVOIC-Nachrichten codierte Identifikationen (z. B. ILN) verwendet werden können und die USt-ID-Nummer nicht zusätzlich angegeben werden muss, was nach Maßgabe der EU-Richtlinie zulässig ist. Die TAXCON enthält auch Angaben zur Anzahl der enthaltenen Nachrichten (nach Nachrichtenart, z. B. werden Rechnungen und Gutschriften in derselben Übertragungsdatei separat gezählt) und die Gesamtsummen zum steuerpflichtigen Betrag und Umsatzsteuerbetrag, aufgeschlüsselt nach Steuersätzen.

Der Lieferant sendet die TAXCON, als Teil der Übertragungsdatei, an den Handelspartner. Der Empfänger rechnet die relevanten Beträge der einzelnen INVOIC-Nachrichten zusammen und vergleicht diese mit den Gesamtsummen in der TAXCON. Hiermit wird sichergestellt, dass keine Daten während der Übertragung verändert wurden oder verloren gegangen sind.

In jedem Fall (bei Sender und Empfänger), wird die TAXCON-Nachricht genutzt, um ein zusammenfassendes Dokument zu erzeugen. Beim Lieferanten zeigt das zusammenfassende Dokument nur die Gesamtsummen der übermittelten Daten. Beim Empfänger enthalten die zusammenfassenden Dokumente sowohl vom Lieferanten übermittelten Gesamtsummen als auch die Kontrollwerte des Empfängers.

<<< zurück nach oben ^
  © GS1 Europe 2005