Durchsuchbare Dokumentation aufrufen | Zurück zur Dokumentationsübersicht

Navigation: Dokumentationen agorum core > agorum core Module und Plugins > Dokument | E-Rechnung

E-Rechnungsformate, Versionen und Profile

Hinweis: Diese Dokumentation bezieht sich auf die aktuellste Version des Plugins Dokument | E-Rechnung. Aktualisieren Sie das hier beschriebene Plugin, um die Dokumentation verwenden zu können.

Diese Seite beschreibt, welche E-Rechnungsformate Dokument | E-Rechnung lesen, prüfen und erstellen kann, welche Versionen und Profile dabei verwendet werden und wie Sie das Profil für ZUGFeRD-Rechnungen steuern. Die Angaben richten sich an Entwickler und Administratoren, die Workflows oder Skripte für E-Rechnungen einrichten.

Überblick über die Formate

Alle unterstützten Formate beruhen auf der europäischen Norm EN 16931. Sie unterscheiden sich in der Syntax (UBL oder CII), im Träger (reines XML oder PDF mit eingebettetem XML) und in den Geschäftsregeln, die zusätzlich zur Norm gelten.

Format-ID Format Syntax / Träger Version beim Erstellen Typischer Einsatz
xrechnung_ubl XRechnung (UBL) XML, OASIS UBL 2.1 (Invoice oder CreditNote) XRechnung 3.0 Rechnungen an öffentliche Auftraggeber (B2G), zunehmend B2B
xrechnung_cii XRechnung (CII) XML, UN/CEFACT Cross Industry Invoice D16B XRechnung 3.0 wie XRechnung (UBL); der Empfänger bestimmt die Syntax
zugferd_cii ZUGFeRD / Factur-X PDF/A-3b mit eingebetteter CII-Datei factur-x.xml ZUGFeRD 2.x, Profil EXTENDED (Voreinstellung) oder EN 16931 B2B; die Rechnung bleibt zusätzlich als PDF lesbar
peppol_ubl Peppol BIS Billing 3.0 XML, OASIS UBL 2.1 Peppol BIS Billing 3.0 Versand über das Peppol-Netzwerk, grenzüberschreitend in Europa

Die Format-ID geben Sie bei allen Funktionen der JavaScript-Bibliothek agorum.electronic.invoicing/js/lib/e-invoice und im Workflow-Knoten E-Rechnung aus normalisierten Daten erstellen an. Die Funktion check liefert sie beim Lesen als type zurück.

Hinweis: Die Auswahlliste im Workflow-Knoten zeigt die Formate als ZUGFeRD V2.2 (CII), X-Rechnung V3.0 (CII), X-Rechnung V3.0 (UBL) und Peppol BIS3 Invoice. Die Versionsangabe bei ZUGFeRD bezeichnet die Version, mit der das Format eingeführt wurde. Maßgeblich für das erzeugte Dokument ist die Spezifikationskennung (BT-24), siehe unten.

Spezifikationskennungen beim Erstellen

Jede E-Rechnung trägt eine Spezifikationskennung (BT-24) und eine Geschäftsprozesskennung (BT-23). Daran erkennt der Empfänger, nach welchen Regeln er die Rechnung prüfen muss. Dokument | E-Rechnung schreibt folgende Werte:

Format-ID BT-24 (Spezifikationskennung) BT-23 (Geschäftsprozess) Übersteuerbar
xrechnung_ubl urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 ja, über agorum_accounting_document_function_code (BT-24) und agorum_accounting_document_version_id (BT-23)
peppol_ubl wie xrechnung_ubl, sofern nicht gesetzt; für Peppol BIS: urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0 urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 ja, wie bei xrechnung_ubl
xrechnung_cii urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 BT-24 nein; BT-23 über den Datenschlüssel agorum_accounting_document_business_process_id
zugferd_cii Profil extended: urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended
Profil en16931: urn:cen.eu:en16931:2017		 urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 BT-24 über das Profil (siehe Profilsteuerung); BT-23 wie bei xrechnung_cii

Achtung: Das Format peppol_ubl verwendet denselben UBL-Generator wie xrechnung_ubl. Wenn Sie eine Rechnung nach Peppol BIS Billing 3.0 versenden wollen, setzen Sie agorum_accounting_document_function_code ausdrücklich auf urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0. Ohne diese Angabe entsteht eine XRechnung-Kennung, und die Rechnung wird gegen die XRechnung-Regeln geprüft.

Unterstützte Formate und Versionen beim Lesen

Beim Lesen (check, parse, validateInvoice) erkennt Dokument | E-Rechnung das Format am Wurzelelement und an der Spezifikationskennung:

Eingang Erkennungsmerkmal Ergebnis (type)
XML mit Wurzelelement Invoice oder CreditNote (UBL) UBL-Namensraum xrechnung_ubl – auch Peppol-BIS-Rechnungen werden mit diesem Typ gemeldet; die passende Prüfung wählt der Validator an der Spezifikationskennung
XML mit Wurzelelement CrossIndustryInvoice (CII) Spezifikationskennung enthält urn:factur-x.eu:1p0 oder urn:zugferd.de:2p0 zugferd_cii
XML mit Wurzelelement CrossIndustryInvoice (CII) andere Spezifikationskennung, etwa XRechnung oder urn:cen.eu:en16931:2017 xrechnung_cii – das gilt auch für eine einzelne ZUGFeRD-XML im Profil EN 16931 ohne PDF
PDF eingebettete Datei factur-x.xml, zugferd-invoice.xml, ZUGFeRD-invoice.xml oder xrechnung.xml zugferd_cii
XML mit Wurzelelement CrossIndustryDocument ZUGFeRD 1.0 check: valid: false mit Hinweis in message; parse und validateInvoice: Fehler No supported e-invoicing format found. The given invoice is ZUGFeRD 1.0. ZUGFeRD 2.0 and newer are supported.

Gelesen werden ZUGFeRD ab Version 2.0.1 in allen Profilen sowie XRechnung und Peppol BIS Billing 3.0 in beiden Dokumentarten (Rechnung und Gutschrift). Alle Formate werden in dieselben normalisierten Daten überführt, sodass Ihre Weiterverarbeitung nicht vom Eingangsformat abhängt.

Hinweis: Die ZUGFeRD-Profile MINIMUM und BASIC WL enthalten keine vollständigen Rechnungsangaben. Sie werden gelesen und geprüft, gelten nach dem BMF-Schreiben zur E-Rechnung in Deutschland aber nicht als E-Rechnung. Behandeln Sie solche Rechnungen wie eine sonstige Rechnung.

Prüfszenarien des Validators

Geprüft wird mit dem Validator der KoSIT (Koordinierungsstelle für IT-Standards). Dokument | E-Rechnung bringt den Validator und die Prüfkonfigurationen mit. Welches Prüfszenario greift, hängt von der Spezifikationskennung der Rechnung ab:

Spezifikationskennung der Rechnung Prüfszenario Geprüfte Regeln
enthält urn:xeinkauf.de:kosit:xrechnung_ (UBL oder CII) XRechnung 3.0.x Schema, EN-16931-Schematron, XRechnung-Schematron (BR-DE-*), inklusive XRechnung-Extension
enthält urn:fdc:peppol.eu:2017:poacc:billing:3.0 (UBL) Peppol BIS Billing 3.0 Schema, EN-16931-Schematron, Peppol-Regeln (PEPPOL-EN16931-*)
enthält urn:factur-x.eu:1p0 oder urn:zugferd.de:2p0 (CII) ZUGFeRD-Kaskade 2.4.0 → 2.3.2 → 2.2.0 → 2.0.1 Schema und Schematron des jeweiligen ZUGFeRD-Profils; die erste gültige Version zählt, ist keine gültig, wird der Bericht der ersten Stufe geliefert
sonstige (z. B. urn:cen.eu:en16931:2017) EN 16931 Schema und EN-16931-Schematron für UBL-Rechnung, UBL-Gutschrift oder CII

Mit dem Konfigurationswert strict: true prüfen validate und validateInvoice ZUGFeRD-Rechnungen gegen die strengen Varianten der ZUGFeRD-Szenarien (für ZUGFeRD 2.2.0 gibt es keine strenge Variante). Details zur Ergebnisstruktur finden Sie bei der Funktion validateInvoice.

Hinweis: Die Prüfkonfigurationen werden mit dem Plugin ausgeliefert und mit Plugin-Updates aktualisiert. Die KoSIT, das FeRD und OpenPeppol veröffentlichen mehrmals im Jahr neue Releases mit festen Stichtagen. Prüfen Sie im Changelog des Plugins, welche Releases enthalten sind, und halten Sie das Plugin aktuell, damit Ihre Prüfung dieselben Regeln anwendet wie die Empfänger Ihrer Rechnungen.

Profilsteuerung für ZUGFeRD

ZUGFeRD kennt mehrere Profile, die sich im Umfang der zulässigen Angaben unterscheiden. Dokument | E-Rechnung erzeugt ZUGFeRD-Rechnungen ab Version 1.1.0 des Plugins wahlweise in einem von zwei Profilen:

Wert Profil BT-24 Wann verwenden
extended (Voreinstellung) Factur-X / ZUGFeRD EXTENDED urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended Der Empfänger hat EXTENDED vereinbart oder benötigt die zusätzlichen Angaben, etwa abweichende Rechnungsempfänger oder Lieferadressen je Position.
en16931 ZUGFeRD EN 16931 (früher COMFORT) urn:cen.eu:en16931:2017 Beliebige gewerbliche Empfänger ohne besondere Vereinbarung. Empfänger, die gegen das EN-16931-Schema prüfen, lehnen EXTENDED-Rechnungen mit einem Schema-Fehler ab.

Profil festlegen

Das Profil wird in dieser Reihenfolge bestimmt:

  1. Je Aufruf: Parameter profile bei createInvoice und createInvoiceRaw, etwa eInvoice.createInvoice({ data: data, format: 'zugferd_cii', profile: 'en16931', attachments: [pdf] }).
  2. Je Workflow-Knoten: Auswahlfeld Profil (nur ZUGFeRD) im Knoten E-Rechnung aus normalisierten Daten erstellen mit den Optionen Voreinstellung des Systems, EXTENDED (Factur-X) und EN 16931. Der Knoten übergibt das Profil sowohl an den vorgeschalteten Prüfschritt als auch an die Erstellung des ausgelieferten Dokuments, damit geprüft wird, was ausgeliefert wird.
  3. Systemweit: MetaDB-Eintrag zugferdProfile. Er gilt, wenn weder Aufruf noch Knoten ein Profil angeben: 
    MAIN_MODULE_MANAGEMENT/customers/agorum.electronic.invoicing/settings/zugferdProfile
    Als Wert tragen Sie extended oder en16931 ein. Der Eintrag ist nach der Installation nicht vorhanden; Sie legen ihn bei Bedarf an.
  4. Ohne Angabe: extended. Das entspricht dem Verhalten vor Version 1.1.0; ein Update allein ändert also nicht, was bestehende Workflows versenden.

Auswirkungen des Profils

Das Profil wirkt ausschließlich beim Format zugferd_cii. Eine XRechnung (xrechnung_cii, xrechnung_ubl) ist immer EN-16931-konform, weil XRechnung eine Einschränkung (CIUS) der EN 16931 ist; ein abweichendes Profil wird dort ignoriert und protokolliert.

Groß- und Kleinschreibung spielen keine Rolle. Ein unbekannter Wert, etwa ein Tippfehler im MetaDB-Eintrag, führt bei allen CII-Formaten (auch xrechnung_cii) zu dem Fehler Unknown profile: "…". Allowed values: "en16931", "extended".

Im Profil en16931 werden nur Elemente geschrieben, die das EN-16931-Schema zulässt. Folgende Angaben entfallen dann:

Ausgelassene Felder gehen nicht stillschweigend verloren: Sie werden protokolliert und im übergebenen Konfigurationsobjekt unter suppressed zurückgemeldet – als Liste von Feldnamen und Hinweisen oder null, wenn nichts ausgelassen wurde. Werten Sie suppressed aus, wenn Sie sicherstellen wollen, dass keine für den Empfänger wichtige Angabe fehlt. suppressed wird nur bei den CII-Formaten gefüllt.

Achtung: Eine Rechnung im Profil extended wird bei der Prüfung gegen die ZUGFeRD-Kaskade geprüft. Dabei laufen die CII-SR-Regeln des eingeschränkten EN-16931-Schemas nicht mit. „Keine Beanstandung“ bedeutet dort also nicht, dass ein Empfänger mit EN-16931-Prüfung die Rechnung annimmt. Nur im Profil en16931 prüft der Validator mit denselben Regeln wie diese Empfänger.

Welches Profil soll ich wählen?

Unterschiede zwischen CII- und UBL-Erzeugung

CII-Formate (xrechnung_cii, zugferd_cii) und UBL-Formate (xrechnung_ubl, peppol_ubl) werden von getrennten Generatoren erzeugt. Einige Funktionen gibt es derzeit nur im CII-Format:

Funktion CII / ZUGFeRD UBL / Peppol
Schema der elektronischen Adresse (BT-34-1, BT-49-1) über *_endpoint_scheme_id ja, ohne Angabe EM nein, immer EM (E-Mail)
Profilsteuerung und Rückmeldung suppressed ja nein
Leerzeichen am Anfang und Ende der Werte entfernen ja nein
Fehler bei unbrauchbarem Datumswert ja nein
Zahlungsstatus wird nicht in die Rechnung geschrieben ja nein, er wird als Zahlungskanal-Code geschrieben
USt-IdNr., die nur aus dem Länderpräfix besteht, wird unterdrückt ja nein
Lieferangaben (Lieferort, Lieferanschrift, Warenempfänger) ja nein, in Version 1.1.1 entsteht ein Schema-Fehler beim Element cac:Delivery; Lieferfelder für UBL leer lassen
Mehrere vorausgegangene Rechnungen (BT-25) nur die erste, Rest unter suppressed alle

Achtung: Für den Versand über das Peppol-Netzwerk brauchen Absender und Empfänger eine elektronische Adresse mit Peppol-Schema, etwa 0204 (Leitweg-ID) oder 9930 (USt-IdNr.). Das UBL-Format schreibt das Schema derzeit fest als EM. Lassen Sie den Zahlungsstatus (agorum_accounting_document_payment_status bzw. document_payment_status in agorum_accounting_document_payment_means) bei UBL-Rechnungen leer, da sonst ein ungültiger Code entstehen kann.

Spezifikationen