Rechnungen im ZUGFeRD-Format

Allgemein

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) ist ein standardisiertes Format für den elektronischen Austausch von Rechnungen.

Eine ZUGFeRD-Rechnung ist ein hybrides Format: Sie kombiniert ein PDF-Dokument im Format PDF/A-3 mit strukturierten Rechnungsdaten im XML-Format. Das PDF ist die Sichtkomponente und lässt sich wie jedes andere PDF öffnen und lesen. Gleichzeitig ist darin eine inhaltlich identische XML-Datei eingebettet, die von Softwaresystemen automatisch verarbeitet werden kann.

Der große Vorteil: Die Rechnung ist sowohl für Menschen lesbar als auch für Maschinen auswertbar. Rechnungsdaten können direkt in ein ERP- oder Buchhaltungssystem übernommen werden, ohne manuell erfasst zu werden. Das ermöglicht einen medienbruchfreien Rechnungsaustausch zwischen Unternehmen.

ZUGFeRD ist seit Version 2.1 technisch identisch mit dem französischen Standard Factur-X und entspricht der europäischen Norm EN 16931. Der Standard wird in verschiedenen Profilen angeboten (z. B. BASIC, EN 16931 oder EXTENDED), die sich im Umfang der enthaltenen Rechnungsdaten unterscheiden.

Bedeutung für die E-Rechnungspflicht

Seit dem 1. Januar 2025 müssen alle Unternehmen in Deutschland E-Rechnungen im inländischen B2B-Geschäftsverkehr empfangen können. Für den Versand gelten Übergangsfristen:

• Bis Ende 2026 dürfen Rechnungen noch als Papier oder, mit Zustimmung des Empfängers, als einfaches PDF verschickt werden.

• Für Unternehmen mit einem Vorjahresumsatz bis 800.000 Euro verlängert sich diese Frist bis Ende 2027.

• Ab dem 1. Januar 2028 ist der Versand von E-Rechnungen für alle Unternehmen verpflichtend.

Nicht jede ZUGFeRD-Rechnung erfüllt diese Anforderungen. Als E-Rechnung im steuerrechtlichen Sinne gelten nur Rechnungen, die der Norm EN 16931 entsprechen, also ab dem Profil BASIC. Die Profile MINIMUM und BASIC WL enthalten nicht alle erforderlichen Rechnungsangaben und gelten daher als sonstige Rechnung, nicht als E-Rechnung.

Im Folgenden wird beschrieben, wie ZUGFeRD in COGLAS verwendet wird und welche Einstellungen dafür erforderlich sind.

Wie ZUGFeRD funktioniert

• Hybrid-Prinzip: Eine XML-Datei mit allen Rechnungsdaten ist im PDF eingebettet.

• Rechtliche Norm: Ab dem Profil BASIC erfüllt ZUGFeRD die europäische Norm EN 16931 und gilt damit als E-Rechnung.

• Identisch mit Factur-X: International ist das Format unter dem Namen Factur-X bekannt.

Vorteile des Formats:

• Für Menschen: Die PDF-Ansicht ist gewohnt übersichtlich und ohne Spezialsoftware lesbar.

• Für Maschinen: Buchhaltungssysteme lesen die XML-Daten fehlerfrei und schnell aus.

• Einfacher Start: Das Format eignet sich gut, um die E-Rechnungspflicht im B2B-Geschäftsverkehr zu erfüllen.

Was müssen Sie als User tun?

Prüfung

Prüfen Sie zunächst, ob Sie den bzw. die Premium-Prozesse für Billing & Contract lizenziert (gemietet) haben. Stellen Sie anschließend sicher, dass Ihre COGLAS-Version ZUGFeRD unterstützt. Andernfalls wird lediglich ein herkömmliches PDF erzeugt.

In einer COGLAS-Version mit dem ZUGFeRD-Prozess wird die XML-Datei beim Download der Rechnung als PDF automatisch erzeugt und eingebettet. Damit die Datei vollständig und gültig ist, müssen vorher einmalig folgende Stammdaten und Einstellungen gepflegt werden:

1. Geschäftspartner Lagerbetreiber vollständig gepflegt

2. Geschäftspartner Rechnungsempfänger vollständig gepflegt, inkl. FibuKontonummer

3. Steuerschlüssel mit Tax Type Code, Tax Category Code und ggf. VATEX-Code

4. Zahlungsarten (Payment Methods) angelegt und der Rechnungsvorlage zugeordnet

5. Optional: IncludedNote für Hinweistexte

Einstellungen und Eingaben im COGLAS

Ordentliche (vollständige) Einträge im Geschäftspartner Lagerbetreiber

Pflegen Sie die Daten des Geschäftspartners Lagerbetreiber vollständig, denn viele der dort hinterlegten Angaben werden als Verkäuferdaten übermittelt, z. B. E-Mail, Telefonnummer und Bankverbindung. Wenn Sie per SEPA-Lastschrift einziehen, wird zusätzlich Ihre Gläubiger-Identifikationsnummer (BT-90) benötigt.

Ordentliche (vollständige) Einträge im Geschäftspartner Rechnungsempfänger

Das Feld IncludedNote am Rechnungsempfänger wird nicht ausgewertet (siehe Abschnitt IncludedNote).

Mitunter kann es vorkommen, dass beim Rechnungsempänger Name1,Name2 und Name3 gepflegt sind. Diese werden in der XML zusammen in das dort vorgegebene Feld Name hinterlegt.

Sind Name, Name2 und Name3 gepflegt, werden sie in der XML-Datei zusammen in das Feld Name (BT-44) geschrieben. Beispiel: „Der Musterempfänger“, „Abteilung Topsecret“ und „z. Hd. Herrn Mustermann“ ergeben den Namen „Der Musterempfänger Abteilung Topsecret z. Hd. Herrn Mustermann“.

COGLAS:

Zugferd XML

Name: “Der Musterempfänger Abteilung Topsecret z.hd.Herrn Mustermann”

FibuKontonummer

Am Rechnungsempfänger muss die FibuKontonummer gepflegt sein. Dies ist nicht die Nummer des Geschäftspartners.

IncludedNote

Das Feld IncludedNote (BT-22) nimmt alles auf, was auf einer Papierrechnung als Hinweistext stehen würde und für das es kein eigenes strukturiertes Feld gibt. Es ist ein freier Text zur gesamten Rechnung, nicht zu einer einzelnen Position.

Beispiele:

• ein Dankestext

• Angaben zu Registergericht, HRB-Nummer und Geschäftsführung

• ein Hinweis zur Aufbewahrungspflicht nach § 14b UStG

• Informationen zu einem Projekt oder Auftrag

IncludedNote kann an zwei Stellen gepflegt werden:

• • In der Rechnungsvorlage bzw. Rechnung: für zusätzliche Notizen zu einer bestimmten Rechnung, neues Feld include Note

  • 

  • Am Lagerbetreiber: für Hinweise, die auf allen Rechnungen erscheinen sollen.

Steuerschlüsseln

An jedem Steuerschlüssel müssen der Tax Type Code und der Tax Category Code gepflegt werden. Bei steuerbefreiten Umsätzen kommt der VATEX-Code hinzu.

Warum das nötig ist:Nach EN 16931 reicht die Angabe eines Steuerschlüssels wie „steuerfrei“ oder „Reverse Charge“ nicht aus. Für die Kategorien E, AE, K, G und O verlangt der Standard eine Begründung der Steuerbefreiung, entweder als Freitext (BT-120) oder als VATEX-Code (BT-121). Fehlt beides, schlägt die Prüfung der Geschäftsregeln fehl (z. B. BR-AE-10), und die Rechnung wird vom Empfängersystem abgelehnt.

Ausnahme Kategorie Z (Nullsatz): Hier darf nach Regel BR-Z-10 kein Befreiungsgrund angegeben werden. Steuerschlüssel mit Kategorie Z erhalten also keinen VATEX-Code.

Der Steuerschlüssel legt im System fest, dass keine Umsatzsteuer berechnet wird, aber nicht, warum. Deshalb wird jedem betroffenen Steuerschlüssel ein passender VATEX-Code fest zugeordnet. So liefert jede Rechnung die geforderte Begründung automatisch mit, ohne manuelle Erfassung.

Die drei Felder

Beispiel: Steuerschlüssel „Reverse Charge DL 19 %“

Erfassung in COGLAS

Die Einträge werden pro Steuerschlüssel in den Feldern TaxTypeCode, TaxCategoryCode und VATEX-Code gepflegt. Das ist auch per Import möglich.

Um Tippfehler zu vermeiden, stehen die aktuell gültigen VATEX-Codes als Dropdown-Auswahl zur Verfügung. Der ausgewählte Wert ist damit immer ein gültiger Code, kann aber fachlich falsch sein. COGLAS prüft nicht, ob die Kombination aus Tax Type Code, Tax Category Code und VATEX-Code stimmig ist. Dafür ist der User verantwortlich. Wenn Sie unsicher sind, sprechen Sie bitte mit Ihrer Buchhaltung oder Ihrem Steuerberater.

Payment Method/Zahlungsbedingung

Hinterlegen Sie anschließend die Payment Method. Diese finden Sie unter System in der Rubrik Billing & Contract.

Die Zahlungsart muss gepflegt und der Rechnungsvorlage zugeordnet werden, sonst kann keine gültige ZUGFeRD-Datei erstellt werden. Sie wird als standardisierter Code (UNTDID 4461) in die XML-Datei übernommen, damit das Empfängersystem erkennt, wie die Rechnung beglichen werden soll.

Sie finden die Zahlungsarten unter System in der Rubrik Billing & Contract. Pflegen Sie dort die für Sie infrage kommenden Zahlungsarten mit folgenden Feldern:

1. Number: eindeutige Nummer der Zahlungsart

2. Name: Name der Zahlungsart

3. Description (Beschreibung): Beschreibung der Zahlungsart

4. Code: der Code für die ZUGFeRD-Datei

5. 

6. Die Datenerfassung orientiert sich an die Standard Code List, die ähnlich aufgebaut ist:

   

   
   

Häufig verwendete Codes:

Die Zahlungsarten können auch per Export/Import eingespielt werden. Eine Musterdatei zum direkten Import finden Sie hier: PaymentMethods_v1_2026-09-22T07_25_28.xlsx

Die vollständige Codeliste mit deutscher Übersetzung pflegt die KoSIT (Koordinierungsstelle für IT-Standards) im XRepository.

Kundenreferenznummer

• Die Kundenreferenznummer aus der Rechnung wird als BT-14 übermittelt (SellerOrderReferencedDocument → IssuerAssignedID).

SellerTradeParty → DefinedTradeContact → PersonName

Als Ansprechpartner des Rechnungsstellers (BT-41, SellerTradeParty → DefinedTradeContact → PersonName) wird der Name des angemeldeten Benutzers übermittelt, der die Rechnung auslöst bzw. druckt.

→ zurück zu COGLAS Prozessen
→ zurück zu COGLAS Menü