Enterprise Edition

Rechnung

Auf einen Blick

NextPDF Enterprise erzeugt strukturierte hybride Rechnungen in ZUGFeRD / Factur-X / Peppol-UBL und validiert Rechnungs-XML gegen das EN-16931-Datenmodell und Schematron-Regelsätze. Es erzeugt strukturierte Rechnungen, die dem in EN 16931 definierten Datenmodell entsprechen; es ist kein Steuerbehörden-Validator und zertifiziert kein Dokument.

Verfügbarkeit & Lizenzierung

Diese Funktion wird in NextPDF Enterprise (nextpdf/enterprise) ausgeliefert und aktiviert sich mit einem Lizenz-Envelope der Enterprise-Stufe. Ein Deployment ohne diese Berechtigung lädt die Klassen der Funktion nicht. Editionen vergleichen und Lizenz erwerben.

Installation

composer require nextpdf/enterprise:^3

Die Schematron-Engine nutzt die PHP-Erweiterung ext-xsl. Installieren und aktivieren Sie sie, bevor Sie die Schematron-Validierung ausführen.

Konzeptioneller Überblick

Das Invoice-Modul hat drei unabhängige Oberflächen: Einbettung strukturierter Rechnungen, EN-16931-XML-Validierung und Ausführung von Schematron-Regeln.

Einbettung. ZugferdEmbedder hängt eine vom Aufrufer bereitgestellte ZUGFeRD-2.4-/Factur-X-1.08-UN/CEFACT-CII-XML-Nutzlast an einen PDF/A-Träger an und erzeugt eine hybride Rechnung. Zwei Trägerformate werden unterstützt: PDF/A-4f (ISO 19005-4:2020), der bevorzugte moderne Träger, und PDF/A-3b (ISO 19005-3:2012) zur Abwärtskompatibilität. ZugferdXmpSchema injiziert die Factur-X-XMP-Erweiterungsschema-Deklaration, die der Träger benötigt. PeppolEmbedder erfüllt dieselbe Rolle für vom Aufrufer bereitgestellte Peppol-BIS-Billing-3.0-UBL-2.1-Rechnungs- oder -Gutschrift-XML und hängt sie mit der korrekten Beziehung der zugehörigen Datei und dem korrekten MIME-Typ an. NextPDF synthetisiert kein Rechnungs-XML; der Aufrufer stellt gültiges XML bereit und bleibt der Rechnungsaussteller.

Validierung. InvoiceXmlValidator prüft Rechnungs-XML gegen das semantische EN-16931-Datenmodell und die ZUGFeRD-/Factur-X-Containererwartungen, einschließlich des BT-24-Spezifikationskennzeichens, das die EN-16931-Geschäftsregel BR-1 vorschreibt. Er läuft in einem von zwei Modi: COMPAT (der Standard; Grenzfall-Findings zur EN-16931-Kardinalität werden als Warnungen gemeldet, um die Abwärtskompatibilität für bestehende Fixtures zu wahren) und STRICT (die BT-24-Kardinalität ist ein harter Fehler, der die Semantik externer Validatoren widerspiegelt). Der Modus ist pro Aufruf, per Umgebungs-Override oder per Konformitätsrichtlinie wählbar.

Schematron. SchematronValidator führt vorkompilierte Schematron-Regelsätze (die zur Build-Zeit zu XSLT kompilierten CEN-EN-16931-.sch-Regeln) gegen Rechnungs-XML mit dem In-process-PHP-XSLT-Prozessor aus und parst den SVRL-Bericht in strukturierte Findings. Das ZugferdProfile-Enum modelliert die Konformitätsprofile — MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED und die deutsche XRechnung-B2G-CIUS über EN 16931.

Was dieses Modul beansprucht und was nicht

Dieses Modul erzeugt und prüft strukturierte Rechnungsdaten. Es sichert nicht zu, dass ein Dokument eine rechtlich konforme Rechnung ist, dass es von einer Steuerbehörde genehmigt ist oder dass es garantiert von einer Behörde akzeptiert wird.

Der Validator prüft ausschließlich das semantische EN-16931-Modell und den ZUGFeRD-/Factur-X-/UBL-Container. Er ist kein Steuerbehörden-Validator. Nationale Erweiterungen und Clearance-Plattformen — zum Beispiel das italienische SDI, das französische Chorus Pro, der deutsche XRechnung-Transport — liegen auf Transportebene außerhalb des Umfangs.
Wie EN 16931-1 selbst feststellt, trägt das semantische Kernmodell die wesentlichen Informationen, die eine elektronische Rechnung benötigt, um die rechtliche und steuerliche Compliance zu unterstützen; der Rechnungsaussteller ist dafür verantwortlich, die Regeln der einschlägigen Gesetzgebung einzuhalten. Dies ist kein Steuerbehörden-Validator.
Die Unterstützung eines Standards ist nicht dasselbe wie Konformität mit ihm. Konsultieren Sie Ihre Steuer- und Compliance-Berater, um die regulatorische Ausreichendheit in Ihrer Rechtsordnung zu beurteilen.

Warum es so funktioniert

Das Modul synthetisiert bewusst niemals Rechnungs-XML. Einbettung, EN-16931-Validierung und Schematron-Ausführung sind drei unabhängige Oberflächen über XML, das der Aufrufer bereitstellt und besitzt. Dadurch bleibt NextPDF Erzeuger und Prüfer, niemals der Aussteller, denn die rechtliche Verantwortung kann nicht an eine Bibliothek delegiert werden. Die Validierung verwendet standardmäßig COMPAT, sodass ein Grenzfall-Kardinalitäts-Finding eher eine Warnung als eine Regression ist. STRICT ist optional, wenn Sie die Semantik externer Validatoren benötigen. Das Ergebnis ist eine saubere Trennung: NextPDF meldet, was es beobachtet, und der Aussteller entscheidet, ob das Dokument dem Gesetz entspricht. Design-Hintergrund: Rechnungen und E-Invoicing.

API-Oberfläche

Klasse	Zuständigkeit
`ZugferdEmbedder`	Hängt ZUGFeRD-/Factur-X-CII-XML an einen PDF/A-4f- oder PDF/A-3b-Träger an.
`ZugferdXmpSchema`	Injiziert die Factur-X-XMP-Erweiterungsschema-Deklaration.
`ZugferdProfile`	Enum für Konformitätsprofile (MINIMUM … EXTENDED, XRECHNUNG).
`PeppolEmbedder`	Hängt Peppol-BIS-3.0-UBL-Rechnungs-/-Gutschrift-XML an einen PDF/A-Träger an.
`InvoiceXmlValidator`	Prüft XML gegen das EN-16931-Datenmodell; COMPAT- oder STRICT-Modus.
`InvoiceValidatorMode`	Enum für den Validierungsmodus: `COMPAT` (Standard) oder `STRICT`.
`SchematronValidator`	Führt vorkompilierte Schematron-Regelsätze aus; parst SVRL-Findings.
`InvoiceValidationResult` / `SchematronResult`	Strukturierte Ergebnisse: Profil, Findings, Schweregrade.

Codebeispiel — Schnellstart

use NextPDF\Enterprise\Invoice\ZugferdEmbedder;
use NextPDF\Enterprise\Invoice\ZugferdProfile;

$pdf = ZugferdEmbedder::basic($pdfAManager, $fileAttachment, $ciiXml)
    ->embed(ZugferdProfile::EN16931);

Codebeispiel — Produktion

use NextPDF\Enterprise\Invoice\InvoiceXmlValidator;
use NextPDF\Enterprise\Invoice\InvoiceValidatorMode;

$result = $validator->validate($ciiXml, InvoiceValidatorMode::STRICT);

foreach ($result->findings as $finding) {
    $logger->warning('invoice.finding', [
        'rule'     => $finding->ruleId,
        'severity' => $finding->severity->value,
    ]);
}
// A clean result is one input to your decision, not a compliance verdict.
// The invoice issuer remains responsible for relevant legislation.

Sonderfälle & Fallstricke

Ein wohlgeformtes PDF ohne erkennbare Rechnungs-Nutzlast ergibt ein „keine Rechnung“-Ergebnis, statt eine Ausnahme zu werfen.
COMPAT ist der Standard-Validierungsmodus: Ein fehlendes BT-24-Spezifikationskennzeichen wird als Warnung gemeldet, sodass Aufrufstellen, die auf ein boolesches Gültigkeitsflag gaten, nicht regredieren. Verwenden Sie STRICT, um BT-24 zu einem harten Fehler zu machen, der der externen KoSIT-/Mustang-Semantik entspricht.
Der Aufrufer stellt das Rechnungs-XML bereit. NextPDF erzeugt oder korrigiert es nicht; eine leere Findings-Liste macht eine nicht konforme Nutzlast nicht konform.
Die Schematron-Engine erfordert ext-xsl. Regelsätze werden zur Build-Zeit kompiliert; zur Laufzeit wird ausschließlich das vorkompilierte XSLT ausgeführt.

Performance

Die Validierungskosten skalieren mit der Größe des eingebetteten XML und der Anzahl der Schematron-Regeln. Die Einbettungskosten skalieren mit der Trägergröße und werden von der PDF/A-Serialisierung dominiert. Das Performance-Budget der Seite spiegelt das Rendering der Dokumentation wider, nicht den Rechnungsdurchsatz.

Sicherheitshinweise

Sämtliches XML-Parsing läuft über den gehärteten XML-Guard: Die Auflösung externer Entitäten ist deaktiviert (XXE-sicher), DOCTYPE wird abgelehnt, und die Dekompression ist begrenzt. Der XSLT-Prozessor läuft mit deaktiviertem Laden von Netzwerk- und Dateisystemressourcen und registriert niemals PHP-Funktionen, sodass document(), xsl:include, xsl:import und result-document weder das Netzwerk noch die Festplatte erreichen können. Behandeln Sie Rechnungs-XML aus nicht vertrauenswürdigen Quellen als feindlich.

Datenresidenz & PII-Minderungen

Rechnungs-XML kann personenbezogene, kommerzielle und finanzielle Daten enthalten. Die Verarbeitung erfolgt in-process und lokal; das Modul führt während der Einbettung oder Validierung keine ausgehenden Netzwerkaufrufe aus. Wenden Sie Ihre eigenen Kontrollen zur Aufbewahrung und Minimierung auf extrahiertes XML und Findings an.

Sichere Telemetrie & Log-Bereinigung

Findings und Validierungslogs können Regel-Identifikatoren und Tag-Werte enthalten. Sie enthalten keine vollständigen Rechnungs-Nutzlasten. Bereinigen oder schwärzen Sie Feldwerte, bevor Sie Logs an gemeinsam genutzte Senken weiterleiten, falls diese Werte sensibel sind.

Konformität

Verhalten	Referenz	Status
Semantisches Kernmodell der Rechnung	EN 16931-1:2026 §4	Dagegen entwickelt; der Aussteller bleibt für die einschlägige Gesetzgebung verantwortlich
Spezifikationskennzeichen (BT-24)	EN 16931-1:2026 BR-1	Geprüft (Warnung in COMPAT, Fehler in STRICT)
UN/CEFACT-CII-Syntaxbindung	CEN/TS 16931-3-3:2020	Einbettung unterstützt
UBL-2.1-Syntaxbindung	CEN/TS 16931-3-2:2020	Einbettung unterstützt
PDF/A-3-zugehörige Datei	ISO 19005-3:2012 §6.7.8	Träger unterstützt
PDF/A-4f-eingebettete Datei	ISO 19005-4:2020 Annex A	Träger unterstützt

Diese Tabelle hält fest, gegen welche Spezifikationen NextPDF Enterprise entwickelt wurde und was es prüft. Sie ist keine Aussage über Zertifizierung, Steuerbehörden-Genehmigung oder regulatorische Ausreichendheit. Der Rechnungsaussteller ist dafür verantwortlich, die Regeln der einschlägigen Gesetzgebung einzuhalten; dies ist kein Steuerbehörden-Validator.

Verhalten im FIPS-Modus

Dieses Modul führt keine kryptografische Signierung durch. Das Signieren einer hybriden Rechnung und die FIPS-Modus-Schlüsselverwahrung liegen hier außerhalb des Umfangs; siehe das Signature-Modul.

Bedrohungsmodell

Nicht vertrauenswürdiges Rechnungs-XML ist die primäre Eingabe. Minderungen: XXE-sicheres Parsing, Ablehnung von DOCTYPE, begrenzte Dekompression, ein XSLT-Prozessor mit deaktiviertem Laden von Netzwerk- und Dateiressourcen und keine Synthese von Ansprüchen — der Aufrufer stellt den Rechnungsinhalt bereit und besitzt ihn.

Verhaltensvertrag

ZugferdEmbedder / PeppolEmbedder hängen vom Aufrufer bereitgestelltes Rechnungs-XML an einen PDF/A-4f- oder PDF/A-3b-Träger an; NextPDF synthetisiert niemals Rechnungs-XML.
InvoiceXmlValidator läuft in COMPAT (Standard; Grenzfall-EN-16931-Kardinalität ist eine Warnung) oder STRICT (die BT-24-Kardinalität ist ein harter Fehler).
SchematronValidator führt vorkompilierte Regelsätze über den In-process-XSLT-Prozessor aus und parst SVRL-Findings; eine leere Findings-Liste macht eine nicht konforme Nutzlast nicht konform.
Sämtliches XML-Parsing ist XXE-sicher: Auflösung externer Entitäten deaktiviert, DOCTYPE abgelehnt, Dekompression begrenzt.

Veröffentlichungsgrenze

Diese Seite dokumentiert ausschließlich extern beobachtbares Verhalten und die unterstützte öffentliche API-Oberfläche. Interne Namespace-Pfade, Hilfsklassen, Mechanismustabellen, Runbook-Dateinamen und Ticket-Präfixe liegen außerhalb des Umfangs.

Core-Fallback

NextPDF Core erzeugt oder validiert keine strukturierten Rechnungen. Ein Core-only-Deployment kann ein PDF erzeugen, hat aber keine ZUGFeRD-/Factur-X-/Peppol-Einbettung, keinen EN-16931-Validator und keine Schematron-Engine.

Pro-Fallback

In einem Pro-only-Deployment ist die unterstützte Oberfläche die E-Invoice-Erkennung und -Validierung von Factur-X-/ZUGFeRD-Nutzlasten auf Pro-Stufe. Pro erzeugt keine ZUGFeRD-/Factur-X- oder Peppol-UBL-Hybridträger, ergänzt nicht das XRechnung-CIUS-Profil und führt nicht die In-process-Schematron-Engine aus; eine Konfiguration, die in einem Pro-only-Deployment die Erzeugung, das XRechnung-CIUS-Profil oder Schematron anfordert, hat keine Enterprise-Komponente, die sie erfüllt. Siehe Pro Compliance zur Pro-Erkennungs- und -Validierungsoberfläche.

Hinweis zur Enterprise-Grenze

Interne Mechanismus-Details verbleiben in der internen Dokumentation des Quell-Repositorys und liegen außerhalb des Umfangs dieses Handbuchs.

Deployment-Grenze

Die Schematron-Engine erfordert die PHP-Erweiterung ext-xsl; deren Bereitstellung und Aktivierung liegt in der Verantwortung des Betreibers. Die Verarbeitung erfolgt in-process und lokal; das Modul führt während der Einbettung oder Validierung keine ausgehenden Netzwerkaufrufe aus. Nationaler E-Invoicing-Transport, Clearance-Plattformen und Archivierungssysteme sind extern zu diesem Modul und liegen in der Verantwortung des Betreibers.

Grenze der rechtlichen Compliance

NextPDF erzeugt strukturierte Rechnungen, die dem in EN 16931 definierten Datenmodell entsprechen, und meldet Regel-Findings. Es erzeugt keine „rechtlich konformen Rechnungen“, liefert keine „steuerbehördlich genehmigte“ Ausgabe und garantiert nicht, dass eine Rechnung von einer Steuerbehörde, einem Gericht oder einem Register akzeptiert wird. Der Rechnungsaussteller ist dafür verantwortlich, die Regeln der einschlägigen Gesetzgebung einzuhalten; dies ist kein Steuerbehörden-Validator. Nationale E-Invoicing-Plattformen, Clearance-Modelle, Archivierungsvorgaben und Anforderungen an digitale Signaturen variieren je nach Rechtsordnung und liegen in der Verantwortung des Ausstellers. Konsultieren Sie Ihre Steuer- und Rechtsberater.

Siehe auch

Invoice-Referenz — API-Referenz für die Embedder, Validatoren und die Schematron-Engine.
Pro Compliance — E-Invoice-Erkennung und -Validierung auf Pro-Stufe.
Document E-Filing — Optimierung der Zustellung an Gerichte/Register.
Enterprise – Überblick
Funktionsmatrix Core vs. Pro vs. Enterprise