Warum Ihre PDF/A-Dateien bei Prüfungen immer wieder durchfallen

Die Kosten solcher unsichtbaren Fehler können erheblich sein. Die DSGVO schreibt strenge Archivierungsstandards vor: sichere Speicherung personenbezogener Daten, Wahrung der Datenintegrität und die Möglichkeit, diese bei Bedarf abrufen zu können. Zudem verlangt die EU-Richtlinie MiFID II, dass Finanzinstitute Kundenkommunikation und Transaktionsaufzeichnungen fünf bis sieben Jahre lang in manipulationssicherer und leicht abrufbarer Form speichern. Bußgelder bei Verstößen können je nach Art der Regelverletzung bis zu 4–10% des Jahresumsatzes eines Unternehmens betragen. Ihre Organisation kann diese Kosten vermeiden, indem sie versteht, an welchen Stellen in der PDF/A-Pipeline Probleme typischerweise auftreten und wie sie sich im Vorfeld vermeiden lassen.

Warum Ihre PDF/A-Dateien bei Prüfungen durchfallen

PDF/A-Validierung ist aus mehreren Gründen entscheidend. Es ist jedoch ein Unterschied zu wissen, warum eine Datei validiert werden sollte, und zu verstehen, warum Ihre PDF/A-Dateien bei Prüfungen durchfallen oder Validierungschecks nicht bestehen. Im Allgemeinen treten folgende Probleme am häufigsten auf:

• Eingebettete Schriftarten: Schriftprobleme gehören zu den häufigsten Ursachen. Eine Studie zeigte, dass von 150 als nicht konform markierten PDF-Dateien 101 Dateien aufgrund unvollständiger Schriftuntermenge beanstandet wurden. Alle Schriftarten müssen im PDF eingebettet sein, sodass der Betrachter die Schriftart nicht auf seinem System installiert haben muss.

• ICC-Profile für Farbräume: Farbräume müssen geräteunabhängige ICC-Profile verwenden, um eine konsistente Farbwiedergabe sicherzustellen, unabhängig davon, wann, wo oder wie das PDF angezeigt wird. Ein häufiger Fehler ist die Nutzung von Farbräumen, die nicht sRGB entsprechen.  

• Metadatenanomalien: Alle PDF/A-Dokumente müssen XMP-Metadaten enthalten, die Details zur PDF/A-Konformität beschreiben, darunter die Eigenschaften pdfaid:part (zeigt die PDF/A-Version) und pdfaid:conformance (zeigt die Konformitätsstufe). 

• Historie inkrementeller Updates: Inkrementelle Updates fügen einem PDF neue Informationen hinzu, ohne die Originaldaten zu ändern. Dabei werden für die neue Version des PDFs eine neue xref-Tabelle und ein neuer Trailer erstellt. Die ältere Dokumentversion bleibt weiterhin in der Datei enthalten, wird dem Betrachter jedoch nicht angezeigt. Die Validierung kann aus mehreren Gründen fehlschlagen:

  • PDF/A‑1 erlaubt keine inkrementellen Updates; jede Änderung erfordert ein vollständiges Speichern.

  • PDF/A‑2 und PDF/A‑3 erlauben inkrementelle Updates, jedoch unter strengen Auflagen. Das Update muss vollständig PDF/A-konform sein. Wird eine Revision mit nicht eingebetteten Schriftarten angehängt, schlägt die Validierung fehl.

  • Außerdem muss die im Header angegebene Dokumentversion mit der im Katalogverzeichnis übereinstimmen, sonst wird die Datei bei der Prüfung beanstandet.

PDF/A-Konvertierung bedeutet nicht automatisch PDF/A-Validierung

Nachdem Sie nun genau wissen, warum Ihre Dateien bei Validierungsprüfungen fehlschlagen, ist es wichtig, den Unterschied zwischen Konvertierung und Validierung zu verstehen:

Bei der PDF/A-Konvertierung wird eine Datei in das PDF/A-Format überführt – entweder aus einem Standard-PDF oder aus einem anderen Dateityp (.doc, .html usw.). Während dieses Prozesses erhält die neue Datei spezifische Metadaten, die sie als PDF/A-Datei ausweisen, einschließlich Angaben zu der genauen PDF/A-Variante. Es ist wichtig zu beachten, dass diese Metadaten lediglich PDF/A-Konformität aufweisen, aber keine tatsächliche Konformität sicherstellen.

Die PDF/A-Validierung prüft hingegen, ob eine Datei tatsächlich PDF/A-konform ist. Open-Source-Validatoren (FOSS) arbeiten häufig heuristisch, anstatt die Spezifikationen vollständig zu überprüfen. Sie können lediglich eine „beste Schätzung“ der Konformität liefern und angeben, dass eine Datei wahrscheinlich konform ist. Dies ist nicht dasselbe wie eine formelle Validierung und kann zu Compliance-Verstößen führen. Auch eine rein visuelle Prüfung des Dokuments ersetzt keine tatsächliche Validierung. Eine Datei kann äußerlich den Eindruck erwecken, alle Anforderungen zu erfüllen, obwohl sie technisch nicht PDF/A-konform ist.

Ein weiterer erschwerender Faktor ist, dass an Dokumenten-Workflows häufig mehrere Personen und Abteilungen beteiligt sind. Beispielsweise kann ein Compliance-Team die Erstellung eines Dokumentenarchivs freigeben, während ein unabhängiges Engineering-Team den Prozess entwickelt, wie diese Dokumente vor der Archivierung bearbeitet werden. Wenn beide Teams unterschiedliche Vorstellungen davon haben, was PDF/A-Konformität bedeutet, kann eine erhebliche Lücke zwischen behaupteter und tatsächlich geprüfter Konformität entstehen. Besonders problematisch ist, dass solche Abweichungen oft erst Jahre später entdeckt werden.

Die Mindestanforderungen für alle PDF/A-Dateien:

• Sämtliche Inhalte wie Schriftarten, Texte und Bilder müssen vollständig in das Dokument eingebettet sein. Verweise auf externe Inhalte sind nicht zulässig.

• Die Datei darf keine Audio- oder Videoinhalte, JavaScript oder XFA-Formulare enthalten.

• Die Datei darf keine LZW-Komprimierung, Verschlüsselung oder Passwortschutz verwenden.

• Alle interaktiven Formularfelder müssen über ein Appearance Dictionary verfügen.

• Die Metadaten der Datei müssen mit der Extensible Metadata Platform (XMP) kodiert sein.

Diese Anforderungen stellen lediglich die Mindestvorgaben dar, die für alle PDF/A-Untertypen gelten. Abhängig vom verwendeten PDF/A-Untertyp und der jeweiligen Konformitätsstufe können zusätzliche Anforderungen hinzukommen. Werden diese Prüfungen übersprungen, besteht das Risiko, dass archivierte Dokumente langfristig nicht mehr lesbar sind, von Behörden zurückgewiesen werden oder zukünftige Prüfungen nicht bestehen.

In den meisten Fällen wird bei einer externen Prüfung oder regulatorischen Kontrolle die Konformitätsstufe bewertet, die in den Metadaten des Dokuments angegeben ist. Deshalb validiert unser SDK PDFs standardmäßig anhand der Konformitätsstufe, die im Dokument intern angegeben ist, sofern der Benutzer nichts anderes festlegt. Andernfalls kann ein Dokument intern als PDF/A-2b-konform ausgewiesen sein und die entsprechende Validierung dennoch nicht bestehen.
 

Warum die Konformitätsstufe eine Architekturentscheidung ist

Neben den bereits genannten Problemen gehören Abweichungen bei der angegebenen Konformitätsstufe zu den häufigsten Fehlerquellen. Gleichzeitig ist dieses Thema komplexer, als es auf den ersten Blick erscheint. Beispielsweise kann ein Dokument als PDF/A-1a-konform ausgewiesen sein, tatsächlich jedoch nur die Anforderungen von PDF/A-1b erfüllen. Bei den PDF/A-Konformitätsstufen sind zwei Punkte besonders wichtig:

• Die Konformitätsstufen sind nicht austauschbar. Die Standards für PDF/A-1, PDF/A-2 und PDF/A-3 wurden zu unterschiedlichen Zeitpunkten entwickelt und unterscheiden sich in ihren Anforderungen. PDF/A-1 unterstützt beispielsweise weder Transparenzen noch Ebenen und kennt ausschließlich die Konformitätsstufen A und B. PDF/A-2 unterstützt dagegen Transparenzen, Ebenen sowie eingebettete PDF/A-Dateien und umfasst die Konformitätsstufen A, B und U.

• Die Konformitätsstufen bauen aufeinander auf. Die Konformitätsstufe U, die nur für PDF/A-2 und PDF/A-3 verfügbar ist, umfasst sämtliche Anforderungen der Stufe B und ergänzt diese um weitere Vorgaben. Die Stufe A wiederum beinhaltet zusätzlich alle Anforderungen der Stufe U. Welche Konformitätsstufe erforderlich ist, hängt vom jeweiligen Anwendungsfall ab. Ein Schadensarchiv, in dem Dokumenttexte auch Jahre später noch zuverlässig durchsuchbar und extrahierbar sein müssen, benötigt beispielsweise mindestens die Konformitätsstufe U. Die Stufe B garantiert diese Funktionalität nicht. Dies zeigt, dass die Wahl der Konformitätsstufe eine Architekturentscheidung mit langfristigen Auswirkungen auf Abrufbarkeit und regulatorische Compliance ist.

Die Konformitätsstufe U konzentriert sich insbesondere auf Suchbarkeit und Textextraktion. Während sich die Stufe B vor allem auf die visuelle Integrität eines Dokuments bezieht, stellt die Stufe U sicher, dass Texte innerhalb des PDFs durchsuchbar bleiben. In Dokumenten der Stufe U werden Unicode-Textinformationen in die Ausgabedatei übernommen, sodass sie später digital extrahiert werden können. Für regulierte Branchen, in denen archivierte Dokumente auch Jahre nach der Ablage erneut geprüft werden müssen, sind deshalb insbesondere die PDF/A-Konformitätsstufen U und A relevant.

Ein prüfungssicherer PDF/A-Workflow

Wie sieht ein zuverlässiger PDF/A-Workflow aus? Wir empfehlen folgenden Ablauf:

PDF-Normalisierung → Konvertierung in PDF/A → Unabhängige Validierung der PDF/A-Konformität → Archivierung des Dokuments

Zu einem solchen Workflow gehört außerdem ein nachvollziehbarer Audit-Trail mit folgenden Informationen:

• Aufzeichnungen darüber, wer Dateien konvertiert hat und wann dies erfolgt ist

• Informationen darüber, welches Tool (und welche Version des Tools) für die Konvertierung verwendet wurden

• Ein unabhängiger Validierungsbericht, der die angegebene Konformitätsstufe bestätigt, idealerweise mit Zeitstempel und gemeinsam mit den entsprechenden Dokumenten gespeichert

Falls Sie sich fragen, ob eine unabhängige Validierung wirklich notwendig ist, lohnt sich ein genauer Blick: Eine Bibliothek, die sowohl die Konvertierung als auch die Validierung übernimmt, prüft das Ergebnis anhand ihrer eigenen Interpretation der Spezifikation. Systematische Fehlinterpretationen der Spezifikation, die besonders bei regulatorischen Prüfungen problematisch werden können, bleiben dadurch häufig unentdeckt.

Genau darin liegt eines der Risiken beim Einsatz von FOSS-Tools für die PDF/A-Validierung. Unsere Validierungsprüfungen erkennen Fehler sowohl auf Basis der ISO-Spezifikation als auch anhand benutzerdefinierter Profile und zeigen diese nach Kategorie, Position, Objektnummer und Seitenzahl an. Ohne unabhängige Validierung können potenzielle Fehler unbemerkt bleiben und gerade in regulierten Umgebungen gehören solche unbemerkten Compliance-Probleme zu den größten Risiken. Schlägt eine Prüfung fehl, muss Ihr Unternehmen nachvollziehbar erklären können, wie es dazu gekommen ist. Auf eine unabhängige Validierung zu verzichten, ist in solchen Fällen kaum vertretbar.

Prüfer erwarten in der Regel, dass Erstellung und Validierung mit getrennten Tools durchgeführt werden und keine Selbstzertifizierung erfolgt. Außerdem sollten maschinenlesbare Validierungsberichte als Nachweis archiviert werden. Ebenso wichtig ist die Übereinstimmung zwischen der angegebenen Konformitätsstufe und der tatsächlichen Dokumentstruktur. Unter regulatorischen Vorgaben wie DSGVO und MiFID II liegt die Nachweispflicht für die Integrität archivierter Dokumente vollständig bei der Organisation, die das Archiv verwaltet.

Wie Sie sehen, ist die unabhängige Validierung ein zentraler Bestandteil eines zuverlässigen PDF/A-Workflows. Deshalb zeigt unser SDK bei der Validierung präzise, welche Prüfungen fehlgeschlagen sind und an welcher Stelle sich die Probleme im Dokument befinden. Dadurch können Fehler frühzeitig behoben und gleichzeitig nachvollziehbare Nachweise für zukünftige Prüfungen erstellt werden. Eine PDF-Bibliothek, die Fehler stillschweigend übersieht, bietet weder dieselbe Transparenz noch dieselbe Sicherheit und kann langfristig zu Problemen bei regulatorischen Prüfungen führen.