Dokumenten-Pipelines: Von DOCX zu PDF/A-3 bis zum signierten Archiv in einem API-Aufruf
Eine Dokumenten-Pipeline, die Eingabedokumente in konforme Archivausgaben konvertiert, klingt nach einem gelösten Problem. In der Praxis produziert sie an jedem Schritt stille Fehler: Schriften, die auf dem Bildschirm korrekt erscheinen, aber die PDF/A-Validierung nicht bestehen; Textebenen, die bei der Konvertierung zerstört werden; Metadaten, die vorhanden aber technisch falsch sind; und Zeitstempel, die auf Dokumente angewendet werden, die noch nicht in ihrer endgültigen Form vorliegen.
Dieser Artikel beschreibt die vollständige Konvertierungskette, was in jedem Schritt schiefgehen kann und wie eine zuverlässige Pipeline aussieht.
Die vollständige Kette
Source document (DOCX / HTML / existing PDF)
↓ conversion
PDF (rendered with correct fonts and layout)
↓ PDF/A-3 conformance
PDF/A-3 (embedded fonts, color profiles, XMP metadata, no external references)
↓ structured attachment (for hybrid invoices)
PDF/A-3 with embedded XML (Factur-X, ZUGFeRD, XRechnung attachment)
↓ digital signature
Signed PDF/A-3 (PAdES signature, LTV information embedded)
↓ RFC 3161 timestamp
Timestamped PDF/A-3 (RFC 3161 token from qualified EU TSA)
↓ archive + audit trail
Final archive (WORM storage + hash-chained audit trail + evidence pack)Jeder Pfeil ist ein Schritt, der Nicht-Konformität einführen kann. Jeder Schritt sollte eine Validierung beinhalten, bevor der nächste Schritt ausgeführt wird.
Schritt 1: Quell-Dokument zu PDF
Die häufigste Konvertierungsroute ist DOCX zu PDF. Das Risiko hier ist Schriftartensubstitution: Wenn eine im DOCX verwendete Schrift auf dem Konvertierungsserver nicht verfügbar ist, ersetzt der Renderer eine andere Schrift. Die Ausgabe sieht auf dem Bildschirm ähnlich aus, enthält aber eine andere Schrift als angegeben. Wenn die PDF/A-Validierung später läuft, kann sie die falsche Schrift erkennen oder fehlschlagen, weil die eingebettete Schrift nicht mit der im Dokument referenzierten Schrift übereinstimmt.
Die Gegenmaßnahme: Sicherstellen, dass die Konvertierungsumgebung alle erforderlichen Schriften installiert hat, oder eine Konvertierungsmethode verwenden, die Schriften zum Konvertierungszeitpunkt einbettet. LibreOffice headless und Gotenberg (ein Docker-basierter LibreOffice-Wrapper) sind zuverlässige Open-Source-Optionen für die DOCX-zu-PDF-Konvertierung. Gotenberg bietet insbesondere eine vorhersagbare isolierte Umgebung.
DOCX nicht zu PDF konvertieren, indem man zu einem PDF-Drucker druckt. Druckertreiber rastern oft Text, was die Textebene zerstört und ein Dokument produziert, das visuell identisch, aber nicht mehr maschinenlesbar oder durchsuchbar ist. Eine rasterisierte PDF kann ohne Re-OCR nicht zu einem gültigen PDF/A-3 gemacht werden, was zusätzliche Fehler einführt.
Für HTML zu PDF ist Headless-Browser-Rendering (mit Browser-Rendering-Engines) allgemein layout-treuer als wkhtmltopdf. Moderne Browser-Engines behandeln CSS korrekt. Sicherstellen, dass die HTML-Quelle alle Schriften entweder eingebettet oder als web-sichere Schriften angegeben hat.
Schritt 2: PDF zu PDF/A-3
PDF/A-3-Konformität wird nicht automatisch durch Ausgabe einer PDF aus einer PDF/A-3-fähigen Bibliothek erreicht. Mehrere Dinge können schiefgehen:
Fehlende oder falsche XMP-Metadaten: PDF/A erfordert einen selbstbeschreibenden XMP-Block, der den Konformitätsgrad identifiziert. Die erforderlichen Felder:
<rdf:Description rdf:about="" xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">
<pdfaid:part>3</pdfaid:part>
<pdfaid:conformance>B</pdfaid:conformance>
</rdf:Description>Ohne diesen Block ist ein Dokument technisch gesehen kein PDF/A-3, unabhängig von seiner Struktur. Viele Konverter produzieren PDF/A-ähnliche Ausgaben, lassen aber den XMP-Block weg oder konfigurieren ihn falsch.
Nicht eingebettete Schriften: Auch wenn die Konvertierung Schriften eingebettet hat, lassen manche Konverter Type1- oder TrueType-Schriften teilweise eingebettet (nur Metriken, nicht die vollen Glyphendaten). PDF/A erfordert vollständige Einbettung.
Nicht unterstützte Farbräume: Bilder im Dokument müssen Farbräume mit eingebetteten ICC-Profilen verwenden. Ein RGB-Bild ohne ICC-Profil besteht die PDF/A-Validierung nicht. Bilder vor dem Einfügen in das Dokument in sRGB mit einem eingebetteten Profil konvertieren.
Transparenz: PDF/A-1 verbietet Transparenz. PDF/A-2 und PDF/A-3 erlauben sie, erfordern aber eine spezifische Handhabung. Viele Quelldokumente verwenden weiche Schatten oder transluzente Überlagerungen, die vor der PDF/A-1-Ausgabe geglättet werden müssen.
Verschlüsselung: PDF/A verbietet Verschlüsselung. Eine PDF mit einem Benutzer- oder Besitzerpasswort ist unabhängig von anderen Eigenschaften nicht PDF/A-konform.
VeraPDF nach diesem Schritt ausführen, um die Konformität vor dem Fortfahren zu bestätigen. VeraPDF ist der Referenz-Validator, der von nationalen Archiven und Regulierungsbehörden in ganz Europa verwendet wird. Es ist Open Source und kann in einer Headless-Pipeline betrieben werden.
Schritt 3: Einbetten von strukturiertem XML (Hybriddokumente)
Für Rechnungen (Factur-X, ZUGFeRD, XRechnung) muss das PDF/A-3 die XML-Rechnung als Anhang mit spezifischen Metadaten enthalten.
Die Anhangsbeziehung muss für Factur-X Alternative sein, nicht Data oder Unspecified. Dies ist in der Factur-X-Spezifikation definiert und ist einer der häufigsten Konformitätsfehler in PDF/A-3-Rechnungsgeneratoren.
Das erforderliche XMP-Erweiterungsschema für den Factur-X-Anhang:
<fx:ConformanceLevel>EN 16931</fx:ConformanceLevel>
<fx:DocumentFileName>factur-x.xml</fx:DocumentFileName>
<fx:DocumentType>INVOICE</fx:DocumentType>
<fx:Version>1.0</fx:Version>Der Dateiname muss für Factur-X genau factur-x.xml sein, und die XMP-Metadaten müssen auf diesen Dateinamen verweisen. Validatoren, die Factur-X-Konformität prüfen (nicht nur PDF/A-3), werden Dokumente ablehnen, bei denen der Dateiname oder die XMP-Referenz falsch ist.
Schritt 4: Digitale Signatur
Eine PAdES-(PDF Advanced Electronic Signatures-)Signatur anwenden, keine einfache PDF-Signatur. PAdES ist in ETSI EN 319 132 definiert und unterstützt LTV-Einbettung.
Zum Zeitpunkt der Signatur die vollständige Zertifikatskette und die OCSP-Antwort oder den CRL-Schnappschuss einbetten, der beweist, dass das Signierzertifikat zum Signierpunkt gültig war. Das sind die LTV-Informationen, die in Langzeit-PDF-Validierung besprochen werden. Ohne sie kann die Signatur unverifizierbar werden, wenn das Signierzertifikat abläuft.
Nicht zeitstempeln vor der Signatur. Die korrekte Reihenfolge ist: zuerst signieren, dann die Signatur zeitstempeln. Das Zeitstempeln des Dokuments vor der Signatur ändert den Dokument-Hash, was die Signatur ungültig macht.
Schritt 5: RFC 3161-Zeitstempel
Den Zeitstempel unmittelbar nach der Signatur anfordern, solange das Signierzertifikat noch online verifizierbar ist. Der Zeitstempel wird auf den Hash des signierten Dokuments angewendet und deckt sowohl den Dokumentinhalt als auch die Signatur ab.
Das Zeitstempel-Token in der PDF (im DSS-Wörterbuch des Dokuments) und auch im Legal Evidence Pack als eigenständige Datei für die unabhängige Verifizierung speichern.
Schritt 6: Archivierung und Prüfpfad
Das endgültige Dokument in WORM-Speicher mit gesperrter Aufbewahrungsfrist schreiben. Das Archivierungsereignis an den Hash-verketteten Prüfpfad anhängen.
Der Prüfpfadeintrag für den Archivierungsschritt sollte enthalten: den Dokument-Hash, den Speicherort, die Aufbewahrungsfrist, den Zeitstempel des Archivierungsereignisses und den Hash des vorherigen Prüfpfadeintrags. Dies produziert einen manipulationssicheren Nachweis, dass das Dokument genau in dieser Form zu genau diesem Zeitpunkt archiviert wurde.
Validierung bei jedem Schritt
Den Fehlermodus zu vermeiden, den es zu verhindern gilt, ist stille Nicht-Konformität: ein Dokument, das alle sechs Schritte durchläuft und eine Datei produziert, die korrekt aussieht, aber bei der Vorlage an einen Prüfer die Validierung nicht besteht.
Nach den Schritten 2, 3 und 5 validieren:
- Nach PDF/A-3-Konvertierung: VeraPDF für PDF/A-3-Konformität
- Nach XML-Einbettung (falls zutreffend): Factur-X- oder ZUGFeRD-Profilvalidator
- Nach Zeitstempelung: PAdES-Prüfer (DSS oder gleichwertig) für Signatur- und Zeitstempelgültigkeit
Wenn die Validierung in einem Schritt fehlschlägt, die Pipeline anhalten und einen strukturierten Fehler zurückgeben. Nicht mit einem nicht-konformen Dokument zur Archivierung fortfahren.
SealDoc als Dokumenten-Pipeline
Die SealDoc API implementiert die vollständige oben beschriebene Kette als einzelnen Endpunkt. Sie übergeben das Quelldokument (DOCX, HTML oder vorhandene PDF) zusammen mit den strukturierten Metadaten (Rechnungsdaten, Parteiinformationen, Aufbewahrungskategorie). Die API führt Konvertierung, PDF/A-3-Validierung, XML-Einbettung, Signierung, Zeitstempelung und Archivierung durch und gibt bei Erfolg das Evidence Pack oder bei Fehlschlag einen strukturierten Validierungsfehler zurück.
Jeder Schritt in der Pipeline ist so implementiert, dass er schnell fehlschlägt: Wenn VeraPDF einen Konformitätsfehler zurückgibt, stoppt die Pipeline und gibt die spezifische Klausel zurück, die verletzt wurde, anstatt mit einem nicht-konformen Dokument zum nächsten Schritt fortzufahren. Das Evidence Pack wird nur generiert, wenn alle Validierungsschritte bestanden wurden.
Für Organisationen, die die Dokumentarchivierung in bestehende Workflows integrieren müssen, akzeptiert die API Webhooks, die bei Abschluss oder Fehler benachrichtigen, und das Evidence Pack ist als ZIP abrufbar, das alle Komponenten in offenen, unabhängig verifizierbaren Formaten enthält.