So beheben Sie Ihre Exception-Queue mit Dokumentennormalisierung

So schätzt Accenture beispielsweise, dass Versicherungssachbearbeiter bis zu 40 % ihrer Zeit mit nicht zum Kerngeschäft gehörenden und administrativen Aufgaben verbringen, was bis 2027 einen branchenweiten Effizienzverlust von bis zu 160 Milliarden US-Dollar bedeutet. Diese Ineffizienz hat auch weitere Folgekosten: Ein ganzes Drittel der Anspruchsteller gab an, mit ihrer jüngsten Schadensabwicklung nicht vollständig zufrieden zu sein, wodurch bis zu 170 Milliarden US-Dollar an Verlängerungsprämien gefährdet sind.

Wenn das Problem also nicht bei Extraktionsfehlern oder Problemen mit der OCR liegt, wo liegt es dann? Sehr oft beginnt es bereits, sobald Dokumente in das System gelangen. Wenn eingehende Dokumente ohne Normalisierung in das System eingegeben werden, folgen ihre internen Strukturen keiner bestimmten Vorlage oder keinem bestimmten Format. Insbesondere die OCR funktioniert in der Regel sehr gut mit bestimmten Vorlagen und Dokumentformaten, doch sobald sie auf etwas völlig Unbekanntes stößt, treten Probleme auf. Und wenn Schadensdokumente Scans, von Maklern erstellte PDFs oder per Smartphone gesendete Dokumente enthalten können, gibt es keine Garantie dafür, dass ihre internen Strukturen auch nur annähernd übereinstimmen.

Ohne Normalisierung beim Erfassen bleiben die Probleme bestehen und verursachen nachgelagerte Schwierigkeiten, was zu Verarbeitungsfehlern führt, die manuelle Exception-Queues zur Folge haben. Wenn Sie Exception-Queues reduzieren und mehr Effizienz (und Konsistenz) in automatisierten Workflows schaffen möchten, ist die Konzentration auf instabile eingehende Dokumente der beste Ansatzpunkt.

Wie instabile eingehende Dokumente zu längeren Exception-Queues führen

Versicherungsschaden-Pipelines müssen große Mengen an Dokumenten in einer Vielzahl von Formaten und Vorlagen verarbeiten, die aus Maklerportalen, Kunden-Uploads, E-Mail-Anhängen, Scansystemen und anderen Quellen stammen. Diese Dateien können bildbasierte Inhalte wie Fotos von Belegen sowie handschriftliche Unterschriften, Notizen oder wichtige Bilder enthalten, die in textlastige Dokumente eingebettet sind. Es ist zudem wahrscheinlich, dass zumindest einige der Dateien mehrschichtigen OCR-Text, fehlerhafte Objekte und/oder inkonsistente Metadaten enthalten.

Wenn nachgelagerte Systeme versuchen, die relevanten Informationen aus Dokumenten zu verarbeiten und zu extrahieren, die sich in ihrer visuellen Form und ihrem Backend-Inhalt unterscheiden, scheitern sie oft. Aufgrund der strukturellen Variabilität zwischen den Dokumenten kommt es dann zu Fehlern bei der Extraktion, Validierung und Verarbeitung. Währenddessen wächst die Exception-Queue der Dokumente, die manuell geprüft werden müssen, weiter an – und mit ihr die Kosten. Eine Umfrage ergab, dass Befragte mit mehr als 100 Mitarbeitern jährlich bis zu 850.000 US-Dollar für die manuelle Dokumentenverarbeitung ausgaben.

Wie unsichtbare Unterschiede zu Fehlern bei der PDF-Verarbeitung führen

Die Funktionsweise von PDFs und der Grund für ihre Entstehung als Dateiformat spielen eine entscheidende Rolle bei der Lösung dieses Problems. Das Hauptziel von PDFs ist es, auf jedem Gerät, auf dem sie geöffnet werden, gleich auszusehen. Infolgedessen sehen sie für uns zwar wie textlastige Dokumente aus, funktionieren aber eher wie ein Stapel unabhängiger Inhaltsebenen, darunter Text, Vektorillustrationen, Bilder, Metadaten, Anmerkungen und mehr. Was wir in einem PDF als Text sehen, ist aus Sicht des Computers eine Reihe einzelner Glyphen, die an bestimmten Stellen auf einer bestimmten Seite gezeichnet werden.

Dieses Problem kann sich auf vielfältige Weise äußern. Nehmen wir an, Sie haben ein digital erstelltes PDF mit ausfüllbaren Textfeldern. Benutzer A füllt die Textfelder nicht am Computer aus, sondern druckt das Dokument aus, füllt es von Hand aus und scannt es wieder ein. Benutzer B hingegen gibt den Text in die Felder ein und speichert das Dokument. Wenn Sie die beiden Dokumente nach dem Ausfüllen vergleichen, sehen sie optisch gleich aus, abgesehen von den handschriftlichen bzw. getippten Antworten. Was jedoch die interne Struktur betrifft, sind sie völlig unterschiedlich, da durch das Ausdrucken und Einscannen alle ursprünglichen Metadaten und die interne Struktur verloren gehen. Aufgrund dieser Unterschiede könnte das Dokument von Benutzer B während des Extraktionsprozesses einwandfrei verarbeitet werden, während das Dokument von Benutzer A Probleme verursacht.

Hier sind einige weitere Beispiele dafür, wie die interne Dokumentstruktur Probleme verursachen kann:

• Es werden zufällige Zeilenumbrüche eingefügt, wodurch Wörter geteilt und Feldwerte durcheinandergebracht werden. Übermäßige Zeilenteilung tritt auf, wenn die Extraktion oder OCR mehrere Zeilen anstelle einer einzigen Zeile ergibt, obwohl es auf dem Bildschirm wie eine einzige Zeile aussieht. Dies wird oft dadurch verursacht, dass ein Buchstabe sehr geringfügig höher oder tiefer liegt als die Buchstaben daneben, was dazu führt, dass das System einen Zeilenumbruch an einer Stelle einfügt, an der keiner sein sollte. Diese Probleme erfordern ohnehin eine manuelle Korrektur, können aber besonders knifflig sein, wenn sie Feldwerte in etwas verwandeln, das nicht mehr maschinenlesbar ist, wie zum Beispiel die Aufteilung eines Namens auf zwei Extraktionszeilen oder das Einfügen eines Zeilenumbruchs mitten in einem Datum.

• Zeilenumbrüche werden gelöscht, was zu unlesbarem Text und zusammengeführten Datenpunkten führt, die nicht korrekt geparst werden können. Dies geschieht bei zu kurzen Zeilen: Zeilen werden zusammengefügt, obwohl sie eigentlich in separaten Zeilen stehen sollten. Dies tritt häufig auf, wenn der Ersteller des Originaldokuments Leerzeichen verwendet hat, um das Textlayout zu ändern (beispielsweise durch Leerzeichen, um Elemente in einer „Tabelle" auszurichten). Das Entfernen dieser Zeilenumbrüche führt oft dazu, dass Datenpunkte, die getrennt sein sollten, zu einem einzigen Wert zusammengefügt werden, den nachgelagerte Systeme nicht korrekt lesen können, was dazu führt, dass Dokumente die Validierung nicht bestehen und mühsame manuelle Korrekturen erforderlich machen.

• Zeichen gehen verloren. Dies tritt am häufigsten bei Ligaturen auf, bei denen zwei oder mehr Buchstaben zu einem Glyphenzeichen verbunden sind (z. B. fi, fl, ff, ffi und ffl). Bei der Extraktion werden Ligaturen manchmal in Unicode-Zeichenfolgen oder Leerzeichen umgewandelt.

• Bildbasierte Inhalte verschwinden. Bildbasierte Inhalte sind für die Textextraktion unsichtbar. Wenn ein Dokument ein Foto von Unfallschäden, ein gescanntes handschriftliches Schadensformular, ein Diagramm oder etwas anderes enthält, das als Rasterbild in ein überwiegend aus Text bestehendes Dokument eingebettet ist, wird dies bei der Standardextraktion vollständig ignoriert. Dies geschieht zudem ohne Fehlermeldung oder Warnung, was zu einem stillen Datenverlust beiträgt, den Sie möglicherweise erst bemerken, wenn das Dokument bereits mehrere Schritte weiter in der Pipeline ist.

• Fehlerhafter Text erscheint. Aufgrund der Struktur von PDF-Dateien können diese Text enthalten, der für den menschlichen Leser unsichtbar ist, aber nach der Extraktion erscheint. Beispielsweise erzeugt die Verarbeitung eines Dokuments mittels OCR eine unsichtbare Textebene im Dokument. Weitere Beispiele sind weißer Text auf weißem Hintergrund, Text, der von Bildern oder grafischen Elementen verdeckt wird, Text, der außerhalb der Seite positioniert ist, usw. Unabhängig von der Ursache sind diese versteckten Textebenen schwer zu erkennen und verfälschen die extrahierte Ausgabe, wodurch sie unbrauchbar wird.

Verwendung deterministischer Normalisierung zur Behebung von Verarbeitungsfehlern

Wenn Sie Exception-Queues reduzieren und mehr Effizienz (und Konsistenz) in automatisierten Workflows schaffen möchten, ist die deterministische Normalisierung der beste Weg nach vorn. Der „deterministische" Aspekt ist entscheidend: Er garantiert, dass die gleiche strukturelle Ausgabe entsteht, unabhängig davon, wie das Eingabedokument erstellt oder übermittelt wurde. Mit dieser Art der Dokumentnormalisierung wandeln Sie inkonsistente Eingabedokumente (mit unterschiedlichen Dateitypen, visuellen Layouts usw.) in strukturell stabile Dokumente um, bevor diese in nachgelagerte Workflows wie OCR, Extraktion oder Archivierung gelangen. Diese Prozesse verhindern Probleme wie im oben beschriebenen Szenario, bei dem optisch identische Dokumente unterschiedlich verarbeitet werden, was zu unvorhersehbaren Fehlern und zusätzlichem manuellem Aufwand führt.

So sieht der Normalisierungsprozess mit dem Pdftools Conversion Service aus:

Schritt eins: Analyse

Der Conversion Service prüft, ob das hochgeladene Dokument zu den 62 von uns unterstützten Dateitypen gehört. Nicht unterstützte Dateitypen brechen die Konvertierung ab, bevor eine Verarbeitung stattfindet. Zusätzlich zur automatischen Überprüfung kann der Benutzer auch konfigurieren, welche der unterstützten Dateitypen verarbeitet werden sollen, und festlegen, was mit den anderen Typen geschieht (die Dokumente ablehnen oder durchlassen usw.).

Schritt zwei: Validieren & reparieren / In PDF konvertieren

• Wenn es sich bei dem hochgeladenen Dokument um ein PDF- oder PDF/A-Dokument handelt, wird es auf strukturelle Integrität geprüft. Werden Beschädigungen in der Datei festgestellt, wird eine automatische Reparatur versucht. Dies ist der erste Punkt, an dem strukturelle Probleme in eingehenden Dokumenten erkannt und korrigiert werden.

• Ist das hochgeladene Dokument kein PDF, wird es vor der weiteren Verarbeitung in ein PDF konvertiert. Dadurch werden alle verarbeiteten Dokumente in ein einziges Format gebracht, für das wir spezifische Tools haben, und unser Kern-SDK übernimmt den Rest des Prozesses.

Schritt drei: OCR

Dieser besteht aus zwei SDK-Vorgängen:

• Analysieren: Vor der Texterkennung wird eine Bildvorverarbeitung (Entzerrung, Binarisierung, Rauschunterdrückung und Auflösungskorrektur) durchgeführt. Anschließend werden Seiten mit bildbasiertem Text für die Verarbeitung identifiziert, sodass die OCR nur auf den Seiten/Bereichen ausgeführt wird, die dies erfordern.

• Synthese: Die OCR-Engine verarbeitet die identifizierten Seiten/Bereiche. Nach der Verarbeitung wird der erkannte Text wieder in das PDF eingebettet und an das visuelle Layout angepasst, wodurch potenzielle Probleme mit versteckten Textebenen und/oder in Bilder eingebettetem Text behoben werden.

Schritt vier: Optimieren

Während der Optimierung werden redundante Daten entfernt, Bilder komprimiert, Anmerkungen abgeflacht und Schriftarten zusammengeführt und reduziert. Dies vor der Konvertierung in PDF/A zu tun, dient mehreren Zwecken:

• Es liefert der PDF/A-Konvertierung eine sauberere, kleinere Eingabedatei.

• Eine Optimierung nach der PDF/A-Konvertierung könnte die Konformität beeinträchtigen, da Metadaten, Schriftartendaten oder andere für PDF/A-Standards erforderliche Elemente entfernt werden.

• Das Zusammenführen von Schriftarten ist eine Voraussetzung für die Konvertierung und stellt sicher, dass keine doppelten Schriftartobjekte vorhanden sind, die die Konvertierungs-Engine verarbeiten muss.

Die Optimierung normalisiert die PDF-Datei und minimiert die Dateigröße, wodurch der spätere Konvertierungsprozess erfolgreich vorbereitet wird.

Schritt fünf: Konvertierung in PDF/A

Hier findet die strukturelle Normalisierung statt. Alle vorhandenen Dokumente entsprechen den PDF/A-Standards des vom Benutzer gewählten Subtyps (d. h. PDF/A-1, -2, -3 oder -4). Hier sind einige Beispiele, wie das aussieht:

• Nicht konforme Anmerkungen (proprietäre, 3D-Anmerkungen usw.) werden entfernt.

• JavaScript-Aktionen werden aus interaktiven Feldern entfernt.

• Bei PDF/A-1-Dateien wird die Transparenz entfernt.

• Metadaten werden standardisiert.

• Alle externen Abhängigkeiten werden entfernt.

Nach dem Normalisierungsprozess werden die Dokumente je nach den Präferenzen des Benutzers zusammengeführt oder in einer einzigen Ausgabedatei zusammengefasst.

Das Endergebnis

Nach diesen Schritten weisen die resultierenden PDF-Dateien dieselbe interne Struktur auf. In Fällen, in denen es nicht möglich ist, ein Dokument genau nach den Standards zu erstellen (z. B. PDF/A-2a), wechselt das System zur nächstbesten Option, wie z. B. PDF/A-2u. Da die Dokumente strukturell ähnlich sind, verhalten sie sich nun im weiteren Verlauf der Dokumentverarbeitungs-Pipeline gleich. Es gibt auch eine optionale XML-Ausgabe für Pipelines, die eine strukturierte Datenextraktion erfordern.

Wenn Sie Ihre Dokumentnormalisierungsprozesse verbessern möchten, sehen Sie sich unseren Conversion Service an. Er übernimmt Normalisierung, OCR, Optimierung und PDF/A-Konvertierung in einer deterministischen Pipeline. Lesen Sie die vollständige technische Dokumentation, um zu verstehen, wie sich der Service in Ihre Architektur und bestehende Workflows einfügen lässt.