Ist PDF/A-3b immer eine E-Rechnung?

Nein. PDF/A-3b ist ein Archiv-PDF-Profil. Factur-X- und ZUGFeRD-E-Rechnungen nutzen PDF/A-3b als Wrapper für eingebettetes EN 16931 XML.

Welcher Endpunkt erzeugt PDF/A-3b?

Nutzen Sie POST /api/v1/pdf/render mit settings.profile für normales PDF/A-3b. Nutzen Sie POST /api/v1/e-invoice/render, wenn die Ausgabe eine Factur-X- oder ZUGFeRD-E-Rechnung sein muss.

Kann ich über diese Seite beliebige Dateien anhängen?

Gehen Sie nicht von Unterstützung beliebiger Anhänge aus, solange die öffentlichen API-Docs diesen Workflow nicht aufführen. Diese Seite konzentriert sich auf dokumentiertes PDF/A-3b und E-Invoice-Nutzung.

Wie prüfe ich PDF/A-Ausgabe?

Nutzen Sie /validator/ oder Ihre eigene Referenzengine-Pipeline. Bei E-Rechnungen validieren Sie sowohl die PDF/A-Schicht als auch die eingebettete XML-Schicht.

Compliance und Archivierung

PDF/A-3b API für Archiv- und E-Invoice-Workflows

Erzeugen Sie PDF/A-3b-Ausgabe mit gPdf und unterscheiden Sie, wann PDF/A-3b nur ein Archivprofil ist und wann es als E-Invoice-Wrapper dient.

PRIMÄRE API JSON Render

ENDPOINT /api/v1/pdf/render

SYSTEME Compliance-Backend / Finanzsystem / Rechtsarchiv / Audit-Workflow

Im Playground testen Dokumentation lesen

Aufgabe im Workflow

Erzeugen Sie PDF/A-3b-Dokumente für Archivierungs-Workflows und wählen Sie den E-Invoice-Endpunkt, wenn PDF/A-3b eingebettetes Factur-X- oder ZUGFeRD-EN 16931 XML tragen muss.

Wann diese API passt

Sie benötigen ein PDF/A-3b-Archivprofil für ein gerendertes Dokument.
Sie müssen die Grenze zwischen normalem PDF/A und E-Invoice-Paketierung erklären.
Ihr Compliance-Workflow validiert erzeugte PDFs mit veraPDF oder einer anderen Referenzengine.
Sie benötigen eine öffentliche Seite, die PDF/A-3b-Suchintention zum richtigen Endpunkt führt.

Was sie nicht ersetzt

Sie benötigen beliebige Datei-Anhangs-Workflows, die in der öffentlichen API nicht dokumentiert sind.
Sie benötigen Factur-X- oder ZUGFeRD-E-Rechnungen über JSON Render. Nutzen Sie E-Invoice Render.
Sie benötigen eine Validator API. Die aktuelle öffentliche Validator-Oberfläche ist die /validator/-Seite.

Welchen Endpoint aufrufen

PRIMÄR

/api/v1/pdf/render

JSON Render ist der Standardpfad für diesen Workflow.

SEKUNDÄR 1

/api/v1/e-invoice/render

Nutzen Sie dies, wenn der Workflow den zugehörigen API-Pfad, einen Template-Vertrag oder eine Capability-Abfrage braucht.

Minimaler Request

POST /api/v1/pdf/render - PDF/A-3b-Ausgabe für ein gerendertes Dokument anfordern.

{
  "settings": {
    "profile": "pdfa-3b"
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Archive copy",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

Was gPdf übernimmt

Auswahl des PDF/A-Profils über JSON-Render-Einstellungen.
PDF/A-3b-E-Invoice-Paketierung bei Nutzung von POST /api/v1/e-invoice/render.
Renderbare PDF-Ausgabe, die sich für Validierung durch externe Referenzengines eignet.
Klare Trennung zwischen Archivprofil und rechtlichem E-Invoice-Workflow.

Was Ihr System verantwortet

Die Aufbewahrungsrichtlinie und den Grund, warum PDF/A-3b erforderlich ist.
Alle Geschäftsdaten, XML-Semantik und externen Compliance-Abnahmekriterien.
Validierungsnachweise, Audit-Datensätze und Langzeitspeicherung nach dem Rendering.

Produktions-Checkliste

Wählen Sie JSON Render für normale PDF/A-3b-Ausgabe.
Wählen Sie E-Invoice Render, wenn eingebettetes EN 16931 XML erforderlich ist.
Validieren Sie PDF/A-Ausgabe mit /validator/ oder Ihrem eigenen veraPDF-Workflow.
Speichern Sie das angeforderte Profil und die Request ID zusammen mit dem Dokument.
Vermeiden Sie Aussagen zu beliebigen Anhängen, solange die öffentlichen Docs diesen Workflow nicht aufführen.

Aussagegrenzen

PDF/A-3b ist ein Archivprofil; E-Invoice-Paketierung ist ein engerer Workflow darauf.
Implizieren Sie nicht, dass jeder beliebige Embedded-File-Workflow unterstützt wird.
Für Factur-X- und ZUGFeRD-PDF/A-3b-Pakete ist die E-Invoice-Route erforderlich.

PDF/A-3b ist der Wrapper, nicht der ganze Workflow

PDF/A-3b ist ein PDF-Archivprofil. Es ist wichtig, weil es als Wrapper für hybride E-Rechnungen dienen kann; das Profil allein macht ein Dokument aber nicht zu einer rechtlichen E-Rechnung. Ein normales archiviertes Dokument kann PDF/A-3b auch ohne eingebettetes Rechnungs-XML nutzen.

Für Factur-X und ZUGFeRD nutzen Sie POST /api/v1/e-invoice/render. Dieser Endpunkt ist für E-Invoice-spezifische Metadaten und die Verknüpfung der zugehörigen Datei verantwortlich.

Wählen Sie den Endpunkt nach Absicht

Nutzen Sie JSON Render, wenn Ihr Ziel lautet: „Dieses Dokument als PDF/A-3b rendern.“ Nutzen Sie E-Invoice Render, wenn Ihr Ziel lautet: „Diese Rechnung als Factur-X oder ZUGFeRD mit EN 16931 CII XML paketieren.“ Die Trennung hält Code verständlich und verhindert, dass normale Archivjobs versehentlich E-Invoice-Annahmen mitführen.

Extern validieren

PDF/A sollte mit einer Referenzengine geprüft werden, nicht mit einer Marketingaussage. Nutzen Sie den öffentlichen Validator oder Ihre eigene Validierungspipeline und speichern Sie den Bericht mit Ihren Audit-Nachweisen.

FAQ

Ist PDF/A-3b immer eine E-Rechnung?: Nein. PDF/A-3b ist ein Archiv-PDF-Profil. Factur-X- und ZUGFeRD-E-Rechnungen nutzen PDF/A-3b als Wrapper für eingebettetes EN 16931 XML.
Welcher Endpunkt erzeugt PDF/A-3b?: Nutzen Sie POST /api/v1/pdf/render mit settings.profile für normales PDF/A-3b. Nutzen Sie POST /api/v1/e-invoice/render, wenn die Ausgabe eine Factur-X- oder ZUGFeRD-E-Rechnung sein muss.
Kann ich über diese Seite beliebige Dateien anhängen?: Gehen Sie nicht von Unterstützung beliebiger Anhänge aus, solange die öffentlichen API-Docs diesen Workflow nicht aufführen. Diese Seite konzentriert sich auf dokumentiertes PDF/A-3b und E-Invoice-Nutzung.
Wie prüfe ich PDF/A-Ausgabe?: Nutzen Sie /validator/ oder Ihre eigene Referenzengine-Pipeline. Bei E-Rechnungen validieren Sie sowohl die PDF/A-Schicht als auch die eingebettete XML-Schicht.