Vom Bildcontainer zur durchsuchbaren Akte: Nextcloud Workflow OCR in der Praxis

Es gibt diese Momente in IT-Abteilungen, in denen ein Problem jahrelang unsichtbar bleibt, obwohl es jeden Tag passiert. Ein Steuerbüro schiebt monatlich mehrere hundert Seiten Belege durch den Scanner. Die Dateien landen sauber benannt in der Nextcloud, die Ordnerstruktur ist vorbildlich, das Backup läuft. Nur: Die PDFs sind Bilddaten in einem Container. Wer in ihnen sucht, sucht mit den Augen. Wer sie archivieren will, muss sie von Hand umbenennen, verschlagworten, einsortieren. Der Flaschenhals sitzt nicht im Speicher und nicht im Netzwerk, sondern in der fehlenden Textebene.

Genau an dieser Stelle setzen Werkzeuge wie Tesseract und OCRmyPDF an, und in der Nextcloud-Welt gibt es dafür seit einigen Jahren einen vergleichsweise eleganten Weg: die App Workflow OCR in Kombination mit der Workflow-Engine des Systems. Wer das einmal sauber aufgesetzt hat, merkt schnell, dass sich damit nicht nur ein paar Sekunden Sucharbeit sparen lassen, sondern ganze Prozessketten neu ordnen – Verschlagwortung, Ablage, Archivierung, sogar die Vorbereitung für KI-gestützte Suche.

Der folgende Beitrag versucht eine Bestandsaufnahme. Keine Produktwerbung, kein How-to in fünf Schritten, sondern eine nüchterne Betrachtung dessen, was technisch dahintersteht, wo die Fallstricke liegen und für wen sich der Aufwand lohnt.

Ein PDF ist nicht gleich ein PDF

Der erste Denkfehler in vielen Projekten ist die Annahme, ein PDF enthalte automatisch Text. Tatsächlich ist das Portable Document Format ein Container, der sehr unterschiedliche Dinge transportieren kann: Vektorgrafiken, Schriftarten, Formularfelder, eingebettete Bilder oder eben eine Kombination daraus. Ein Scan ist technisch betrachtet ein Foto. Es sieht aus wie eine Seite, verhält sich beim Zoomen auch so, aber es gibt darin keine Buchstaben – nur Pixel. Ein Copy-and-paste liefert nichts, die Suche findet nichts, und jede Software, die den Inhalt verstehen soll, steht vor einem Rasterbild.

Optische Zeichenerkennung, kurz OCR, löst das, indem sie das Rasterbild analysiert: Zeilen finden, Wörter segmentieren, einzelne Zeichen klassifizieren, aus Wahrscheinlichkeiten Wörter bilden und diese schließlich wieder zu einem Text zusammensetzen. Das Ergebnis wird dann als unsichtbare Textebene über das Originalbild gelegt. Der Betrachter sieht weiterhin den Scan, die Maschine sieht zusätzlich Zeichenketten mit Koordinaten. Solche Dateien heißen umgangssprachlich „durchsuchbare PDFs“ oder „Sandwich-PDFs“.

Unter der Haube steckt bei den meisten freien Lösungen Tesseract, eine OCR-Engine, die ursprünglich bei HP entstand, später von Google gepflegt wurde und heute als Community-Projekt weiterläuft. Tesseract ist erstaunlich gut – bei sauberem, geradem, kontrastreichem Material. Und erstaunlich empfindlich, sobald der Scan schief liegt, das Papier durchschimmert, ein Stempel quer über die Rechnungsnummer läuft oder der Kopierer die Ränder abgeschnitten hat. Deshalb ist Tesseract selten allein im Einsatz. Meist kommt OCRmyPDF dazu, ein Werkzeug, das die Vorarbeit erledigt: Seiten drehen, begradigen, Rauschen entfernen, das Bild aufbereiten, Tesseract pro Seite aufrufen, die Textebene einbauen und am Ende ein valides PDF ausgeben. Optional mit PDF/A-Konformität, was für die revisionssichere Archivierung relevant ist.

Für den Anwender ist diese Arbeitsteilung unsichtbar. Für den Betrieb ist sie entscheidend, denn genau hier entstehen die Abhängigkeiten, über die später noch zu reden sein wird: Tesseract mit den passenden Sprachpaketen, Ghostscript, unpaper, qpdf, unter Umständen ImageMagick. Fehlt eines davon, bricht die Verarbeitung ab – und zwar oft mit Fehlermeldungen, die niemandem weiterhelfen, der nicht weiß, wie OCRmyPDF intern arbeitet.

Warum der Workflow der eigentliche Hebel ist

Man kann OCR natürlich von Hand anstoßen: Datei herunterladen, lokal durch ein Tool schicken, Ergebnis wieder hochladen. Für zehn Dokumente im Jahr ist das völlig in Ordnung. Für einen Betrieb, in dem täglich Dutzende Dateien eintrudeln, ist es Unsinn. Der entscheidende Punkt ist nicht die Erkennung selbst, sondern der Zeitpunkt, an dem sie ausgelöst wird. Idealerweise passiert sie, ohne dass jemand daran denken muss – als Teil des normalen Dateilebenszyklus.

Genau das ist der Gedanke hinter der Workflow-Engine, die Nextcloud seit Version 18 mitbringt. Ursprünglich als „Flow“ eingeführt und inzwischen fest in den Funktionsumfang integriert, beschreibt sie Regeln nach dem Muster Ereignis → Bedingung → Aktion. Ein Ereignis könnte sein, dass eine Datei hochgeladen wurde. Eine Bedingung könnte prüfen, ob der Dateiname einem Muster entspricht oder ob die Datei in einem bestimmten Ordner gelandet ist. Eine Aktion könnte eine Benachrichtigung verschicken, ein Tag setzen, ein Skript ausführen – oder eben eine OCR-Verarbeitung starten.

Das klingt unspektakulär, ist aber ein ziemlicher Sprung gegenüber dem, was viele kleinere DMS-Lösungen bieten. Der Workflow bekommt nicht nur ein Häkchen „OCR aktiviert“ oder „OCR aus“, sondern eine echte Regelbasis. Man kann unterscheiden, ob etwas aus dem Scanner-Eingangsordner kommt oder aus dem öffentlichen Upload-Link, man kann Dateitypen ausschließen, man kann mehrere Regeln nebeneinander betreiben. Ein interessanter Aspekt ist dabei die Kombination mit der App für automatisches Tagging: Dateien, die über einen bestimmten Weg eintreffen, bekommen zunächst ein Merkmal wie „zu verarbeiten“, und der Workflow greift nur auf Dateien mit diesem Merkmal zu. Nach erfolgreicher Verarbeitung setzt er ein zweites Merkmal. Aus dem Merkmal wird so eine Art Zustandsmaschine, ohne dass man dafür eine Programmiersprache anfassen muss.

Nicht zuletzt lässt sich das auch für Nachvollziehbarkeit nutzen. Wenn ich später wissen will, welche Dokumente bereits eine Textebene besitzen und welche nicht, brauche ich keine Datenbankabfrage, sondern filtere nach dem Tag. In Häusern mit Prüfpflichten ist das kein Luxus, sondern eine Arbeitserleichterung.

Der Unterbau: Wie Flow intern arbeitet

Wer eine solche Regel baut, sollte grob wissen, was danach passiert. Die Workflow-Engine selbst ist ein Framework. Sie nimmt Ereignisse entgegen, die von anderen Apps ausgelöst werden – etwa vom Datei-Modul – und arbeitet dann die konfigurierten Regeln ab. Jede Aktion ist ein eigener kleiner Baustein, der von einer App bereitgestellt wird. Es gibt Bordmittel wie Benachrichtigungen oder eben das Setzen von Tags, und es gibt Aktionen aus Zusatz-Apps.

Für schwere Arbeiten ist dieses Modell bewusst aufgeteilt. Manche Aktionen laufen synchron im Kontext des auslösenden Requests, andere werden als Hintergrundjob eingereiht. Das ist kein Detail am Rande: Eine OCR-Verarbeitung über 80 Seiten dauert auf einem kleinen Server durchaus eine Minute oder mehr. Synchron würde das bedeuten, dass der Upload-Vorgang hängt, der Browser wartet, ein Timeout droht und der Anwender den Upload abbricht. Deshalb der Umweg über die Job-Queue.

Die Job-Queue ist im Kern eine Tabelle in der Nextcloud-Datenbank. Ein Cron-Job – bei Installationen mit deaktiviertem AJAX-Cron idealerweise alle fünf Minuten – sieht nach, ob Arbeit anliegt, und arbeitet sie ab. In größeren Umgebungen lohnt es sich, den Vorgang zu beschleunigen, indem man zusätzliche Worker dauerhaft laufen lässt. Der Befehl dafür lautet in etwa occ background-job:worker, typischerweise mit Angabe des Job-Typs, damit nicht alles quer durch die Queue gemischt wird. Mit occ background-job:list lässt sich nachsehen, was gerade ansteht. Wer das nicht einrichtet, bekommt gelegentlich den Eindruck, OCR „dauere ewig“ – in Wahrheit wartet sie einfach, bis der nächste Cron-Takt kommt.

Ein weiterer Punkt, der gern übersehen wird: Ein hängender Job kann die ganze Kette blockieren. Wenn Tesseract auf einem defekten Scan endlos rechnet oder ein Speicherlimit reißt, bleibt der Eintrag in der Queue liegen. Deshalb sollte man Zeitüberschreitungen nicht auf astronomische Werte setzen, sondern lieber die Verarbeitung aufteilen und im Zweifel das Original unangetastet lassen.

Die App Workflow OCR: Umfang und Grenzen

Die App, um die es hier geht, heißt schlicht Workflow OCR und ist im offiziellen App Store verfügbar. Sie stammt aus der Community, wird als freie Software gepflegt und liefert eine Reihe von Aktionen, die sich in Flow einhängen. Die wichtigste davon startet die OCR-Verarbeitung einer Datei; daneben gibt es Optionen für Ausgabename, Sprache, Vorverarbeitung und einige weitere Schalter, auf die später noch einzugehen ist.

Für die Installation gilt eine einfache Regel: Die App allein genügt nicht. Sie braucht die Workflow-Engine als Grundlage. Wer sie über die Weboberfläche installiert und die Abhängigkeit fehlt, bekommt eine entsprechende Meldung – das ist lästig, aber immerhin ehrlich. Wesentlich unangenehmer sind die Abhängigkeiten außerhalb von Nextcloud. Die App ruft das Kommandozeilenwerkzeug ocrmypdf auf. Fehlt es, scheitert jeder Lauf mit einem Fehler im Log, während die Oberfläche keine Ursache nennt.

Was die App ausdrücklich nicht ist: ein DMS. Sie verschlagwortet nicht inhaltlich, sie erkennt keine Rechnungsnummern, sie ordnet nichts in Ordnerstrukturen ein, sie versteht den Inhalt nicht. Sie erzeugt eine Textebene und erledigt ein paar mechanische Aufräumarbeiten. Alles darüber hinaus – Klassifikation, Extraktion von Feldern, Dublettenprüfung – muss man separat lösen oder in ein spezialisiertes Dokumentenmanagementsystem auslagern. Diese Abgrenzung ist wichtig, weil in Ausschreibungen gern „automatische Rechnungsverarbeitung“ gefordert wird, während das eigentliche OCR nur ein Zwischenschritt davon ist.

Ein schöner Nebeneffekt: Weil die App die Aktion als Flow-Baustein bereitstellt, lässt sie sich mit allen anderen Aktionen kombinieren. Datei hochladen → OCR → Tag setzen → Benachrichtigung an die Buchhaltung. Oder: PDF erzeugen → OCR → in den Archivordner verschieben. Solche Ketten sind in wenigen Minuten konfiguriert und sparen danach dauerhaft Arbeit.

Voraussetzungen, bevor die erste Regel läuft

Die technische Checkliste ist der Punkt, an dem die meisten Projekte hängen bleiben. Auf einem gewöhnlichen Linux-Server sieht sie ungefähr so aus:

• OCRmyPDF in einer halbwegs aktuellen Fassung – ältere Versionen kennen einige Optionen nicht, die die App anspricht. Als Untergrenze gilt grob Version 12, besser ist ein aktueller Stand.
• Tesseract in Version 4 oder 5, inklusive der gewünschten Sprachpakete. Die Pakete sind je nach Sprachversion unterschiedlich groß; Deutsch und Englisch sind unkritisch, slawische Sprachen oder Kyrillisch brauchen mehr.
• Ghostscript für die PDF-Verarbeitung, qpdf für Optimierungen, unpaper für die Reinigung von Scans.
• pdftk oder ein Ersatz, wenn PDF-Formulare verarbeitet werden sollen.
• Die PHP-Erweiterung imagick, sobald Bildformate wie JPG, PNG, TIFF oder HEIC verarbeitet werden sollen. Ohne sie bleibt die Verarbeitung auf PDF beschränkt.
• Ausreichend Speicherplatz und Rechte: Der Webserver-Benutzer muss die Werkzeuge ausführen dürfen. In restriktiv geharteten Umgebungen ist das nicht selbstverständlich.

Wer die offizielle All-in-One-Distribution verwendet, hat es an dieser Stelle leichter, weil dort ein Teil der Abhängigkeiten bereits im Image steckt. Bei klassischen Installationen auf einem eigenen Server – oder in einem Container, der nur die Nextcloud selbst enthält – muss man die genannten Pakete nachziehen. Das ist kein Hexenwerk, aber es ist der Schritt, den man in der Dokumentation am ehesten überliest.

Noch ein Hinweis zu den Laufzeitgrenzen: Die OCR-Verarbeitung läuft serverseitig, und zwar mit den Rechten des Webserver-Benutzers. In Shared-Hosting-Umgebungen mit stark beschnittenen Shells funktioniert das entweder gar nicht oder nur mit Ausnahmen. Wer also vorhat, Workflow OCR auf einem Billigtarif zu betreiben, sollte vorher prüfen, ob überhaupt externe Prozesse gestartet werden dürfen.

Die Regel richtig zuschneiden

Die Konfiguration selbst ist unspektakulär – und genau deshalb wird sie häufig nachlässig gemacht. Eine typische Regel sieht so aus: Ereignis „Datei wurde hochgeladen“, Bedingung „Dateiname endet auf .pdf und Ordner ist /Scan-Eingang“, Aktion „OCR durchführen“. Der Teufel steckt in den Details.

Das wichtigste Detail ist die Schleifenvermeidung. Wenn die OCR-Ausgabe im selben Ordner landet und ebenfalls auf .pdf endet, greift die Regel erneut – auf die bereits verarbeitete Datei. Theoretisch entsteht so eine Endlosschleife, praktisch fällt sie oft erst auf, wenn der Speicher voll ist oder die Job-Queue dreihundert Einträge zeigt. Es gibt mehrere saubere Wege heraus. Der eleganteste ist ein Tag: Nach erfolgreicher Verarbeitung bekommt die Datei ein Merkmal wie ocr-erledigt, und die Bedingung lautet zusätzlich „hat nicht das Tag ocr-erledigt“. Alternativ kann man die Ausgabedateien mit einem Suffix versehen und die Regel so bauen, dass Dateien mit diesem Suffix ausgeschlossen werden. Beides funktioniert; die Tag-Variante ist robuster, weil sie unabhängig vom Dateinamen greift.

Der zweite wichtige Punkt ist die Frage, was mit dem Original passiert. Die App kann die Ausgabe überschreiben, eine neue Datei daneben legen oder das Original löschen. In Archivumgebungen ist Überschreiben heikel, weil sich damit die Datei unter der Hand ändert – der Hash, den ein Prüfsystem vorher gebildet hat, stimmt nicht mehr. Wer revisionssicher arbeiten muss, legt besser eine neue Datei an und behandelt das Original als unveränderlichen Eingang. Wer es umgekehrt handhabt und eine Textebene nachträglich einbaut, sollte sich über die Konsequenzen im Klaren sein.

Drittens: Bedingungen nicht zu grob wählen. Eine Regel, die auf alle PDFs im Haus losgeht, produziert Rechenlast ohne Ende. Besser ist die Konzentration auf definierte Eingangsordner oder auf Dateien mit einem bestimmten Merkmal. In der Praxis hat sich eine zweistufige Struktur bewährt – ein „Eingang“-Ordner, in dem alles landet, und ein Archivordner, in den die verarbeiteten Dokumente wandern. Damit bleibt die Regel schlank und ist leicht zu überblicken.

Und viertens, ein Punkt, der oft vergessen wird: Testen mit echten Dateien. Der eine Scan vom Kopierer verhält sich anders als die 300-seitige Satzung mit zweispaltigem Layout. Wer die Regel erst nach dem Rollout mit dem Produktivbestand prüft, lernt seine Umgebung auf die schmerzhafte Weise kennen.

Qualitätsregler: Was man einschalten sollte und was nicht

Die App erlaubt eine Reihe von Vorverarbeitungsschritten, die OCRmyPDF bereitstellt. Sie klingen nach Detailarbeit, haben aber erheblichen Einfluss auf die Erkennungsrate – und auf die Laufzeit. Die wichtigsten seien kurz sortiert.

Deskew und Rotation korrigieren schief eingezogene Seiten und falsch orientierte Scans. Bei Material aus einem Einzugsscanner bringt das selten viel, bei Handyfotos oder Flachbettvorlagen dagegen eine Menge. Der Aufwand hält sich in Grenzen, die Wirkung ist meist positiv. Wer viel gemischtes Material verarbeitet, sollte beides aktivieren.

Clean ruft unpaper auf und versucht, Rauschen, Verunreinigungen und schiefe Ränder zu entfernen. Das klingt verlockend, kann aber nach hinten losgehen: Handschriftliche Randnotizen oder feine Linien verschwinden gern mit. Für maschinell gedruckte Geschäftsdokumente ist es meist ein Gewinn, für historisches Material eher nicht.

Optimize steuert die Kompression des Ergebnisses. Stufe 1 ist verlustfrei und vergrößert die Datei tendenziell, Stufe 2 und 3 arbeiten verlustbehaftet und können die Dateigröße deutlich senken. Bei reinen Archivdokumenten ist das ein relevanter Faktor, gerade wenn über Jahre hinweg große Mengen zusammenkommen. Allerdings kostet die Optimierung Rechenzeit – und bei mehreren hundert Seiten pro Tag merkt man das.

PDF/A ist für alle relevant, die Dokumente langfristig aufbewahren müssen. Der Standard schränkt ein, was in einer Datei erlaubt ist, und sorgt dafür, dass sie in zehn oder zwanzig Jahren noch darstellbar ist. Der Nachteil: Der Schritt ist langsam und bläht Dateien auf. Wer beides braucht – schnelle Suche und langfristige Aufbewahrung – fährt oft zweigleisig: ein Arbeits-PDF mit Textebene und ein PDF/A-Archivstand.

Spannend ist auch die Wahl der Ausgabestruktur. Neben der eingebetteten Textebene kann man sich separat extrahierten Text ausgeben lassen. Das ist praktisch, wenn nachgelagerte Systeme – Volltextindex, KI-Pipeline, Klassifikator – den reinen Text brauchen und nicht jedes Mal das PDF parsen sollen. Für Suche innerhalb von Nextcloud genügt die Textebene; für alles Weitere ist eine Textdatei oft die angenehmere Schnittstelle.

Sprachen, Wörterbücher und die Erkennungsrate

Ein unterschätzter Faktor ist die Sprachkonfiguration. Tesseract arbeitet mit trainierten Modellen pro Sprache, und diese Modelle können kombiniert werden – etwa Deutsch plus Englisch für Dokumente, in denen Fachbegriffe gemischt auftreten. Die Kombination kostet Zeit, verbessert aber die Erkennung in genau diesen Mischtexten erheblich. Wer nur mit dem englischen Standardmodell arbeitet, wird bei deutschen Umlauten und Fachbegriffen regelmäßig enttäuscht.

Umgekehrt gilt: Zu viele Sprachen gleichzeitig verschlechtern das Ergebnis. Tesseract muss dann bei jedem Zeichen gegen mehrere Modelle abwägen und produziert mehr Verwechslungen. In der Praxis sind zwei, maximal drei Sprachen ein vernünftiger Rahmen. Wer ganze Archive mit unterschiedlichsten Beständen verarbeitet, sollte die Sprachwahl nicht global, sondern pro Regel festlegen – also eine Regel für den deutschsprachigen Eingang, eine andere für internationale Korrespondenz.

Ergänzend lohnt sich ein Blick auf die Auflösung. Tesseract mag etwa 300 dpi. Sehr hochauflösende Scans bringen kaum mehr Genauigkeit, kosten aber deutlich mehr Zeit; sehr niedrig aufgelöste Scans – etwa aus einem Fax oder einer verkleinerten Kopie – lassen sich dagegen kaum retten. Manche Häuser setzen deshalb im Scannerprofil an, statt hinterher zu reparieren. Das ist der billigere Weg.

Asynchronität, Monitoring und der Alltag im Betrieb

Ist die Regel einmal scharf, beginnt der eigentliche Betrieb. Und der ist geprägt von der Frage, wie viel Arbeit gleichzeitig laufen darf. OCR ist CPU-intensiv und lässt sich nur begrenzt parallelisieren. Tesseract kann intern mehrere Threads nutzen, OCRmyPDF kann mehrere Seiten gleichzeitig verarbeiten – aber beides konkurriert um dieselben Kerne. Auf einem Server, der gleichzeitig Dateioperationen, Datenbankabfragen und vielleicht noch Collabora bedient, ist Vorsicht angebracht.

Als Faustregel gilt: Ein Vierkern-Server mit acht Gigabyte Arbeitsspeicher schafft problemlos die üblichen Büromengen – also ein paar Dutzend Seiten am Tag –, solange nicht mehrere OCR-Jobs gleichzeitig auf dieselben Kerne losgelassen werden. Sobald ganze Altbestände migriert werden sollen, ändert sich das Bild. Dann empfiehlt es sich, die Verarbeitung zeitlich zu entzerren, also nachts laufen zu lassen oder das Ganze auf einen separaten Worker-Rechner auszulagern.

Beobachtbarkeit ist in diesem Zusammenhang kein Schlagwort, sondern praktische Notwendigkeit. Die App schreibt in die Nextcloud-eigene Logdatei, und die ist bei aktiviertem Debug-Level reichlich gesprächig. Sinnvoll ist ein Blick in die Job-Queue: Wie viele Einträge stehen an, wie alt sind sie, gibt es welche, die wiederholt scheitern. Fehlgeschlagene Jobs sind die häufigste Ursache für den Eindruck, OCR funktioniere nicht.

Für die Nachverarbeitung bestehender Bestände gibt es verschiedene Wege. Neue Uploads sind trivial, weil das Ereignis sie auslöst. Bestehende Sammlungen lassen sich je nach App-Version über einen Kommandozeilenaufruf nachziehen, andernfalls über einen Durchlauf, bei dem Dateien erneut in den Eingangsordner gespielt werden. Beides ist Handarbeit, und das sollte man ehrlich einplanen: Eine Migration von zwanzigtausend gescannten Seiten ist kein Nachmittagsprojekt, sondern ein Vorgang über mehrere Tage, der auf einem ausgelasteten Server nichts zu suchen hat.

Grenzen der Technik

Man tut dem Thema keinen Gefallen, wenn man die Erfolgsgeschichten erzählt und die Einschränkungen verschweigt. Klassisches OCR erkennt gedruckten Text. Handschrift ist für Tesseract weitgehend ein Fremdwort; es gibt experimentelle Modelle, aber nichts, worauf man einen Geschäftsprozess bauen würde. Formulare mit Kästchen und Linien bereiten ebenfalls Mühe, Tabellen werden selten in einer Struktur ausgegeben, die man maschinell weiterverwenden kann. Mehrspaltige Layouts – Zeitungsartikel, Satzungen, Beipackzettel – führen dazu, dass die Textebene Zeilen aus zwei Spalten mischt. Durchsuchbar ist das Ergebnis dann, aber die Trefferqualität sinkt.

Hinzu kommt: Die Textebene ist keine Wahrheit. Sie ist eine Wahrscheinlichkeitsaussage über das, was auf dem Papier stand. Bei sauberem Druckmaterial liegt die Zeichengenauigkeit im hohen neunziger Bereich, bei schlechten Vorlagen rutscht sie deutlich darunter. Für die Suche ist das unproblematisch – ein falsch erkannter Buchstabe bleibt in aller Regel in der Nachbarschaft des gesuchten Wortes. Für eine automatisierte Weiterverarbeitung, in der Beträge oder Vertragsnummern extrahiert werden, sind das dagegen gefährliche Abweichungen. Wer darauf aufbauen will, braucht eine Validierung mit Plausibilitätsprüfungen, nicht bloß einen Textextraktor.

Ein weiterer, gern übersehener Punkt: Die Textebene ist selbst Datenmaterial. Ein Vertrag, der als Bild vorlag, war für eine automatische Indexierung unlesbar. Nach der OCR ist er maschinell erfassbar – auch für Dienste, die man vielleicht gar nicht im Haus haben will. Wer also eine Textebene erzeugt, sollte sich überlegen, in welchen Ordnern sie liegen darf und wer darauf Zugriff hat. Andernfalls entsteht unbemerkt ein zweiter, maschinenlesbarer Datenbestand neben dem ursprünglichen.

Und schließlich die Kostenfrage. OCR ist nicht teuer, aber auch nicht kostenlos. Jede Seite braucht Rechenzeit, jede zusätzliche Option – Clean, PDF/A, Optimierung – erhöht sie weiter. Auf stromsparsamen Mini-Servern ist die Verarbeitung eines umfangreichen Bestands daher keine Frage von Minuten. Wer das einmal durchgerechnet hat, entscheidet die Frage „alles nachträglich OCRen“ erstaunlich oft anders, als er sie vorher gestellt hat.

Was die Volltextsuche anders macht

In der Nextcloud-Welt gibt es neben dem hier diskutierten Weg noch einen zweiten Ansatz: Volltextsuche mit Elasticsearch oder OpenSearch. Dabei werden Dokumente in einen Suchindex überführt, der deutlich mehr kann als eine lokale Suche – Stemming, Ranking, Filter, Fuzzy-Matching. Für PDFs und Office-Dateien gibt es Ingest-Pipelines, und für gescannte Texte existiert ein zusätzlicher Baustein, der Tesseract in die Indexierungspipeline einhängt.

Die beiden Verfahren schließen sich nicht aus, sondern ergänzen sich. Workflow OCR erzeugt die Textebene in der Datei selbst – ein bleibender Bestandteil des Dokuments, der überall dort verfügbar ist, wo das PDF geöffnet wird, auch außerhalb der Cloud. Die Volltextsuche dagegen erzeugt einen Index, der bei Bedarf neu aufgebaut werden kann und nicht Teil des Dokuments ist, aber viel bessere Suchfunktionen bietet. Wer beides betreibt, hat ein durchsuchbares Dokument und eine erstklassige Suche; wer nur eines hat, muss Kompromisse eingehen.

Wichtig ist die Reihenfolge. Ein Index, der über ein Bild-PDF gebildet wurde, enthält keinen Text. Die OCR muss also vor oder während der Indexierung passieren. In der Praxis heißt das: Wer eine Volltextsuche aufbaut, sollte sich überlegen, ob die Textebene zentral erzeugt wird und der Indexer nur noch einsammelt – oder ob der Indexer selbst OCR betreibt. Beides hat Vor- und Nachteile; die zentrale Variante ist meist diejenige, die man später leichter nachvollziehen kann.

Datenschutz und Compliance

Ein Argument, das in der aktuellen Diskussion oft zu kurz kommt: Lokal betriebenes OCR ist ein Datenschutzvorteil. Die Verarbeitung findet auf dem eigenen Server statt, die Dokumente verlassen das Haus nicht, es gibt keine API-Aufrufe zu einem Cloud-Dienst und damit auch keine Auftragsverarbeitung mit einem Dritten. Für Kanzleien, Arztpraxen, Steuerberater und öffentliche Stellen ist das kein Nebenaspekt, sondern häufig das entscheidende Kriterium.

Daraus folgt aber auch eine Verpflichtung. Wenn die Verarbeitung lokal stattfindet, liegt die Verantwortung für die Ergebnisse ebenfalls lokal. Es gibt keinen Anbieter, der für fehlerhafte Erkennung haftet. Es gibt niemanden, der die Löschfristen verwaltet. Und es gibt keine externe Instanz, die Audit-Logs führt. Alles das muss die eigene Organisation leisten – was machbar ist, aber eingeplant werden sollte.

Ein praktisch relevanter Punkt ist die Verschlüsselung. Nextcloud kann Dateien serverseitig verschlüsseln, etwa für externe Speicher oder bei bestimmten Verschlüsselungsmodulen. Das ist gut für die Ruhe der Daten, aber es hat Konsequenzen für die Verarbeitung: Ein OCR-Werkzeug, das als externer Prozess auf eine Datei zugreift, braucht Zugang zum Klartext. In der Praxis ist das meist unproblematisch, weil die Verschlüsselung transparent arbeitet – aber wer an dieser Stelle mit eigenen Schlüsselverwaltungen oder externen Krypto-Lösungen arbeitet, sollte vorher testen, ob die Pipeline noch durchläuft.

Und dann ist da noch das Thema Aufbewahrung. Ein durchsuchbares PDF ist ein anderes Dokument als der ursprüngliche Scan, auch wenn der Inhalt optisch identisch wirkt. Wer Aufbewahrungsfristen auf Datei-Ebene verwaltet, sollte wissen, dass nach der OCR zwei Versionen desselben Vorgangs existieren können – die ursprüngliche Bilddatei und die angereicherte Variante. Ohne klare Regel, welche davon aufbewahrt und welche gelöscht wird, wächst der Bestand schneller als geplant.

Alternativen und Nachbarn

Nextcloud Workflow OCR ist nicht die einzige Option, und es wäre unseriös, das zu behaupten. Wer vor einer grundsätzlichen Entscheidung steht, sollte die Nachbarschaft kennen.

Für alle, die Dokumentenverarbeitung als Kernprozess betreiben, ist Paperless-ngx die naheliegende Alternative. Es ist ein ausgewachsenes Dokumentenmanagementsystem mit OCR an Bord, eigener Klassifikation, Volltextsuche und einer Konsumentenlogik, die eingehende Dateien automatisch einsortiert. Wer hauptsächlich Belege, Rechnungen und Verträge verarbeitet, ist damit oft besser bedient als mit einer Nextcloud-Erweiterung. Der Preis dafür ist ein zweites System, das betrieben, gesichert und erklärt werden muss.

Als Werkzeug für Einzelfälle hat sich Stirling PDF etabliert, eine selbst gehostete Sammlung von PDF-Operationen mit OCR-Funktion. Es ist kein Workflow, aber für den Anwender, der gelegentlich ein Dokument nachbearbeiten will, angenehm niedrigschwellig. Auch OCRmyPDF selbst lässt sich direkt nutzen – in Skripten, Cronjobs oder über die App „Workflow Script“, mit der sich beliebige Kommandos an Dateiereignisse hängen lassen. Wer bereit ist, ein paar Zeilen Shell zu schreiben, kommt damit sehr weit.

Und dann sind da die Cloud-Dienste. Die Erkennungsqualität kommerzieller Anbieter, gerade bei Handschrift und komplexen Layouts, liegt über dem, was Tesseract leistet. Das ist unbestritten. Der Preis ist die Datenübermittlung an Dritte, mit allen Konsequenzen für Auftragsverarbeitung, Aufbewahrung und Prüfpflichten. In manchen Branchen ist das schlicht ausgeschlossen, in anderen eine bewusste Abwägung. Pauschal lässt sich das nicht entscheiden.

Ein Praxisbeispiel

Zur Veranschaulichung ein Szenario, wie es in dieser Form regelmäßig vorkommt: Eine Hausverwaltung mit rund 1.800 Wohneinheiten erhält pro Monat etwa 900 Eingangsdokumente – Handwerkerrechnungen, Nebenkostenbelege, Eigentümerbeschlüsse, Versicherungsschreiben. Ein Teil kommt per Post und wird gescannt, ein Teil als PDF per Mail, ein weiterer Teil über ein Upload-Formular auf der eigenen Website. Die Verwaltung arbeitet mit Nextcloud als Dateiablage und einem Buchhaltungssystem, das per Schnittstelle angebunden ist.

Vor der Umstellung lagen die Scans in einem Eingangsordner, wurden von einer Mitarbeiterin gesichtet, umbenannt, in Unterordner verschoben und teilweise abgetippt. Der Aufwand lag bei etwa zwanzig Stunden im Monat, die Fehlerquote war nicht trivial – Rechnungen verschwanden, Belege wurden doppelt erfasst. Nach der Umstellung gibt es zwei Flow-Regeln. Die erste greift auf PDFs im Upload-Ordner und in einem Scan-Eingangsordner, verarbeitet sie mit OCR, versieht sie mit dem Tag ocr-fertig und legt eine Textdatei daneben. Die zweite greift auf Dateien mit diesem Tag und schickt eine Benachrichtigung an die Buchhaltung, die daraufhin im Volltextindex sucht statt zu blättern.

Der Effekt war nicht dramatisch im Sinne einer Halbierung der Arbeitszeit, aber spürbar: Die Sichtung fällt weg, die Suche funktioniert, und die Nachvollziehbarkeit ist besser, weil sich Belege über Stichworte wiederfinden lassen. Bemerkenswert ist ein Detail, das in der Planung niemand auf dem Schirm hatte: Die Mitarbeiter begannen, in den PDFs Anmerkungen zu machen, weil sie die Textebene für Kommentare nutzen konnten. Aus einem Nebeneffekt wurde ein Arbeitsmittel.

Ausblick: Von OCR zu Dokumentenverständnis

Wer heute eine OCR-Pipeline baut, baut streng genommen eine Vorleistung für etwas, das erst noch kommt. Denn die aktuelle Entwicklung geht klar in Richtung Dokumentenverständnis. Modelle, die nicht nur Zeichen erkennen, sondern Layouts interpretieren, Tabellen rekonstruieren, Felder benennen und Zusammenhänge zwischen Absätzen herstellen, sind bereits verfügbar – und sie werden kleiner und lokal betreibbar.

Nextcloud selbst arbeitet seit einigen Versionen an einem Assistenten-Framework, das lokale Sprachmodelle einbindet, sowie an einer Kontextsuche, die Dokumente in einen Vektorindex überführt und Fragen dazu beantwortet. Diese Systeme brauchen Text. Ein eingescanntes Dokument ohne Textebene ist für sie unsichtbar. Damit wird OCR von einer Komfortfunktion zu einer Grundvoraussetzung: Ohne Textebene keine Einbettung, ohne Einbettung keine semantische Suche.

Spannend ist dabei die Kombination. Tesseract liefert den Rohtext, ein Sprachmodell räumt die Erkennungsfehler auf, ein Klassifikator ordnet das Dokument ein, ein Extraktor zieht die relevanten Felder heraus. Jeder Schritt ist für sich genommen fehlbar, aber die Kette ist robuster als die einzelne Komponente. Wer heute eine solide OCR-Basis aufbaut, hat morgen die Möglichkeit, darauf aufzusetzen – ohne die Grundlage neu erfinden zu müssen.

Fazit

Nextcloud Workflow OCR ist kein spektakuläres Produkt. Es ist ein Werkzeug, das eine unspektakuläre Aufgabe zuverlässig erledigt, wenn man ihm die richtigen Voraussetzungen schafft. Wer die Abhängigkeiten sauber installiert, die Regeln sorgfältig zuschneidet und den Betrieb nicht aus dem Blick verliert, bekommt dafür eine durchsuchbare Ablage, die sich in bestehende Abläufe einfügt, statt sie umzuwerfen.

Der Aufwand liegt weniger in der Installation als in der Konzeption: Welche Dateien sollen verarbeitet werden, welche nicht, wo landet das Ergebnis, wie wird eine Schleife verhindert, was passiert mit dem Original. Diese Fragen kostet keine Software der Welt. Und genau dort entscheidet sich, ob eine OCR-Pipeline nach drei Monaten noch läuft oder stillschweigend verstopft. Wer sich die Zeit für die Konzeption nimmt, hat danach ein System, das jahrelang unauffällig seinen Dienst tut – und das ist in der IT bekanntlich die höchste Form von Lob.