Rechnungen und E-Rechnungen

Spec Spec: EN 16931-1:2026, BT-24 EN 16931-1:2026 BT-24 Spec Spec: Factur-X 1.08 Factur-X 1.08 Spec Spec: ISO 32000-2:2020, §14.13 ISO 32000-2:2020 §14.13 Evidence ⊕ Mixed evidence Evidence: Mixed evidence

Auf einen Blick

Eine moderne Rechnung besteht aus zwei Dokumenten in einer Datei: einer Seite, die ein Mensch liest, und einer maschinenlesbaren XML-Nutzlast, die ein Steuersystem auswertet. Diese Seite führt Sie durch das Szenario der hybriden Rechnung von der Pflicht bis zur Ausgabe: was ZUGFeRD und Factur-X tatsächlich verlangen, wie NextPDF die strukturierte Nutzlast anhängt und prüft und wo Konformität nicht mehr Aufgabe der Engine ist, sondern in Ihre Verantwortung fällt.

Warum das wichtig ist

Mehrere Rechtsordnungen schreiben strukturierte Rechnungen für die Abrechnung zwischen Unternehmen sowie zwischen Unternehmen und Behörden inzwischen verbindlich vor. Die Falle besteht darin, dass eine hybride Rechnung auf dem Bildschirm perfekt aussehen und dennoch abgelehnt werden kann. Abgelehnt wird sie wegen des eingebetteten XML, nicht wegen der Pixel. Wenn der strukturierten Nutzlast der Spezifikationsbezeichner fehlt, sie das falsche Profil deklariert oder mit der falschen Beziehung angehängt wird, weist die empfangende Plattform sie ab. Auf Ihrer Seite bleibt der Fehler oft unbemerkt und fällt erst Tage später auf, wenn die Zahlung bereits festhängt.

Es ist weitaus günstiger, dies einmal in der dateierzeugenden Schicht richtig zu lösen, als eine beanstandete Rechnung nach der anderen erst im Nachhinein zu entdecken.

Die Kurzfassung

• Eine konforme hybride Rechnung ist ein PDF/A-Träger mit einer konformen, als zugeordnete Datei eingebetteten XML-Nutzlast. Die Metadaten des Trägers müssen das Profil deklarieren.
• Das einzelne Feld, das am häufigsten über die Annahme entscheidet, ist BT-24, der Spezifikationsbezeichner. EN 16931-Geschäftsregel BR-1 verlangt, dass jede Rechnung ihn enthält. Der Wert ist eine URN, die das genaue Profil benennt — zum Beispiel die URN des Profils EN 16931 (COMFORT) urn:cen.eu:en16931:2017.
• NextPDFs Aufgabe ist das Einbetten und die strukturelle Validierung von XML, das der Aufrufer bereitstellt. Es erstellt den Rechnungsinhalt nicht und ist kein Validierer einer Steuerbehörde.
• Der Aussteller bleibt für die rechtliche und steuerliche Richtigkeit verantwortlich. Ein fehlerfreies Validierungsergebnis ist eine Eingabe für diese Entscheidung, kein Zertifikat.

Wie NextPDF es angeht

NextPDF behandelt die strukturierte Rechnung als schichtenübergreifenden Vertrag, nicht als einzelnes Feature. Die Kern-Engine definiert die Schnittstellen — einen Embedder, einen Profildeskriptor und einen Validierer — und die Premium-Stufe liefert die Implementierungen. Diese Trennung ist beabsichtigt. Die öffentliche Oberfläche ist im Kern eingefroren, sodass Aufrufstellen und Tests das Profil und das Ergebnis unabhängig von der dahinterliegenden Stufe auf dieselbe Weise ansprechen.

Der Ablauf umfasst vier Phasen, und die Reihenfolge ist wichtig, weil jede Phase von der vorherigen abhängt.

1. Author the invoice XML You (or your ERP) produce a UN/CEFACT CII or Peppol UBL payload. NextPDF never synthesizes invoice content.
2. Produce the PDF/A carrier A PDF/A-3 or PDF/A-4f document is the human-readable face and the conformant container the standard requires.
3. Embed the payload The embedder attaches the XML as an associated file with the correct AFRelationship, and injects the Factur-X XMP profile declaration.
4. Validate, then ship A structural pass checks the root, the required sections, and BT-24 against the declared profile before the file leaves your system.

Das Szenario der hybriden E-Rechnung von Anfang bis Ende: Sie erstellen das XML und tragen die Verantwortung für seine rechtliche Richtigkeit; NextPDF trägt es und prüft es strukturell; die empfangende Plattform trifft die endgültige Annahmeentscheidung.

Der Embedder-Vertrag lautet: Bytes hinein, Bytes heraus. Ein PDF/A-Träger und eine XML-Nutzlast werden übergeben, hybride PDF-Bytes kommen zurück. Bevor irgendetwas angehängt wird, parst eine gehärtete Schutzschicht das XML: Sie lehnt eine DOCTYPE ab, begrenzt die Eingabegröße und weist in XML 1.0 verbotene Steuerzeichen zurück. Dies beseitigt XML-External-Entity- und Billion-Laughs-Angriffe konstruktionsbedingt, weil Rechnungs-XML regelmäßig von außerhalb Ihrer Vertrauensgrenze eintrifft.

Der Profildeskriptor beantwortet die vier Fragen, die ein nachgelagertes System stellt: die kanonische Profil-URN, den zu deklarierenden Wert von BT-24, einen stabilen Namen für Protokolle und ein stufenunabhängiges Unterscheidungsmerkmal, damit Paritätstests Ergebnisse gruppieren können. Der Deskriptor bildet Lücken offen ab. Das ZUGFeRD-Profil MINIMUM enthält keinen BT-24-Spezifikationsbezeichner, und der Deskriptor gibt dafür null zurück statt einen zu erfinden. Das ist auch der Grund, warum MINIMUM und BASIC WL nicht EN 16931-konform sind. Die Engine bildet die tatsächliche Kardinalität ab, statt sie zu verbergen.

Human-factors note: Human-factors note

Der Validierer hat zwei Modi; Standard ist die konservative Variante. Im Standardmodus wird ein fehlender BT-24 als Warnung gemeldet, damit eine bestehende Pipeline, die auf einem Booleschen Wert prüft, nicht stillschweigend regressiert. Der Strict-Modus stuft denselben Befund als harten Fehler ein, passend zur Semantik externer Validierer. Der Modus ist eine bewusste Entscheidung, die Sie pro Aufruf treffen. Die Engine wählt Ihre Risikohaltung nicht für Sie, und sie teilt Ihnen mit, welche Haltung aktiv ist, statt es Ihnen zu überlassen, sie abzuleiten.

Was die Belege sagen

Das oben beschriebene Verhalten ist an drei Stellen verankert, und jede liefert eine andere Art von Beleg.

Der Standard legt die Pflicht fest. Spec Spec: EN 16931-1:2026, BR-1 EN 16931-1:2026 BR-1 macht den Spezifikationsbezeichner für jede Rechnung verpflichtend. Der technische Anhang von Factur-X legt die URN-Werte pro Profil fest, einschließlich der URN des Profils EN 16931 urn:cen.eu:en16931:2017. Der Träger selbst ist eine PDF-Angelegenheit: Spec Spec: ISO 32000-2:2020, §9 ISO 32000-2:2020 §9 hält fest, dass das vorhersagbarste und verlässlichste Rendering dann erfolgt, wenn alle Schriften eingebettet sind — direkt relevant, weil eine Rechnung, die in zehn Jahren lesbar sein muss, nicht von der Schriftumgebung des Lesers abhängen darf.

Der Code setzt den Vertrag um. Evidence { } Code-backed Evidence: Code-backed Die Kern-Schnittstellen EmbedderInterface, ProfileInterface und ValidatorInterface sind echte, stufenunabhängige Schnittstellen. ProfileType::isEn16931Conformant() bildet den Ausschluss von MINIMUM / BASIC WL im Typsystem ab. ValidationResult ist ein unveränderliches DTO, dessen isValid die Konjunktion aus “kein Fehlerbefund” und “keine fatale Regelverletzung” ist.

Das Verhalten ist auf Fähigkeitsebene für die Premium-Stufe dokumentiert: Evidence § Standard-backed Evidence: Standard-backed der Embedder hängt vom Aufrufer bereitgestelltes ZUGFeRD 2.4 / Factur-X 1.08 CII- oder Peppol-UBL-XML an einen PDF/A-4f- oder PDF/A-3b Träger als zugeordnete Datei mit der korrekten Beziehung an. Der Validierer prüft das semantische Modell von EN 16931 und den Bezeichner BT-24. Die Schematron-Stufe führt die zu XSLT kompilierten CEN-Regelsätze aus. Nichts davon erzeugt oder korrigiert den Rechnungsinhalt.

Praktisches Beispiel

Das folgende Muster veranschaulicht die Nahtstelle; es ist keine Copy-and-paste-Integration. Die Trägererzeugung und der Embedder stammen aus der Premium-Stufe, und das XML gehört Ihnen.

<?php

declare(strict_types=1);

use NextPDF\Contracts\EInvoice\ProfileType;
use NextPDF\Contracts\EInvoice\ValidatorContext;
use NextPDF\Contracts\EInvoice\ValidatorInterface;
use NextPDF\Contracts\EInvoice\EmbedderInterface;
use NextPDF\Contracts\EInvoice\EmbedderOptions;
use Psr\Log\LoggerInterface;

/**
 * Validate first, embed second, never ship an invalid payload.
 *
 * @param non-empty-string $carrierPdf  PDF/A-3 or PDF/A-4f carrier bytes
 * @param non-empty-string $ciiXml      Caller-authored UN/CEFACT CII XML
 *
 * @return non-empty-string Hybrid invoice bytes, ready to deliver
 */
function buildHybridInvoice(
    ValidatorInterface $validator,
    EmbedderInterface $embedder,
    LoggerInterface $logger,
    string $carrierPdf,
    string $ciiXml,
): string {
    // STRICT mode: a missing BT-24 is a hard error, not a warning.
    $context = new ValidatorContext(
        profile: ProfileType::EN16931,
        strictMode: true,
    );

    $result = $validator->validate($ciiXml, $context);

    if (!$result->isValid) {
        foreach ($result->getErrors() as $finding) {
            $logger->error('invoice.structural_finding', [
                'message' => $finding->message,
            ]);
        }

        // A failed structural check is your signal to stop, not to ship.
        throw new \RuntimeException('Invoice XML failed structural validation.');
    }

    $options = new EmbedderOptions(profile: ProfileType::EN16931);

    return $embedder->embed($carrierPdf, $ciiXml, $options);
}

Auf die Reihenfolge kommt es an. Die Validierung ist im Vergleich zu einer abgelehnten Rechnung und einer verzögerten Zahlung günstig; deshalb läuft sie, bevor die Nutzlast überhaupt angehängt wird.

Verbreitetes Missverständnis

Das teuerste Missverständnis ist “NextPDF macht meine Rechnungen konform.” Das tut es nicht, und es sagt das unmissverständlich. Die Engine bettet von Ihnen erstelltes XML ein und prüft es strukturell. Ein bestandenes strukturelles Ergebnis bedeutet, dass die Nutzlast die von EN 16931 erwartete Form hat und das von Ihnen angeforderte Profil deklariert. Es bedeutet nicht, dass die Rechnung rechtlich ausreichend, von der Steuerbehörde genehmigt oder garantiert von einer Clearing-Plattform angenommen wird. Nationale Erweiterungen und Clearing-Transporte liegen auf Engine-Ebene außerhalb des Geltungsbereichs. Wie EN 16931-1 es selbst formuliert, trägt das Kernmodell die Informationen, die zur Unterstützung der Konformität erforderlich sind. Der Aussteller ist dafür verantwortlich, die einschlägige Gesetzgebung zu erfüllen.

Eine zweite, weniger auffällige Falle: Die Unterstützung eines Standards ist nicht die Konformität mit ihm. Konformität ist eine Eigenschaft der endgültigen Datei zusammen mit einem Validierer, nicht eine Eigenschaft der Bibliothek, die sie erzeugt hat.

Grenzen und Abgrenzungen

• NextPDF erstellt oder korrigiert keinen Rechnungsinhalt. Der Aufrufer liefert gültiges XML und bleibt der Rechnungsaussteller. Eine leere Befundliste macht aus einer nicht konformen Nutzlast keine konforme Nutzlast.
• Strukturiertes Einbetten und Schematron-Validierung sind Fähigkeiten der Premium-Stufe. Der Kern definiert die Verträge; die Implementierungen erfordern das kommerzielle Paket. Siehe die Abgrenzung unten.
• Der Validierer prüft nur das semantische Modell von EN 16931 und den ZUGFeRD- / Factur-X- / UBL-Container. Er ist kein Validierer einer Steuerbehörde. SDI-, Chorus-Pro- und XRechnung-Transport liegen auf Transportebene außerhalb des Geltungsbereichs.
• Die Profile MINIMUM und BASIC WL sind nicht EN 16931-konform und führen keinen BT-24-Spezifikationsbezeichner — beabsichtigt, weil dies die Kardinalität des Standards widerspiegelt, keine Einschränkung der Engine.
• Die Schematron-Engine benötigt ext-xsl. Regelsätze werden zur Buildzeit kompiliert. Die Laufzeit führt nur das vorkompilierte XSLT aus, wobei das Laden von Ressourcen aus Netzwerk und Dateisystem deaktiviert ist.
• Diese Seite beschreibt das Verhalten auf Fähigkeitsebene. Sie garantiert keine Annahme durch eine bestimmte Behörde oder Plattform.

Structured e-invoice embedding and validation — edition availability

Edition	Availability
Core	○ Der Kern definiert die schichtenübergreifenden Verträge (EmbedderInterface, ProfileInterface, ValidatorInterface), liefert aber keine Implementierung der strukturierten Rechnung mit. Ein einfacher PDF-Träger ohne strukturierte Nutzlast ist das, was allein mit dem Kern entsteht.
Pro	○ Factur-X 1.08-CII-Einbettung in einen PDF/A-Träger und die Profildeskriptoren für EN 16931 sind verfügbar.
Enterprise	○ Fügt Peppol BIS 3.0-UBL-Einbettung, die XRechnung-B2G-CIUS, COMPAT-/STRICT- XML-Validierung und die prozessinterne Schematron-Regelengine hinzu.

Verwandte Dokumente

• Archivierung und PDF/A — warum der Rechnungsträger eine PDF/A-Datei ist und was das für die langfristige Lesbarkeit garantiert.
• Der Integrationsentscheidungsleitfaden — welches Ökosystempaket zu einer Rechnungspipeline passt (Generierung über Warteschlange, Framework-Brücke oder Connect).
• Betrieb von NextPDF in der Produktion — wie Sie Validierungsbefunde und -fehler beobachten, sobald Rechnungen in großem Umfang fließen.

Glossar

• Hybride Rechnung — eine einzelne PDF-Datei, die zugleich eine menschenlesbare Seite und eine maschinenlesbare, eingebettete XML-Rechnungsnutzlast ist.
• ZUGFeRD / Factur-X — die deutsche und die französische Bezeichnung für denselben Ansatz hybrider Rechnungen: eine UN/CEFACT-Cross-Industry-Invoice-(CII-)XML-Nutzlast, eingebettet in einen PDF/A-Träger.
• EN 16931 — der europäische Standard, der das semantische Datenmodell der Kernelemente einer elektronischen Rechnung definiert.
• BT-24 (Spezifikationsbezeichner) — der EN 16931-Geschäftsbegriff, dessen Wert eine URN ist, die das genaue Profil benennt, dem die Rechnung entspricht. Erforderlich durch Geschäftsregel BR-1.
• Profil — auch Konformitätsstufe genannt (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG). Bestimmt, welche Geschäftsbegriffe eine Rechnung enthalten muss.
• Zugeordnete Datei — eine in ein PDF eingebettete Datei mit einer deklarierten Beziehung (AFRelationship), die beschreibt, wie sie sich zum sichtbaren Dokument verhält; der Mechanismus, der das Rechnungs-XML trägt.
• Schematron — eine Regelsprache, die zum Ausdrücken der EN 16931-Geschäftsregeln verwendet wird. NextPDF führt die zu XSLT kompilierten CEN-Regelsätze aus.