Page tree
Skip to end of metadata
Go to start of metadata

Als elektronischer Standard zur Übermittlung von Rechnungsdaten als PDF und in einer XML-Struktur wird ZUGFeRD  in der SHK-Branche für die Kommunikation zwischen Großhandel und Handwerk verwendet. In 2018 entwickelten Experten der Branchenverbände BVBS, DG Haustechnik und ZVSHK unter Federführung von ITEK eine einheitliche Implementierungsempfehlung.

Diese richtet sich an Lieferanten (Großhändler/Hersteller), die ZUGFeRD-Rechnungen an Handwerker senden möchten und an Hersteller von Handwerkersoftware, die diese ZUGFeRD Dateien einlesen und verarbeiten möchten. Mit dieser Implementierungsempfehlung als Grundlage können ZUGFeRD-Rechnungen optimal empfangen, eingelesen und verwendet werden.

Für die Übertragung von ZUGFeRD Rechnungen wurde ein Web-Service definiert, der den Abruf und das Quittieren des Empfangs von Rechnungen ermöglich. Der Web Service wurde offen gestaltet, so dass zukünftig auch weitere Dokumenttypen und Formate übertragen werden können. 

Abgrenzung

Diese Empfehlung behandelt nicht das ZUGFeRD-Format (z.B. PDF/A-3), sondern die Abbildung der Dateninhalte der in der ZUGFeRD-PDF enthaltenen XML-Datei, sowie den Transport der PDF-Datei. Sie ist als ergänzende Empfehlung zur ZUGFeRD Dokumentation zu verstehen. Die Empfehlung ist gedacht für Lieferanten (Großhändler/Hersteller), die ZUGFeRD-Rechnungen an Handwerker senden möchten und an Hersteller von Handwerkersoftware, die diese ZUGFeRD Dateien einlesen und verarbeiten möchten.

Präambel

Die Handwerker möchten eine elektronische Rechnung im ZUGFeRD Format bekommen, damit sie die Rechnung ordentlich und automatisch auf Projekte bzw. Kostenträger verbuchen können. Es geht dem Handwerker nicht nur um eine Buchungshilfe bei der Erfassung und um eine Archivierung, ohne zu scannen, sondern auch um eine inhaltliche, mengen- und preismäßige Rechnungsprüfung, sowie um eine Weiterverarbeitung der enthaltenen Artikelpositionsinformationen für die Weiterberechnung. Im Idealfall ermöglichen die enthaltenen Informationen eine vollständige „Dunkelbuchung“, d.h. die Verbuchung der Eingangsrechnung erfolgt ausschließlich und anhand der in der ZUGFeRD-XML enthaltenen Daten im Zusammenspiel mit den Daten der Handwerkersoftware.

Wichtigste Voraussetzung dafür ist eine qualifizierte Abbildung der Inhalte. Hierzu sollen möglichst alle Dateninhalte strukturiert übertragen werden. Eine Verwendung von textuellen Beschreibungen soll möglichst vermieden werden, da diese eine automatische Verarbeitung erschwert oder komplett verhindert.

Für eine vollständig automatische Verarbeitung sind neben den detaillierten Artikelpositionen vor allem die Referenzangaben in der ZUGFeRD-XML erforderlich. Mit diesen kann die Rechnung mit Vorgängen wie Bestellung und Lieferschein, sowie mit Projekten und Aufträgen im Handwerkerprogramm abgeglichen werden. Das ZUGFeRD Format und Regelwerk ist sehr umfangreich und flexibel. Es lässt sehr viele Freiheitsgrade zu, die diverse Möglichkeiten, Varianten und Interpretationen erlauben. Diese Empfehlung soll dafür sorgen, dass diese Zuordnungen ohne bilaterale Absprachen möglich sind und es keinen „Wildwuchs“ bei der Nutzung der diversen XML-Knoten und Felder gibt.

Weiterhin ist es für einen optimalen Workflow notwendig, einen einfachen, sicheren, automatisierten und allgemeingültigen Transport zu vereinbaren.

Diese Empfehlung dient als Erklärung, stellt jedoch keine Verpflichtung dar. Das Ziel soll sein, dass die Ersteller und Verarbeiter von ZUGFeRD-Rechnungen, die sich an diese hier beschriebenen Empfehlungen halten, davon ausgehen können, dass die ZUGFeRD-Rechnungen optimal empfangen, eingelesen und verwendet werden können.

Empfehlungen zur elektronischen ZUGFeRD Rechnung

Verwendetes ZUGFeRD-Profil

ZUGFeRD kennt drei Profile (BASIC, COMFORT, EXTENDED). Die drei Profile unterscheiden sich im Informationsgehalt und in der Stärke und Qualität der Strukturierung. Sie bauen aufeinander auf und enthalten immer mehr und besser strukturierte und verarbeitbare Informationen. Damit das in der Präambel benannte Ziel erreicht werden kann, ist das EXTENDED-Profil nötig.

• BASIC-Profil: Es eignet sich ausschließlich als Buchungshilfe und zur Archivierung, da es lediglich rudimentäre Daten für die Buchung (Netto, MwSt., Brutto, Rechnungsnummer und -datum), als auch Zahlungsinformationen in nur teilweise strukturierter Form enthält. Eine Rechnungsprüfung ist damit nicht möglich. Es sind Rechnungen und Gutschriften (im Sinne von Rechnungskorrekturen) möglich.

• COMFORT-Profil: Mit den zusätzlichen Informationen im COMFORT-Profil kann eine automatische Zuordnung zu einem Vorgang und somit auch für eine Rechnungsprüfung vorgenommen werden. Zusätzlich sind Wertrechnungen ohne Warenbezug möglich.

• EXTENDED-Profil: Das EXTENDED-Profil erlaubt noch bessere Referenzangaben, sowie weitere strukturierte Informationen. Es ist daher das empfohlene Format. Es beinhaltet zusätzlich steuerrechtliche Gutschriften. Wenn das EXTENDED-Profil benutzt wird, sollten nach Möglichkeit immer die hier zusätzlich verfügbaren TypeCodes benutzt werden, da diese Freitext Informationen strukturieren.

Sammelrechnungen

Sammelrechnungen sind Rechnungen, die sich auf mehrere Kommissionen oder auf verschiedene Lieferscheine beziehen. Grundsätzlich sind diese in ZUGFeRD möglich, da diese Angaben und Referenzen pro Position übertragen werden können. Die strukturierte Abbildung von Zwischensummen und Bereichen innerhalb der Rechnung ist nicht möglich.

Die Abbildung von Einzelrechnungen (zu einem Lieferschein und Bestellung) in ZUGFeRD wird dringend empfohlen. Eine Abbildung von Sammelrechnungen (zu mehreren Kommissionen, Lieferscheinen bzw. Bestellungen) ist grundsätzlich möglich. Alle Zu- und Abschläge sowie die Frachtangaben, die zu einer enthaltenen Rechnung gelten, müssen in diesem Fall als einzelne Positionen angegeben werden. Nur so können diese über die Referenzen zum Lieferschein bzw. zur Bestellung den einzelnen Positionen zugeordnet werden. Bei dieser Abbildung kann die Art des Zu- oder Abschlags bzw. der Facht nur im Text angegeben werden und geht als strukturierte Information verloren.

Referenzangaben

Innerhalb der Rechnung sind verschiedene Referenzen (z. B. Kommission, Referenz auf Lieferscheine usw.) relevant. Neben den fest definierten Referenzen auf Bestellung und Lieferschein können „zusätzliche Referenzen“ unter Angabe des Typs angegeben werden. Es ist wichtig, dass die Abbildung der Referenzen in jedem Fall eindeutig ist. Da die Referenzen auf Kopf- und Positionsebene angegeben werden können, sollten diese pro Art der Referenz nur auf Kopf- oder Positionsebene übertragen werden. Eine Mischform pro Art der Referenz wird explizit nicht empfohlen. Bei Übertragung von identischen Informationen pro Position soll die Übertragung auf Kopfebene erfolgen.

Sofern auf Positionsebene Referenzen mit Positionsnummern im Sinne von Lieferscheinpositionsnummer, Bestellpositionsnummer oder Kundenbestellungs-, LV-, Ausschreibungspositionsnummer verwendet werden, sollten die Referenzen nur auf Positionsebene angegeben und nicht auf Kopfebene wiederholt werden.

Folgende Empfehlungen werden ausgesprochen:

Referenz auf die Ursprungsrechnung bei einer Gutschrift

Die Angabe der Ursprungsrechnung in einer Gutschrift soll mit „AWR“ für „Ursprungsbelegnummer“ angegeben werden. In der Codierung ist die Art des Belegs nicht spezifiziert und ergibt sich erst aus dem referenzierten Beleg.

Referenz von Unterposition auf die Hauptposition (Set-Abbildung) innerhalb einer Rechnung

Die Referenz auf die Hauptposition innerhalb einer Rechnung wird mit „AWR“ für Ursprungsbeleg angegeben. Als Referenznummer wird die Rechnungsnummer angegeben.

Referenz von Unterposition auf die Hauptposition (Set-Abbildung) eines anderen Belegs

Die Referenz auf die Hauptposition eines anderen Belegs wird mit „AWR“ für Ursprungsbeleg angegeben. In der Codierung ist die Art des Belegs nicht spezifiziert und ergibt sich erst aus dem referenzierten Beleg.

Referenz auf den / die Lieferscheine bei Streckenlieferungen

Im Fall einer Streckenlieferung kann es zwei Lieferscheine geben, die referenziert werden können. Der Lieferschein des Rechnungsstellers soll als „DeliveryNoteReferencedDocument“ übertragen werden. Der Lieferschein des Herstellers soll als „zusätzliche Dokumentenreferenz“ (AdditionalReferencedDocument) mit dem Code „AAS“ für „Transportdokumenten-Nummer“ angegeben werden.

Angabe der Kommission

Die Angabe der Kommission kann auf Kopfebene im Element „Referenz des Käufers“ (BuyerReference) übertragen werden.

Auf Positionsebene kann die Übertragung als „Zusätzliche Dokumentenreferenz“ (AdditionalReferencedDocument) mit „AER“ für „Projektspezifikationsnummer“ angegeben werden.

Beteiligte Parteien (Trade Partys)

Grundsätzlich können die Parteien in zwei Gruppen unterschieden werden. Parteien, die am Zahlungsfluss beteiligt sind und weitere Parteien.

Die folgende Tabelle stelle die Einordnung dar.

Rolle

Erläuterung

Bezeichnung ZUGFeRD

Beteiligt am Zahlungsfluss

Anmerkung

Sender

Verkäufer

Lieferant, Rechnungsersteller

Seller

Ja

Standardmäßig ist der Verkäufer (=Leistungserbringer) gleichzeitig
Rechnungssteller, Lieferant und Zahlungsempfänger. Sind einzelne dieser Rollen an andere übertragen worden, müssen diese an gesonderten Stellen definiert werden.

Zahlungs-empfänger

Zusätzliche Rolle, falls abweichend.

Payee

Ja

-

Warenversender

Zusätzliche Rolle, falls abweichend.

ShipFromTradeParty

Nein

-

Empfänger

Käufer

-

Buyer

Ja

Standardmäßig ist der Käufer (=Leistungsempfänger) Warenempfänger, Rechnungsempfänger und Zahlungsverpflichteter. Sind einzelne dieser Rollen an andere übertragen worden, müssen diese an gesonderten Stellen definiert werden.

Rechnungs-empfänger

Zusätzliche Rolle, falls abweichend

Invoicee

Ja

-

Warenempfänger/
Leistungsort

-

ShipToTradeParty

Nein

-

Endempfänger

-

UltimateShipToTradeParty

Nein

-

Endverbraucher

-

ProductEndUserTradeParty

Nein

-

Kopfinformationen

Angaben zum Verkäufer (Seller)

Die Identifikation des Verkäufers kann über verschiedene Informationen erfolgen. Die folgende Tabelle stellt die Informationen dar.

Inhalt

Priorität

Anmerkung

Übertragung

Umsatzsteuer ID

Pflicht


Da für die Steuernummer keine einheitliche Schreibweise existiert, soll die Schreibweise genutzt werden, die bei der Vergabe vom zuständigen Finanzamt verwendet wurde. Verpflichtend ist nur eine Steuerangabe.

SpecifiedTaxRegistration

schemeID = „VA“

Steuernummer

SpecifiedTaxRegistration

schemeID = „FC“

Global Location Number

Ergänzend


GlobalID

schemeID = „0088“

D-U-N-S Nummer

Ergänzend

Data Universal Numbering System

GlobalID

schemeID = „0060“

Lieferanten ID beim Kunden

Ergänzend

Durch den Kunden zugewiesene „Lieferantennummer“. Diese sollte angegeben werden, wenn die vorherigen IDs im empfangenden System nicht eindeutig sind. Z.B. beim mandanten- oder projektspezifischen Speichern von Adressen.

ID

Es sollten möglichst alle vorhandenen Informationen angegeben werden, um die Wahrscheinlichkeit einer automatischen Verarbeitung beim Empfänger zu erhöhen. Die Angabe einer Bankverbindung ist nicht hinreichend für eine Identifikation.

Angaben zum Zahlungsempfänger (Payee)

Sofern der Zahlungsempfänger vom Verkäufer abweicht, kann dieser ebenfalls übermittelt werden. Die Identifikation kann über verschiedene Informationen erfolgen. Die folgende Tabelle stellt die Informationen dar.

Inhalt

Priorität

Anmerkung

Übertragung

Umsatzsteuer ID

Pflicht


Da für die Steuernummer keine einheitliche Schreibweise existiert, soll die Schreibweise genutzt werden, die bei der Vergabe vom zuständigen Finanzamt verwendet wurde. Verpflichtend ist nur eine Steuerangabe.

SpecifiedTaxRegistration

schemeID = „VA“

Steuernummer

SpecifiedTaxRegistration

schemeID = „FC“

Global Location Number

Ergänzend


GlobalID

schemeID = „0088“

D-U-N-S Nummer

Ergänzend

Data Universal Numbering System

GlobalID

schemeID = „0060“

Lieferanten ID beim Kunden

Ergänzend

Durch den Kunden zugewiesene „Lieferantennummer“. Diese sollte angegeben werden, wenn die vorherigen IDs im empfangenden System nicht eindeutig sind. Z.B. beim mandanten- oder projektspezifischen Speichern von Adressen.

ID

Es sollten möglichst alle vorhandenen Informationen angegeben werden, um die Wahrscheinlichkeit einer automatischen Verarbeitung beim Empfänger zu erhöhen. Die Angabe einer Bankverbindung ist nicht hinreichend für eine Identifikation.

Angaben zum Warenversender (ShipFromTradeParty)

Sofern der Warenversender oder der Abholort vom Verkäufer abweicht, kann dieser ebenfalls übermittelt werden. Die Identifikation kann über verschiedene Informationen erfolgen. Die folgende Tabelle stellt die Informationen dar.

Inhalt

Priorität

Anmerkung

Übertragung

Global Location Number

Ergänzend


GlobalID

schemeID = „0088“

D-U-N-S Nummer

Ergänzend

Data Universal Numbering System

GlobalID

schemeID = „0060“

Es sollten möglichst alle vorhandenen Informationen angegeben werden, um die Wahrscheinlichkeit einer automatischen Verarbeitung beim Empfänger zu erhöhen. Neben der Identifikation sollte die vollständige Adresse angegeben werden.

Angaben zum Käufer (Buyer)

Die Identifikation des Käufers kann über verschiedene Informationen erfolgen. Die folgende Tabelle stellt die Informationen dar.

Inhalt

Priorität

Anmerkung

Übertragung

Umsatzsteuer ID

Pflicht


Da für die Steuernummer keine einheitliche Schreibweise existiert, soll die Schreibweise genutzt werden, die bei der Vergabe vom zuständigen Finanzamt verwendet wurde. Verpflichtend ist nur eine Steuerangabe.

SpecifiedTaxRegistration

schemeID = „VA“

Steuernummer

SpecifiedTaxRegistration

schemeID = „FC“

Global Location Number

Ergänzend


GlobalID

schemeID = „0088“

D-U-N-S Nummer

Ergänzend

Data Universal Numbering System

GlobalID

schemeID = „0060“

Kundenummer GH

Ergänzend

Durch den Lieferanten zugewiesene „Kundennummer“. Diese sollte angegeben werden, wenn die vorherigen IDs im empfangenden System nicht eindeutig sind. Z.B. beim mandanten- oder projektspezifischen Speichern von Adressen.

ID

Es sollten möglichst alle vorhandenen Informationen angegeben werden, um die Wahrscheinlichkeit einer automatischen Verarbeitung beim Empfänger zu erhöhen.

Angaben zum Rechnungsempfänger (Invoicee)

Sofern der Rechnungsempfänger vom Käufer abweicht, kann dieser ebenfalls übermittelt werden. Die Identifikation kann über verschiedene Informationen erfolgen. Die folgende Tabelle stellt die Informationen dar.

Inhalt

Priorität

Anmerkung

Übertragung

Umsatzsteuer ID

Pflicht


Da für die Steuernummer keine einheitliche Schreibweise existiert, soll die Schreibweise genutzt werden, die bei der Vergabe vom zuständigen Finanzamt verwendet wurde. Verpflichtend ist nur eine Steuerangabe.

SpecifiedTaxRegistration

schemeID = „VA“

Steuernummer

SpecifiedTaxRegistration

schemeID = „FC“

Global Location Number

Ergänzend


GlobalID

schemeID = „0088“

D-U-N-S Nummer

Ergänzend

Data Universal Numbering System

GlobalID

schemeID = „0060“

Kundenummer GH

Ergänzend

Durch den Lieferanten zugewiesene „Kundennummer“. Diese sollte angegeben werden, wenn die vorherigen IDs im empfangenden System nicht eindeutig sind. Z.B. beim mandanten- oder projektspezifischen Speichern von Adressen.

ID

Es sollten möglichst alle vorhandenen Informationen angegeben werden, um die Wahrscheinlichkeit einer automatischen Verarbeitung beim Empfänger zu erhöhen.

Angaben zum Warenempfänger (ShipToTradeParty)

Sofern der Warenempfänger vom Käufer abweicht, kann dieser ebenfalls übermittelt werden. Die Identifikation kann über verschiedene Informationen erfolgen. Die folgende Tabelle stellt die Informationen dar.

Inhalt

Priorität

Anmerkung

Übertragung

Global Location Number

Ergänzend


GlobalID

schemeID = „0088“

D-U-N-S Nummer

Ergänzend

Data Universal Numbering System

GlobalID

schemeID = „0060“

Es sollten möglichst alle vorhandenen Informationen angegeben werden, um die Wahrscheinlichkeit einer automatischen Verarbeitung beim Empfänger zu erhöhen. Neben der Identifikation sollte die vollständige Adresse angegeben werden.

Angaben zum Endempfänger (UltimateShipToTradeParty)

Zu den Angaben des Endempfängers werden keine ergänzenden Empfehlungen ausgesprochen.

Angaben zum Endverbraucher (ProductEndUserTradeParty)

Zu den Angaben des Endverbrauchers werden keine ergänzenden Empfehlungen ausgesprochen.

Freitext auf Kopfebene

Auf die Verwendung von Freitexten, für wichtige Informationen, soll möglichst verzichtet werden, da diese eine automatische Verarbeitung erschweren oder komplett verhindern. Sie dienen höchstens zur Sicherstellung, dass Angaben auf der gedruckten Rechnung mit den Angaben in der XML übereinstimmen.

Referenz auf eine Bestellung

Die Referenz auf eine Bestellung kann über das Element „BuyerOrderReferencedDocument“ auf Kopfebene mit Datum der Bestellung und der Bestellnummer angegeben werden.

Referenz auf einen Lieferschein

Die Referenz auf einen Lieferschein kann über das Element „DeliveryNoteReferencedDocument“ auf Kopfebene mit Datum des Lieferscheins und der Lieferscheinnummer angegeben werden.

Kopfebene: Kommission

Zur Übertragung der Kommission wird auf Kopfebene die „Referenz des Käufers“ (BuyerReference) verwendet.

Da es das Element „BuyerReference“ auf Positionsebene nicht gibt, kann auf Positionsebene die Kommission über das Element „AdditionalReferencedDocument“ (siehe 3.11.5) angegeben werden. Das Element „AdditionalReferencedDocument“ darf auch auf Kopfebene benutzt werden, um über den „TypeCode“ und einem Datum auch andere strukturierte Referenzen im Sinne von Kommission zu übermitteln.

Zu- und Abschläge auf Kopfebene

Für alle Zu- und Abschläge sind die Angaben, ob es sich um eine Zu- oder Abschlag handelt (Trade_ ChargeIndicator) und der Betrag des Zu- oder Abschlags (ActualAmount), Pflicht. Zusätzlich wird empfohlen, den Grund des Zu- oder Abschlags als Code (ReasonCode) und Freitext (Reason) anzugeben. Weitere Informationen wie Berechnungs-Reihenfolgen, Rabatt in Prozent, Basisbetrag des Rabatts und Basismenge des Rabatts können angegeben werden, werden aber in der automatischen Rechnungsprüfung nicht genutzt und dienen nur zur Information.

Zahlungsbedingungen

Innerhalb der Angabe der Zahlungsbedingungen werden folgende Abbildungen empfohlen.

Nettozahlungsziel

Angabe des Nettozahlungsziels erfolgt mit Beschreibung und Datum.

<ram:SpecifiedTradePaymentTerms>
<ram:Description>Zahlbar ohne Abzug bis zum 20.07.2017</ram:Description>
<ram:DueDateDateTime>
<udt:DateTimeString format="102">20170720</udt:DateTimeString>
</ram:DueDateDateTime>
</ram:SpecifiedTradePaymentTerms>

Skonto mit fester Datumsangabe

Die Angabe des Skontos mit festem Datum erfolgt mit Beschreibung, Datum, Basiswert (inkl. Währung) und dem Prozentsatz.

<ram:SpecifiedTradePaymentTerms>
<ram:Description>Skonto 3% bis zum 30.06.2016</ram:Description>
<ram:DueDateDateTime>
<udt:DateTimeString format="102">20160630</udt:DateTimeString>
</ram:DueDateDateTime>
<ram:ApplicableTradePaymentDiscountTerms>
<ram:BasisAmount currencyID="EUR">2498.66</ram:BasisAmount>
<ram:CalculationPercent>3.00</ram:CalculationPercent>
</ram:ApplicableTradePaymentDiscountTerms>
</ram:SpecifiedTradePaymentTerms>

Skonto auf Basisdatum mit Zeitraum

Die Angabe des Skontos auf ein Basisdatum mit Zeitraum erfolgt mit Beschreibung, Basisdatum, Zeitraum (inkl. Einheit), Basiswert (inkl. Währung) und dem Prozentsatz.

<ram:SpecifiedTradePaymentTerms>
<ram:Description>Bis zum 30.06.2016 erhalten Sie 3,000 % Skonto</ram:Description>
<ram:ApplicableTradePaymentDiscountTerms>
<ram:BasisDateTime>
<udt:DateTimeString format="102">20160620</udt:DateTimeString>
</ram:BasisDateTime>
<ram:BasisPeriodMeasure unitCode="DAY">10</ram:BasisPeriodMeasure>
<ram:BasisAmount currencyID="EUR">3625.6400</ram:BasisAmount>
<ram:CalculationPercent>3.00</ram:CalculationPercent>
</ram:ApplicableTradePaymentDiscountTerms>
</ram:SpecifiedTradePaymentTerms>

Skonto mit fester Datumsangabe mit Basisdatum ohne Zeitraum

Die Abbildung ist technisch möglich, wird aber nicht empfohlen.

Skonto mit Angabe Fälligkeitsdatum und Fälligkeitstage

Die Abbildung ist technisch möglich, wird aber nicht empfohlen.

Informationen zur Position

Positionsnummer / Zeilennummer („AssociatedDocumentLineDocument/LineID“)

Die Positions- bzw. Zeilennummer muss auch im Falle einer Sammelrechnung eindeutig sein. Hierzu kann ggf. die Nummer des Lieferscheins oder der Bestellung vorangestellt werden.

Freitext zur Position („IncludedNote“)

Auf eine Verwendung von Freitexten soll möglichst verzichtet werden, da diese eine automatische Verarbeitung erschweren oder komplett verhindern.

Referenz auf eine Bestellung je Position

Die Referenz auf eine Bestellung kann über das Element „BuyerOrderReferencedDocument“ auf Positionsebene mit Datum der Bestellung und der Bestellnummer (ID) und ggf. der Positionsnummer (LineID) angegeben werden.

Referenz auf einen Lieferschein je Position

Die Referenz auf einen Lieferschein kann über das Element „DeliveryNoteReferencedDocument“ auf Positionsebene mit Datum des Lieferscheins, der Lieferscheinnummer (ID) und ggf. der Positionsnummer (LineID) angegeben werden.

Position: Kommission

In einer Sammelrechnung kann die Kommission auf Positionsebene als „Zusätzliche Dokumentenreferenz“ (AdditionalReferencedDocument) mit der Projektspezifikationsnummer (ReferenceTypeCode) „AER“ angegeben werden. Die Angaben zum Dokumentendatum und zur referenzierten Position (LineID) im Dokument können entfallen.

Referenz auf ein Leistungsverzeichnis (Ausschreibung)

Die Angabe der Referenz auf eine Ausschreibung soll als zusätzliche Dokumentenreferenz (AdditionalReferencedDocument) erfolgen. Als Art des Dokuments (ReferenceTypeCode“) soll „BD“ (Bid number) verwendet werden.

Da der Code „BD“ aktuell in der ZUGFeRD Dokumentation nicht ausdrücklich, in den zugrundeliegenden Standards aber enthalten ist, ist aktuell unklar, ob dieser verwendet werden darf. Vor diesem Hintergrund soll aktuell der Code „AER“ verwendet werden.

Da im Regelfall die Nummer der Ausschreibung beim Großhandel nicht bekannt ist, diese aber zwingend erforderlich ist, kann die Nummer (ID) mit dem Dummy Wert „LV“ angegeben werden.

Die Ordnungszahl wird als „Referenzierte Position“ (AdditionalReferencedDocument/LineID) vollständig angegeben.

Zu- und Abschlag zur Position

Die Angaben der Zu- und Abschläge stellen an der Position eine Unterstruktur zum Bruttopreis dar. Sofern Zu- oder Abschläge angegeben werden sollen, ist der Bruttopreis zwingend erforderlich.

Analog zum Kopf sind für alle Zu- und Abschläge die Angaben, ob es sich um einen Zu- oder Abschlag handelt (ChargeIndicator/Indicator), und der Betrag des Zu- oder Abschlags (ActualAmount) Pflicht. Zusätzlich wird empfohlen, den Grund des Zu- oder Abschlags als Code (ReasonCode) und Freitext (Reason) anzugeben. Die Angabe des Codes (ReasonCode) soll die Art des Zu- und Abschlags weidergeben. Nur so ist eine Unterscheidung, z. B. bei Materialzuschlägen, möglich.

Falls die Werte für Basisbetrag des Rabatts und Basismenge des Rabatts vom den Preisangaben abweichen, müssen diese mit angegeben werden, da die Zu- und Abschläge sonst nicht nachvollzogen werden können. Weitere Informationen wie Berechnungs-Reihenfolgen und Rabatt in Prozent können angegeben werden, werden aber in der automatischen Rechnungsprüfung nicht genutzt und dienen nur zur Information.

Materialzuschläge

Bei der Übertragung der Materialzuschläge muss in zwei Bereiche unterschieden werden. Zum einen muss innerhalb der Zu- und Abschläge die Summe des Zu- oder Abschlags angegeben werden, damit dieser in die Positionsberechnung einfließen kann. Dies soll mit dem Code „MC“ (Material surcharge) angegeben werden.

Da der Code „MC“ aktuell in der ZUGFeRD Dokumentation nicht ausdrücklich, in den zugrundeliegenden Standards aber enthalten ist, ist aktuell unklar, ob dieser verwendet werden darf. Vor diesem Hintergrund soll aktuell der Code „ADR“ verwendet werden.

In der Praxis werden Materialzuschläge teilweise nur informativ in der Rechnung angegeben. In diesem Fall ist der konkrete Zuschlag bereits im Bruttopreis enthalten. Die Angabe des Zuschlags kann dann in der XML Abbildung entfallen, sollte aber in den Produkteigenschaften genannt werden.

Weiterhin ist die Übertragung der Informationen zum Nachvollziehen der Materialzuschläge erforderlich. Diese sollen als Produkteigenschaften übertragen werden. Als Code soll „Material“ verwendet werden. Die Übertragung der Inhalte erfolgt im Element Value als json Struktur.

Die Angaben der Materialpreise, mit dem der Artikel vorkalkuliert wurde und der aktuell gilt, werden als reiner Wert angegeben. Beide beziehen sich auf die in den offiziellen Rohstoffnotierungen genutzten Angaben (z. B. pro 100 kg).

Beispiel:

• 50 Meter Kabel

• Preis 10.000 € pro 1000 m

• Kupfergewicht beträgt 80 kg pro 100 m

• Aluminiumgewicht beträgt 15 kg pro 100m

• Kupferpreis wurde mit 150 € pro 100 kg kalkuliert

• Der aktuelle Kupferpreis ist 300 € pro 100 kg

• Aluminiumpreis wurde mit 200 € (pro 100 kg) kalkuliert

• Der aktuelle Aluminiumpreis ist 250 € (pro 100 kg)


Abbildung im ZUGFeRD XML

Bruttopreis 10.000 € pro 1000 Meter

<ram:SpecifiedSupplyChainTradeAgreement>

<ram:GrossPriceProductTradePrice>

<ram:ChargeAmount currencyID="EUR">10000.0000</ram:ChargeAmount>

<ram:BasisQuantity unitCode="MTR">1000.0000</ram:BasisQuantity>


Materialzuschlag Kupfer

<ram:AppliedTradeAllowanceCharge>

<ram:ChargeIndicator>true</ram: ChargeIndicator>

<ram:BasisQuantity unitCode="MTR">100.000</ram: BasisQuantity>

<ram:ActualAmount currencyID="EUR">120.000</ram: ActualAmount>

<ram:ReasonCode>MC</ram: ReasonCode>

<ram:Reason>Materialzuschlag Kupfer</ram: Reason>

</ram:AppliedTradeAllowanceCharge>


Materialzuschlag Aluminium

<ram:AppliedTradeAllowanceCharge>

<ram:ChargeIndicator>true</ram: ChargeIndicator>

<ram:BasisQuantity unitCode="MTR">100.000</ram: BasisQuantity>

<ram:ActualAmount currencyID="EUR">7.500</ram: ActualAmount>

<ram:ReasonCode>MC</ram: ReasonCode>

<ram:Reason>Materialzuschlag Aluminium</ram: Reason>

</ram:AppliedTradeAllowanceCharge>

</ram:GrossPriceProductTradePrice>


Nettopreis 11.275 € pro 1000 Meter

<ram:NetPriceProductTradePrice>

<ram:ChargeAmount currencyID="EUR">11275.0000</ram:ChargeAmount>

<ram:BasisQuantity unitCode="MTR">1000.0000</ram:BasisQuantity>

</ram:NetPriceProductTradePrice>

</ram:SpecifiedSupplyChainTradeAgreement>


Menge

<ram:SpecifiedSupplyChainTradeDelivery>

<ram:BilledQuantity unitCode="MTR">50.0000</ram:BilledQuantity>

</ram:SpecifiedSupplyChainTradeDelivery>

Informationen zum Marterialzuschlag am Artikel

<ram:ApplicableProductCharacteristic>

<ram:TypeCode>MC</ram:TypeCode>

<ram:Description>Materialzuschlag Kupfer</ram:Description>

<ram:Value>

{

"Type": "RawMaterial",

"Value": {

"MaterialCode": "CU",

"WeightPart": "80",

"WeightPartUnit": "KGM",

"BaseValue": "100",

"BaseUnit": "MTR",

"QuotationBase": "150",

"QuotationCurrent": "300"

}

}

</ram:Value >

</ram:ApplicableProductCharacteristic>

<ram:ApplicableProductCharacteristic>

<ram:TypeCode>MC</ram:TypeCode>

<ram:Description> Materialzuschlag Aluminium</ram:Description>

<ram:Value>

{

"Type": "RawMaterial",

"Value": {

"MaterialCode": "AL",

"WeightPart": "15",

"WeightPartUnit": "KGM",

"BaseValue": "100",

"BaseUnit": "MTR",

"QuotationBase": "200",

"QuotationCurrent": "250"

}

}]

</ram:Value >

</ram:ApplicableProductCharacteristic>

Artikeltexte

Die in der Rechnung angegeben Artikelbezeichnung (Name) und Artikelbeschreibung (Description) sind so anzugeben, dass diese unabhängig voneinander den Artikel beschreiben und einzeln verwendet werden können.

Unter-Positionen

Die Abbildung von Unter-Positionen kann in zwei Fälle unterschieden werden.

Abbildung als eigenständige Positionen

Sofern die Unterpositionen auch auf der PDF Rechnung als eigenständige Positionen (mit Positionsnummer und eigenen Daten) ausgegeben werden, sollte dies auch in der XML erfolgen. An den Unter-Positionen ist eine Referenz zur Haupt-Position als „zusätzliche Dokumentenreferenz“ (AdditionalReferencedDocument) erforderlich. Als Art des Dokuments (ReferenceTypeCode) soll „OH“ (Reference number identifying the current invoice.) verwendet werden, um kenntlich zu machen, dass es sich um eine interne Referenz handelt.

Da der Code „OH“ aktuell in der ZUGFeRD Dokumentation nicht ausdrücklich, in den zugrundeliegenden Standards aber enthalten ist, ist aktuell unklar, ob diese verwendet werden darf. Vor diesem Hintergrund soll aktuell der Code „AWR“ verwendet werden.

Zusätzlich wird die Rechnungsnummer als „Dokumentennummer“ (ID) und die Positionsnummer als „Referenzierte Position“ (LineID) angegeben.

Abbildung als enthaltene Produkte

In Fällen, in denen die Unterpositionen in der PDF Rechnung nicht als eigenständige Positionen enthalten sind, können diese als „Detailinformationen zu enthaltenen Produkten“ (IncludedReferencedProduct) mit folgenden Werten angegeben werden.

• Globaler Identifier des Produktes (GlobalID)

• Artikelnummer des Verkäufers (SellerAssignedID)

• Artikelnummer des Käufers (BuyerAssignedID)

• Artikelbezeichnung (Name)

• Artikelbeschreibung (Description)

• Menge (UnitQuantity), enthalten inkl. Mengeneinheit (unitCode)

Sonderfall kaufmännische Gutschrift

Die Übertragung einer kaufmännischen Gutschrift ist in ZUGFeRD vorgesehen. Diese erfolgt als Rechnung mit negativen Werten. Alle Rechenregeln der Rechnung bleiben erhalten.

Auf Positionsebene werden der Brutto- und Nettopreis sowie ggf. Zu- und Abschläge positiv angegeben. Die Menge wird negativ angegeben. Hierdurch ergibt sich über die negative Menge und den Nettopreis eine negative Positionssumme.

In der Aufsummierung im Kopf ergeben sich automatisch die richtigen (negativen) Summen.

Wichtig ist, dass auf Kopfebene die Zahlungsbedingungen der ursprünglichen Rechnung ausgegeben werden. Hierfür ergeben sich ein negativer Basisbetrag („BasisAmount“) des Zahlungszuschlags und ein negativer Skontobetrag („ActualDiscountAmount“).

Übertragung der ZUGFeRD Rechnung

Für die Übertragung der ZUGFeRD Rechnung werden verschiedene Alternativen empfohlen.

Grundsätzlich ist es wichtig, dass pro Kunde nur ein Übertragungsweg genutzt werden kann. Eine Mischung innerhalb eines Kunden soll nicht unterstützt werden.

Weiterre Informationen erhalten Sie unter Dokumentenübertragung ZUGFeRD.

  • No labels