Jedes mittelgroße Fertigungsunternehmen in der SK/EU verarbeitet täglich Dutzende bis Hunderte papierbasierter oder eingescannter Dokumente — Lieferantenrechnungen, Kundenbestellungen, Lieferscheine, Zollanmeldungen, technische Zeichnungen mit Maßangaben. Und bei den meisten davon sitzt irgendwo ein Mitarbeiter, der Werte manuell ins ERP, SAP oder Excel überträgt. Das ist kein Problem, das Unternehmen ignorieren — es ist ein Problem, das sich bisher einfach nicht anders zu lösen lohnte.
Im Jahr 2026 hat sich das geändert. Moderne Document-Intelligence-Systeme — eine Kombination aus OCR (optischer Zeichenerkennung), Vision-Language-Modellen und Validierungslogik — können strukturierte und halbstrukturierte Dokumente mit einer Genauigkeit verarbeiten, die manuelle Erfassung nicht erreicht. Dieser Artikel erklärt, wo sich diese Technologie lohnt, wie ein reales Deployment aussieht und wo die Grenzen liegen, über die kein Marketingmaterial informiert.
Warum klassisches OCR nicht ausreicht
Wenn die meisten Menschen „OCR" hören, denken sie an Tesseract oder Adobe Acrobat — Tools, die aus einem eingescannten Text editierbaren Text machen. Für einfache Fälle reicht das. Für industrielle Dokumente nicht.
Die Probleme entstehen auf mehreren Ebenen gleichzeitig:
- Verwackelte oder schiefe Scans aus einer 30 Jahre alten Faxrechnung bringen klassisches OCR weit mehr aus dem Tritt als ein modernes VLM-Modell.
- Tabellen, Maßangaben und Schemata sind für textbasiertes OCR ein blinder Fleck — man bekommt die richtigen Zeichen, verliert aber die Struktur, aus der die Bedeutung erst entsteht.
- Formatvielfalt: Jeder Lieferant hat eine eigene Rechnungsvorlage. Klassische OCR-Lösungen begegnen dem mit regelbasierten Extraktionsschemas pro Vorlage (rule-based extraction) — bei Dutzenden Lieferanten bedeutet das Dutzende Templates und permanente Wartung.
- Kontextueller Sinn: Die Zahl „1500" in der rechten unteren Ecke einer Seite kann eine Seitenzahl, eine Bestellnummer oder ein Betrag in Euro sein — ohne Kontext kann klassisches OCR nicht unterscheiden.
Moderne VLM-Modelle (Vision-Language-Modell, z. B. Qwen2.5-VL) lösen dieses Problem anders: Sie lesen nicht nur Zeichen, sondern verstehen das Layout und den Kontext des Dokuments. Das ist ein qualitativer Sprung, keine Evolution.
Wie eine Document-Intelligence-Pipeline aussieht
Eine reale Industriepipeline zur Dokumentenverarbeitung besteht aus mehreren Schichten. Jede davon kann ein Fehlerpunkt sein, wenn sie unterschätzt wird.
1. Ingestion und Normalisierung
Das Dokument kommt als gescanntes PDF, Smartphone-Foto, E-Mail-Anhang oder EDI-Export aus einem Altsystem. Der erste Schritt ist die Überführung in ein einheitliches internes Format — mit Metadaten (Quelle, Eingangsdatum, Dokumenttyp).
Hier steckt ein verstecktes Problem: Bei Fotos aus dem Feld ist die Eingangsqualität extrem variabel. Unscharf, abgedunkelt, gefaltet — damit kommt ein VLM besser zurecht als klassisches OCR, aber nicht unbegrenzt besser. Die Eingangsqualität begrenzt nach wie vor die Ausgangsqualität.
2. Dokumentklassifikation
Bevor die Extraktion startet, muss das System wissen, was es verarbeitet. Rechnung, Bestellung, Lieferschein und technische Zeichnung erfordern unterschiedliche Extraktionsschemata. Ein Klassifikator (entweder ein einfaches Modell oder regelbasierte Logik über die Dokumentstruktur) ordnet das Dokument der richtigen Kategorie zu.
3. Strukturierte Extraktion
Das Kernstück der Pipeline: Aus dem Dokument werden Werte gemäß einem vordefinierten Schema extrahiert. Für eine Rechnung sind das typischerweise:
- Rechnungsnummer, Ausstellungsdatum, Fälligkeitsdatum
- USt-IdNr. und Steuernummer von Lieferant und Empfänger
- Zeilenpositionen (Beschreibung, Menge, Einheit, Nettopreis, MwSt., Bruttopreis)
- Gesamtbetrag, Bankkontonummer, Verwendungszweck
VLM-Modelle bewältigen das direkt — sie erhalten ein Bild oder PDF als Eingabe und liefern JSON gemäß dem angegebenen Schema zurück. Die Ausgabe entspricht dem Konzept der Structured Outputs und des JSON-Modus — das Modell produziert ausschließlich valides JSON mit definierten Feldern.
Für technische Zeichnungen ist die Situation anspruchsvoller: Maßangaben, Toleranzen und Materialspezifikationen sind im geometrischen Kontext des Schemas verstreut. VLM-72B-Modelle haben hier deutliche Fortschritte gemacht, aber für präzise technische Dokumente empfiehlt sich ein Human-in-the-Loop für die abschließende Verifikation kritischer Werte.
4. Validierung und Cross-Check
Die extrahierten Werte durchlaufen mehrere Validierungsschichten:
- Mathematische Konsistenz: Die Summe der Einzelpositionen muss dem Gesamtbetrag entsprechen; die MwSt. muss mit dem angegebenen Steuersatz übereinstimmen.
- Referenzvalidierung: Die Bestellnummer auf der Rechnung muss im ERP existieren; die USt-IdNr. des Lieferanten muss in der Datenbank genehmigter Lieferanten vorhanden sein.
- Bereichsvalidierung: Rechnungsbetrag im für diesen Lieferanten typischen Rahmen (Ausreißer gehen zur manuellen Prüfung).
Diese Validierungsschicht ist entscheidend. In der Praxis haben wir Fälle gesehen, wo das Modell die Zahlen korrekt aus dem Dokument extrahiert hat, der Rechnungsbetrag aber nicht der Summe der Positionen entsprach — der Fehler lag im Originaldokument, nicht in der Extraktion. Ohne Validierung würde das ERP inkonsistente Daten enthalten.
5. ERP-Integration und Workflow
Validierte Datensätze werden über eine API ans ERP übergeben. Dokumente mit niedrigem Confidence-Wert (das Modell ist sich bei einem Wert unsicher) oder mit fehlgeschlagener Validierung gehen in eine Warteschlange zur manuellen Prüfung — mit Markierung des konkreten Feldes, das problematisch ist.
Das ist der richtige Ansatz: keine vollständige Automatisierung, sondern assistierte Automatisierung mit einem klaren Human-in-the-Loop dort, wo Unsicherheit besteht.
Wo sich Automatisierung lohnt — und wo nicht
Nicht jeder Dokumenttyp ist gleich gut für Automatisierung geeignet. Auf Basis realer Deployments lässt sich sagen:
Sehr gut geeignet: - Rechnungen von wiederkehrenden Lieferanten (das System „lernt" das Format) - Standardisierte Bestellformulare (eigene und von Handelspartnern) - Lieferscheine mit Barcodes oder QR-Codes (Hybrid-Ansatz OCR + Barcode) - Materialnachweise mit definierter Struktur
Geeignet mit Einschränkungen: - Rechnungen von neuen Lieferanten (erste Verarbeitung erfordert erhöhte Kontrolle) - Per E-Mail eingegangene Bestellungen als Plain-Text oder HTML — hier kann ein LLM über dem E-Mail-Body besser funktionieren als OCR über einem Bild - Technische Datenblätter mit Parametertabellen
Weniger geeignet ohne Speziallösung: - Handschriftliche Dokumente, altes Fax mit schlechter Qualität - Technische Zeichnungen mit komplexen geometrischen Schemata und Toleranzen — Extraktion funktioniert, erfordert aber Verifikation - Verträge und rechtliche Dokumente mit komplizierter Struktur (hier ist ein LLM über industrieller Dokumentation wertvoller als eine reine OCR-Pipeline)
Technische Entscheidungen — Cloud vs. On-Prem
Die meisten Unternehmen, mit denen wir arbeiten, stehen vor der Frage: Cloud-API oder eigene Installation?
Cloud-API (Azure AI Document Intelligence, Google Document AI, AWS Textract): - Schneller Start, keine eigene Infrastruktur - Pay-per-Page-Modell — bei großen Volumina (Zehntausende Dokumente pro Monat) können die Kosten erheblich sein - Rechnungen und Bestellungen enthalten geschäftssensible Daten — in regulierten Branchen oder bei interner DSGVO-Politik ist Cloud problematisch
On-Prem VLM (z. B. Qwen2.5-VL-72B quantisiert):
- Vollständige Datenkontrolle — kein Datenabfluss
- Höhere VRAM-Anforderungen: Ein 72B-Modell benötigt ein Multi-GPU-Setup (in der Größenordnung 40+ GB VRAM für Inferenz)
- Einmalige Hardwareinvestition, danach marginale Kosten nahe null bei steigendem Volumen
Für die meisten Industrieunternehmen in der EU ist das On-Prem-Argument stark, wenn das Volumen ausreicht (in der Größenordnung Tausende Dokumente pro Monat). Bei niedrigerem Volumen oder für einen schnellen Start kann ein Cloud-API ein sinnvoller Einstieg mit Migrationsplan sein.
Integration mit strukturierten Ausgaben und ERP
Ein kritisches Detail in dieser Pipeline ist die Zuverlässigkeit des Ausgabeformats vom LLM. Ein Modell, das mal sauberes JSON zurückgibt und mal JSON eingewickelt in einen Markdown-Block, ist für die automatisierte Integration unbrauchbar.
Moderne Modelle unterstützen Constrained Decoding — das Modell generiert Token gemäß einem definierten JSON-Schema und ist physisch nicht in der Lage, ungültiges JSON zurückzugeben. Das ist für Produktions-Deployments eine Notwendigkeit, keine Option. Mehr dazu im Artikel Structured Outputs und JSON-Modus.
Für die ERP-Integration gilt die Regel: Niemals direkt aus einem KI-Modell ins ERP schreiben. Das Standardmuster ist:
- 1.KI extrahiert und validiert → Ergebnis in eine Staging-Tabelle
- 2.Validierungsregeln (Skript oder Workflow-Engine) prüfen die Konsistenz
- 3.Bei Erfolg → automatischer Import ins ERP; bei Unsicherheit → Warteschlange zur manuellen Prüfung
- 4.Der menschliche Prüfer sieht das Dokument, die extrahierten Werte und das konkrete Feld mit dem Problem
Dieses Muster wahrt die Auditierbarkeit und verhindert stille Datenbeschädigung im ERP.
Technische Zeichnungen und technische Dokumentation
Eine eigene Kategorie bilden technische Zeichnungen — DXF, PDF mit Geometrie, Schaltpläne. Klassisches OCR ist hier nahezu unbrauchbar, da der Großteil der Information in den Beziehungen zwischen grafischen Elementen steckt, nicht im Text selbst.
Moderne VLM-Modelle können aus einer technischen Zeichnung extrahieren: - Maßangaben und Toleranzen (mit von der Eingangsqualität abhängiger Genauigkeit) - Beschreibungen von Materialien und Oberflächenbehandlungen - Bauteil- und Revisionsnummern
Wo nach wie vor menschliche Kontrolle notwendig ist: sicherheitskritische Toleranzen, Elektroinstallationspläne für ATEX-Bereiche, Dokumente für Zertifizierungsprozesse. KI hilft hier als Assistent, nicht als autonome Entscheidung — ähnlich wie beim KI-Copilot für Bediener, wo das Modell die Arbeit reduziert, aber die Verantwortung nicht ersetzt.
Häufige Fehler beim Deployment
Zum Abschluss des technischen Teils — Probleme, die wir wiederholt beobachten:
„Einrichten und vergessen" — eine Document-Intelligence-Pipeline braucht Monitoring. Ein neuer Lieferant mit einer ungewöhnlichen Rechnungsvorlage senkt den Confidence-Score und landet in der manuellen Warteschlange; das ist in Ordnung, aber die Warteschlange muss beobachtet werden.
Unterschätzung der Variabilität — im Pilot testen Sie 50 Rechnungen von 5 Lieferanten. In der Produktion haben Sie 500 Lieferanten, von denen einige ihre Vorlagen ohne Vorwarnung ändern. Testen Sie an einer vielfältigen Stichprobe, nicht an „sauberen" Fällen.
Confidence-Score ohne Kalibrierung — das Modell gibt eine Extraktionssicherheit an, aber diese Scores sind auf Trainingsdaten kalibriert, nicht auf Ihre Dokumente. In den ersten Wochen des Produktionseinsatzes beobachten Sie, wo das Modell „sicher" behauptet und doch falsch liegt — passen Sie entsprechend die Schwellenwerte für manuelle Prüfung an.
Edge Cases ignorieren — was passiert, wenn eine Rechnung auf Polnisch eingeht? Oder wenn ein PDF zwei Rechnungen enthält? Diese Fälle müssen explizit definiert und implementiert werden — darauf zu hoffen, dass das Modell damit schon irgendwie umgeht, reicht nicht.
Häufige Fragen
Wie genau sind moderne Systeme bei der Extraktion aus Rechnungen?
Für strukturierte Rechnungen von wiederkehrenden Lieferanten erreichen moderne VLM-Pipelines in der Praxis 95–99 % Genauigkeit bei Schlüsselfeldern (Rechnungsnummer, Betrag, Datum). Bei neuen oder nicht standardisierten Formaten ist die Genauigkeit geringer — daher ist die Validierungsschicht und die Warteschlange für manuelle Prüfung kritisch. Zahlen aus Marketingmaterialien (99,9 %) stammen in der Regel aus kontrollierten Tests, nicht aus realen Produktions-Deployments mit vollständiger Variabilität der Eingaben.
Braucht man für Document Intelligence eine GPU?
Für Cloud-APIs nicht — man zahlt für API-Aufrufe. Für On-Prem-Deployments mit VLM-Modellen (70B+) schon — man benötigt in der Größenordnung 40+ GB VRAM für vernünftige Inferenzlatenzen. Kleinere Modelle (7–14B) schaffen auch eine RTX 4090 (24 GB VRAM mit Quantisierung), aber mit geringerer Genauigkeit bei komplexen technischen Dokumenten. Für Rechnungen und Bestellungen reicht auch ein 7B-Modell mit guter Leistung.
Können wir das an unser bestehendes SAP / andere ERP-Systeme anbinden?
Ja — eine Document-Intelligence-Pipeline produziert strukturiertes JSON, das über ERP-APIs oder standardisierte Integrationsschnittstellen importiert werden kann (REST, IDOC für SAP, CSV-Import für einfachere Systeme). Die Integration selbst ist kein Problem; der größere Aufwand liegt in der Definition der Staging-Logik und der validierungsregeln, die auf Ihre spezifischen Geschäftsprozesse abgestimmt sind.
Was ist mit Dokumenten in verschiedenen Sprachen (Deutsch, Polnisch)?
Moderne VLM-Modelle sind mehrsprachig und bewältigen die meisten europäischen Sprachen ohne spezielle Konfiguration. Validierungsregeln (z. B. Format der Steuernummer, IBAN) müssen pro Land eingestellt werden. Wenn Sie große Volumina aus einem bestimmten Land verarbeiten, lohnt es sich, die Genauigkeit an realen Stichproben zu überprüfen — die Performance ist nicht immer sprachübergreifend identisch.
Wie lange dauert die Implementierung?
Einen einfachen Pilot für einen Dokumenttyp (z. B. Rechnungen von den Top-20-Lieferanten) kann man in 4–6 Wochen starten. Ein vollständiges Produktions-Deployment mit ERP-Integration, Monitoring und Abdeckung aller Dokumenttypen bewegt sich je nach Komplexität der Umgebung und Anzahl der Integrationspunkte im Bereich von 3–6 Monaten.
*MP Industrial Solutions unterstützt Unternehmen beim Übergang von manueller Dokumentenerfassung zu einem nachvollziehbaren, automatisierten Datenfluss — vom Pilot mit einem Rechnungstyp bis zum Produktions-Deployment mit ERP-Integration. Wenn Sie sich mit Document Intelligence beschäftigen oder überlegen, wo Sie anfangen sollen, beurteilen wir gern Ihren konkreten Fall.*