Wenn Sie 2026 E-Rechnungen an einen deutschen B2B-Kunden senden, ist die Datei entweder ZUGFeRD-konform oder wird beim Empfang zurückgewiesen. In Frankreich gilt dasselbe mit Factur-X. Das Format ist eine PDF/A-3-Hülle mit angehängtem EN 16931 CII XML; die Referenz-Engine extrahiert dieses XML und prüft die Geschäftsregeln.

Diese Referenz-Engine ist in der Praxis Mustang (mustangproject.org): ein Open-Source-Java-Projekt, das eingebettetes XML aus einem PDF/A-3 extrahiert und gegen EN-16931-Schematron validiert. Mustang ist der Checker, gegen den Sie testen, bevor Sie eine E-Rechnung in Produktion geben.

Dieser Beitrag zeigt die Fehlermodi, die Mustang meldet, und eine schnellere Art, es auszuführen.

Was Mustang tatsächlich prüft

Wenn Sie Mustang ein Factur-X- oder ZUGFeRD-PDF geben, passiert ungefähr Folgendes:

Eingebettete Datei extrahieren. PDF/A-3 speichert Anhänge im /EmbeddedFiles Name Tree. Mustang sucht den kanonischen Dateinamen (factur-x.xml für Factur-X, zugferd-invoice.xml für ZUGFeRD 2.x) und hebt die Bytes heraus.
AFRelationship prüfen. Die angehängte Datei muss nach Factur-X- / ZUGFeRD-Baseline mit AFRelationship="Alternative" deklariert sein. Alles andere (Source, Data, Supplement) fällt durch.
XMP-Namespace und Version prüfen. Factur-X 1.0 nutzt urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#. ZUGFeRD 2.x nutzt urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#. Ein falscher Namespace oder Versionsstring fällt durch.
XML als Cross-Industry Invoice (CII) parsen. Es muss wohlgeformtes XML sein und mit dem richtigen CII-Root-Element (rsm:CrossIndustryInvoice) beginnen.
EN 16931 Schematron ausführen. Das ist der Hauptteil der Validierung: etwa 200 Geschäftsregeln zu Feldsemantik, Pflichtcodes, Summenlogik, VAT-Logik, Parteikennungen usw.

Pass = Die Rechnung ist für jedes EN-16931-konforme AP-System in der EU akzeptabel. Fail = Die AP-Automation Ihres Kunden weist die Rechnung beim Empfang zurück, und das AR-Team bekommt einen manuellen Ausnahmefall.

Die fünf häufigsten Fehlermodi

Diese tauchen auf der Mustang-Seite des Validators immer wieder auf, wenn Teams ihre ersten E-Rechnungen testen.

1. Falsches AFRelationship

ERROR: The embedded file relationship must be "Alternative".

Die PDF-Spezifikation erlaubt mehrere Beziehungstypen für angehängte Dateien. Factur-X / ZUGFeRD verlangen ausdrücklich Alternative: Das angehängte XML ist eine alternative Darstellung des sichtbaren PDF-Inhalts. Wenn Ihr PDF-Tool standardmäßig Data setzt, fällt Mustang durch.

2. Falscher oder fehlender XMP-Namespace

ERROR: Missing Factur-X namespace urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#

Das XMP-Paket des PDFs muss deklarieren, welches Factur-X-Profil vorliegt, etwa MINIMUM, BASIC, EN 16931, EXTENDED, und welchen Dateinamen der Prüfer suchen soll. Beim Schreiben einer PDF/A-3-Hülle von Hand wird das leicht übersehen; gPdfs /api/v1/e-invoice/render setzt diese Felder aus dem settings.e_invoice-Block.

3. CII XML ist wohlgeformt, aber EN 16931 Schematron fällt durch

BR-CO-25: In case the Amount due for payment (BT-115) is positive,
either Payment means (BG-16) or Payment terms (BT-20) shall be present.

Das ist der Großteil realer Fehler. Ihr XML ist syntaktisch gültig; die Geschäftsregeln fallen durch. EN-16931-Schematron-Regeln haben stabile IDs (BR-01, BR-CO-25 usw.), die Sie in der EN-16931-Spezifikation nachschlagen können.

Typische Ursachen:

Steuerkategorie fehlt auf einer Position.
Rundung bei LineTotal und TaxTotal weicht um 0,01 ab.
Verkäufer- oder Käufer-Kennung fehlt.
Währung ist im Header gesetzt, aber nicht in Beträgen.
Zahlungsbedingungen fehlen bei positiver Zahlungssumme.

4. Die PDF/A-Hülle validiert nicht wirklich

INFO: CII XML extracted and validates against EN 16931.
ERROR: PDF/A-3b conformance check failed: missing Output Intent.

Das ist der Fall, in dem Mustangs XML-Prüfung besteht, aber die zugrunde liegende PDF/A-3-Hülle durchfällt. Häufige Ursache: Jemand hat das XML korrekt geschrieben, aber ein normales PDF statt PDF/A-3 ausgegeben. Die eingebettete Datei ist vorhanden, aber die Archiv-Compliance nicht.

5. Encoding- / Deklarations-Mismatch

XML declaration says encoding="UTF-8"
embedded byte stream is UTF-8 with BOM. Mustang strict mode rejects BOM.

Klein, aber häufig. Das eingebettete XML muss exakt zu seiner Deklaration passen. Entfernen Sie BOMs, normalisieren Sie Line Endings und stellen Sie sicher, dass Content-Type / XMP-Metadaten dieselbe Kodierung nennen.

Mustang ohne Java-Installation ausführen

Java plus Mustang CLI zu installieren, ist für einen einmaligen Check in Ordnung. Für laufende Verifikation - jede generierte Rechnung, jeder CI-Lauf, der E-Rechnungskonformität absichert - ist es Reibung, die Sie nicht brauchen.

gpdf.com/validator/ führt Mustang im Browser aus:

Ziehen Sie Ihr Factur-X- / ZUGFeRD-PDF in die Upload-Zone.
Der Validator extrahiert das eingebettete XML und führt Mustangs Schematron-Engine darauf aus, kompiliert zu JavaScript / WebAssembly und ausgeführt im Cloudflare Worker.
Mustangs Report erscheint neben dem PDF/A-3-Report von veraPDF, weil beide Ebenen bestehen müssen.

Kein Login. Keine Quote. Derselbe Mustang, den Sie über Maven installieren würden, nur als kostenloser öffentlicher Service.

TL;DR

Mustang meldet fünf häufige Fehlermodi; die meisten laufen darauf hinaus, dass die Datei von einem Tool erzeugt wurde, das kein vollständig konformes Factur-X / ZUGFeRD PDF/A-3 ausgibt. Die gPdf E-invoice API gibt eine Datei in einem Aufruf aus. Der Validator prüft das Ergebnis parallel mit zwei Engines (Mustang + veraPDF).

Die meisten Bugs, die Mustang findet, liegen in der Hülle oder im AFRelationship, nicht nur in der XML-Semantik. Die Datei korrekt zu erzeugen, ist der größte Teil der Arbeit; der Validator ist der Beleg, dass Sie es getan haben.