ZUGFeRD für Entwickler: CII-Format und PDF/A-3 verstehen

ZUGFeRD ist das hybride E-Rechnungsformat des Forums elektronische Rechnung Deutschland (FeRD): eine PDF-Datei für Menschen, mit eingebetteten XML-Daten für Maschinen. Dieser Artikel erklärt das Format aus Entwicklersicht – das zugrundeliegende Cross Industry Invoice (CII)-XML, die Profile und die PDF/A-3-Einbettung.

Was ist ZUGFeRD?

Eine ZUGFeRD-Rechnung besteht aus zwei Komponenten:

1. Sichtkomponente: ein PDF/A-3-Dokument (ISO 19005-3), das die Rechnung menschenlesbar darstellt
2. Strukturierte Daten: eine im PDF eingebettete XML-Datei im UN/CEFACT-CII-Format für die maschinelle Verarbeitung

Empfänger ohne spezielle Software öffnen einfach das PDF; Systeme mit E-Rechnungs-Unterstützung verarbeiten die XML-Daten automatisch. Wichtig für die Praxis: Nach dem BMF-Schreiben zur E-Rechnungspflicht ist bei hybriden Formaten der strukturierte XML-Teil der führende Teil – bei Abweichungen gehen die XML-Daten den Angaben im PDF vor.

ZUGFeRD wird gemeinsam mit dem französischen Standard Factur-X entwickelt; beide sind technisch identisch. Aktuell ist ZUGFeRD 2.5 (entspricht Factur-X 1.09), veröffentlicht im Juni 2026 und vollständig rückwärtskompatibel. Die Version basiert auf UN/CEFACT CII D22B und bleibt abwärtskompatibel zur bisherigen Basis D16B.

Rechtlicher Rahmen

Seit dem 01.01.2025 ist die E-Rechnung nach § 14 UStG der Standard für Umsätze zwischen inländischen Unternehmern: Empfangen können muss sie seitdem jedes Unternehmen, für die Ausstellung gelten Übergangsfristen nach § 27 Abs. 38 UStG (mit Zustimmung des Empfängers bis Ende 2026, bei Vorjahresumsatz bis 800.000 € bis Ende 2027). Das BMF-Schreiben vom 15.10.2024 (geändert am 15.10.2025) erkennt ZUGFeRD ab Version 2.0.1 als zulässiges Format an – ausgenommen die Profile MINIMUM und BASIC WL.

ZUGFeRD vs. XRechnung

Wer das CII-Format beherrscht, kann also sowohl ZUGFeRD-Rechnungen als auch XRechnungen in der CII-Syntax erstellen.

Die ZUGFeRD-Profile

ZUGFeRD definiert fünf Profile mit unterschiedlichem Detailgrad sowie ein Referenzprofil:

• MINIMUM: nur grundlegende Kopfdaten, ohne USt-Aufschlüsselung. In Deutschland keine vollständige Rechnung, nur eine Buchungshilfe.
• BASIC WL („without lines“): Kopfdaten ohne Rechnungspositionen. Ebenfalls keine vollständige Rechnung.
• BASIC: grundlegende Daten inklusive Positionen; als vollständige Rechnung anerkannt.
• EN 16931 (COMFORT): bildet das vollständige semantische Datenmodell der EN 16931 ab. Für die meisten Anwendungsfälle die richtige Wahl.
• EXTENDED: Erweiterung über die EN 16931 hinaus für komplexe Branchenanforderungen.
• XRECHNUNG (Referenzprofil): erfüllt zusätzlich die deutschen XRechnung-Geschäftsregeln; seit ZUGFeRD 2.1.1 in Abstimmung mit der KoSIT enthalten.

Das CII-Format: Namensräume

CII verwendet vier zentrale XML-Namensräume:

<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice
    xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
    xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100"
    xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
    <!-- Rechnungsinhalt -->
</rsm:CrossIndustryInvoice>

• rsm: Root-Element und Hauptstruktur
• ram: wiederverwendbare Geschäftsentitäten (Parteien, Adressen, Positionen)
• qdt / udt: qualifizierte und einfache Datentypen (Datum, Beträge, Codes)

Während UBL die Präfixe cac:/cbc: verwendet, erkennt man CII-Dokumente sofort an rsm: und ram:.

Anatomie einer CII-Rechnung

Eine CII-Rechnung gliedert sich in drei Hauptbereiche:

1. ExchangedDocumentContext: Kontext, insbesondere das Profil
2. ExchangedDocument: Dokumentmetadaten
3. SupplyChainTradeTransaction: der Geschäftsvorfall mit allen Details

1. Der Dokumentenkontext (ExchangedDocumentContext)

<rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
        <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>

Die GuidelineSpecifiedDocumentContextParameter/ID ist der wichtigste Identifikator: Sie gibt das verwendete Profil an.

2. Das Dokument (ExchangedDocument)

<rsm:ExchangedDocument>
    <ram:ID>RE-2026-001</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
        <udt:DateTimeString format="102">20260615</udt:DateTimeString>
    </ram:IssueDateTime>
</rsm:ExchangedDocument>

• ID (BT-1): die Rechnungsnummer
• TypeCode (BT-3): der Dokumenttyp nach UNTDID 1001 – „380“ für eine Handelsrechnung, „381“ für eine Gutschrift
• IssueDateTime: das Rechnungsdatum; format="102" bedeutet YYYYMMDD

3. Der Geschäftsvorfall (SupplyChainTradeTransaction)

3.1 Rechnungspositionen (IncludedSupplyChainTradeLineItem)

<ram:IncludedSupplyChainTradeLineItem>
    <ram:AssociatedDocumentLineDocument>
        <ram:LineID>1</ram:LineID>
    </ram:AssociatedDocumentLineDocument>
    <ram:SpecifiedTradeProduct>
        <ram:Name>IT-Beratung</ram:Name>
    </ram:SpecifiedTradeProduct>
    <ram:SpecifiedLineTradeAgreement>
        <ram:NetPriceProductTradePrice>
            <ram:ChargeAmount>120.00</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
    </ram:SpecifiedLineTradeAgreement>
    <ram:SpecifiedLineTradeDelivery>
        <ram:BilledQuantity unitCode="HUR">8</ram:BilledQuantity>
    </ram:SpecifiedLineTradeDelivery>
    <ram:SpecifiedLineTradeSettlement>
        <ram:ApplicableTradeTax>
            <ram:TypeCode>VAT</ram:TypeCode>
            <ram:CategoryCode>S</ram:CategoryCode>
            <ram:RateApplicablePercent>19</ram:RateApplicablePercent>
        </ram:ApplicableTradeTax>
        <ram:SpecifiedTradeSettlementLineMonetarySummation>
            <ram:LineTotalAmount>960.00</ram:LineTotalAmount>
        </ram:SpecifiedTradeSettlementLineMonetarySummation>
    </ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>

• BilledQuantity mit unitCode nach UN/ECE Rec. N°20/N°21
• ApplicableTradeTax mit Steuerkategorie nach UNTDID 5305 und Steuersatz
• LineTotalAmount: Nettobetrag der Position (Menge × Einzelpreis)

3.2 Handelsvereinbarung (ApplicableHeaderTradeAgreement)

Enthält Verkäufer, Käufer und die Käuferreferenz (BT-10, bei Behördenrechnungen die Leitweg-ID):

<ram:ApplicableHeaderTradeAgreement>
    <ram:BuyerReference>PROJEKT-2026-ZF</ram:BuyerReference>
    <ram:SellerTradeParty>
        <ram:Name>Muster Software GmbH</ram:Name>
        <ram:PostalTradeAddress>
            <ram:PostcodeCode>10115</ram:PostcodeCode>
            <ram:LineOne>Musterstraße 42</ram:LineOne>
            <ram:CityName>Berlin</ram:CityName>
            <ram:CountryID>DE</ram:CountryID>
        </ram:PostalTradeAddress>
        <ram:SpecifiedTaxRegistration>
            <ram:ID schemeID="VA">DE123456789</ram:ID>
        </ram:SpecifiedTaxRegistration>
    </ram:SellerTradeParty>
    <ram:BuyerTradeParty>
        <ram:Name>Kunde GmbH</ram:Name>
        <ram:PostalTradeAddress>
            <ram:PostcodeCode>80331</ram:PostcodeCode>
            <ram:LineOne>Kundenweg 1</ram:LineOne>
            <ram:CityName>München</ram:CityName>
            <ram:CountryID>DE</ram:CountryID>
        </ram:PostalTradeAddress>
    </ram:BuyerTradeParty>
</ram:ApplicableHeaderTradeAgreement>

Die Umsatzsteuer-Identifikationsnummer wird in SpecifiedTaxRegistration mit schemeID="VA" angegeben.

3.3 Lieferinformationen (ApplicableHeaderTradeDelivery)

<ram:ApplicableHeaderTradeDelivery>
    <ram:ActualDeliverySupplyChainEvent>
        <ram:OccurrenceDateTime>
            <udt:DateTimeString format="102">20260601</udt:DateTimeString>
        </ram:OccurrenceDateTime>
    </ram:ActualDeliverySupplyChainEvent>
</ram:ApplicableHeaderTradeDelivery>

3.4 Abrechnungsinformationen (ApplicableHeaderTradeSettlement)

<ram:ApplicableHeaderTradeSettlement>
    <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
    <ram:SpecifiedTradeSettlementPaymentMeans>
        <ram:TypeCode>58</ram:TypeCode>
        <ram:PayeePartyCreditorFinancialAccount>
            <ram:IBANID>DE12345678901234567890</ram:IBANID>
        </ram:PayeePartyCreditorFinancialAccount>
    </ram:SpecifiedTradeSettlementPaymentMeans>
    <ram:ApplicableTradeTax>
        <ram:CalculatedAmount>182.40</ram:CalculatedAmount>
        <ram:TypeCode>VAT</ram:TypeCode>
        <ram:BasisAmount>960.00</ram:BasisAmount>
        <ram:CategoryCode>S</ram:CategoryCode>
        <ram:RateApplicablePercent>19</ram:RateApplicablePercent>
    </ram:ApplicableTradeTax>
    <ram:SpecifiedTradePaymentTerms>
        <ram:DueDateDateTime>
            <udt:DateTimeString format="102">20260715</udt:DateTimeString>
        </ram:DueDateDateTime>
    </ram:SpecifiedTradePaymentTerms>
    <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:LineTotalAmount>960.00</ram:LineTotalAmount>
        <ram:TaxBasisTotalAmount>960.00</ram:TaxBasisTotalAmount>
        <ram:TaxTotalAmount currencyID="EUR">182.40</ram:TaxTotalAmount>
        <ram:GrandTotalAmount>1142.40</ram:GrandTotalAmount>
        <ram:DuePayableAmount>1142.40</ram:DuePayableAmount>
    </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
</ram:ApplicableHeaderTradeSettlement>

• SpecifiedTradeSettlementPaymentMeans/TypeCode (BT-81): die Zahlungsart nach UNTDID 4461 – „58“ ist die SEPA-Überweisung, „30“ die generische Überweisung
• ApplicableTradeTax: die Steueraufschlüsselung je Steuersatz
• SpecifiedTradeSettlementHeaderMonetarySummation: die Gesamtsummen; sie müssen rechnerisch exakt zu den Positionen passen

PDF/A-3: das Trägerformat

PDF/A-3 (ISO 19005-3) ist der Archivierungsstandard für PDF, der – anders als PDF/A-1 und PDF/A-2 – das Einbetten beliebiger Dateien erlaubt. Genau das nutzt ZUGFeRD: Die CII-XML-Datei wird als Anhang in das PDF eingebettet (bei ZUGFeRD 2.x unter dem Namen factur-x.xml, im XRECHNUNG-Profil xrechnung.xml).

Für ein konformes PDF/A-Dokument gelten unter anderem diese Anforderungen:

• Alle Schriftarten müssen eingebettet sein
• Keine Verschlüsselung, keine aktiven Inhalte wie JavaScript
• Metadaten müssen als XMP vorliegen; für die ZUGFeRD-spezifischen Metadaten (u. a. Profil und Dateiname der XML) stellt das FeRD ein XMP-Erweiterungsschema bereit

Die korrekte Einbettung samt XMP-Metadaten ist erfahrungsgemäß die häufigste Fehlerquelle bei Eigenimplementierungen – PDF-Bibliotheken erzeugen ohne Zusatzaufwand kein valides PDF/A-3.

Validierung

Vor dem produktiven Einsatz sollten sowohl das XML als auch der PDF-Container geprüft werden:

• Das ZUGFeRD-2.5-Paket des FeRD enthält XSD-Schemata und Schematron-Regeln für alle Profile.
• Der KoSIT-Validator prüft EN-16931- und XRechnung-Konformität der XML-Daten (UBL und CII).
• Das Open-Source-Projekt Mustang validiert ZUGFeRD-Dateien inklusive PDF-Teil.

Geprüft werden dabei Schema-Konformität, die Geschäftsregeln der EN 16931 (insbesondere die Summenbildung), die PDF/A-3-Konformität und die korrekte Einbettung.

Der einfachere Weg: ZUGFeRD per API erstellen

Wer nicht selbst CII-XML generieren und normkonform in PDF/A-3 einbetten will, kann beides einer API überlassen: RechnungsAPI erzeugt aus einem JSON-Request eine fertige, validierte ZUGFeRD-Rechnung samt PDF. Wie das geht, zeigt unser Tutorial zur ZUGFeRD-Erstellung per API.

Quellen

• FeRD: ZUGFeRD-Standard und FAQ
• FeRD: Release ZUGFeRD 2.5
• BMF-Schreiben vom 15.10.2025 zur obligatorischen E-Rechnung
• § 14 UStG und § 27 UStG
• KoSIT-Validator auf GitHub