Der Schritt, den alle in der Dokumentenautomatisierung überspringen (und warum Ihre OCR scheitert)

Sie haben die API angebunden. Sie haben die OCR eingerichtet. Sie haben sogar ein LLM eingebunden, das die Felder extrahiert. Und trotzdem kommt jedes fünfte Dokument verstümmelt zurück: ein Lieferantenname, der als SMlTH & S0NS gelesen wird, ein Betrag von €1.204 statt €1.204,50, ein Rechnungsdatum, das einfach verschwunden ist.

Hier ist die unbequeme Wahrheit: Das Problem ist meist nicht Ihre OCR. Es ist das, was Sie ihr füttern.

Müll rein, Müll raus

OCR-Engines und LLM-Extraktoren sind bemerkenswert gut, wenn sie saubere, flache, korrekt ausgerichtete Dokumente lesen. Schlecht sind sie bei dem, was in der Realität tatsächlich ankommt:

• Ein Lieferschein, der leicht schräg fotografiert wurde
• Eine Vertragsseite mit einem Knick quer durch die Unterschrift
• Eine Rechnung unter der Schreibtischlampe, halb im Schatten
• Ein Kassenbon, bei dem die obere rechte Ecke abgeschnitten ist

Werfen Sie irgendeines davon in Ihre OCR-Pipeline, verschlechtert sich das Ergebnis, nicht weil das Modell schlecht ist, sondern weil die Geometrie des Dokuments falsch ist, bevor auch nur ein Zeichen gelesen wird.

Der fehlende Schritt: der saubere Scan

Zwischen „Kamerafoto" und „OCR" gibt es einen Schritt, den fast jede Automatisierung überspringt:

Foto  →  sauberer Scan  →  OCR / KI-Extraktion  →  strukturierte Daten

Der „saubere Scan" ist der Punkt, an dem aus einer Rohaufnahme ein maschinenlesbares Dokument wird:

• Perspektivkorrektur — ein schräg aufgenommenes Dokument gerade ausrichten
• Zuschneiden & Ausrichten — die Seitenränder finden, das Dokument korrekt ausrichten
• Wölbung glätten — die Biegung eines dicken Dokuments oder einer gekrümmten Seite ausgleichen
• Schatten & Reflexionen entfernen — das Licht vereinheitlichen, damit kein Text verloren geht

Nichts davon ist OCR. Alles davon entscheidet darüber, ob Ihre OCR funktioniert.

Ein konkretes Beispiel: der Lieferschein

Nehmen wir einen Lieferschein, wie ihn ein Fahrer bei Regen auf einer Laderampe mit dem Handy in einer Hand fotografiert.

Direkt in die OCR geschickt, bekommen Sie vielleicht ein paar Textfragmente. Aber die Felder, die Ihr Workflow wirklich braucht, sind ein Glücksspiel.

Läuft dasselbe Foto zuerst durch einen Scan-Schritt, ist der Unterschied wie Tag und Nacht:

{
  "supplier": "ACME Logistics GmbH",
  "delivery_date": "2026-08-21",
  "delivery_note_number": "DN-1042",
  "items": [
    { "name": "Pallet", "quantity": 3 },
    { "name": "Crate", "quantity": 7 }
  ]
}

(Fiktives Beispiel, alle Werte sind erfunden.)

Das sind die Daten, die Ihre Anwendung automatisch erhalten und verarbeiten könnte, weil die Geometrie korrigiert wurde, bevor der Text gelesen wurde.

Warum das für No-Code-Teams wichtig ist

Wenn Sie mit n8n, Zapier oder Make arbeiten, kennen Sie das Problem: Es gibt einen „OCR-Node", aber Ihre gescannten Dokumente kommen trotzdem falsch an. Der Grund ist, dass die meisten OCR-Tools davon ausgehen, dass die Eingabe bereits sauber ist.

Die Lösung ist ein kleiner, auf eine Sache spezialisierter Schritt vor Ihrer OCR: eine Dokumenten-Scan-API, die das Foto entgegennimmt und den sauberen Scan zurückgibt, sodass Ihr OCR-Node und das LLM dahinter endlich Eingaben bekommen, die sie lesen können.

Foto rein. Sauberer Scan raus. Dann erledigt der Rest Ihres Workflows das, wofür er gebaut wurde.

Warum es für Entwickler wichtig ist

Dieselbe Logik gilt, wenn Sie die Integration selbst bauen. Sie brauchen keine monolithische Dokumentenverarbeitungsplattform. Sie brauchen eine zuverlässige Komponente, die das Scan-Problem löst, damit Sie weiterhin die OCR, das LLM oder das ERP nutzen können, das Sie bereits haben.

• Ein Aufruf: POST /scan/crop
• Foto oder PDF rein, sauberes JPG oder PDF raus
• Ihr bestehender Extraktions-Stack bleibt unverändert

Ein Hinweis dazu, wo die Daten leben

Dokumentfotos sind sensibel. Gerade für EU-Unternehmen ist es oft ein Compliance-Problem, Kundendokumente an einen in den USA gehosteten OCR-Dienst zu schicken, bevor es überhaupt ein technisches Problem ist. Achten Sie auf einen Scan-Schritt, der in der EU gehostet wird, Daten bei der Übertragung verschlüsselt und Dokumente nach der Verarbeitung löscht. Nur Ihr sauberer Scan sollte die Anfrage verlassen.

---

Das Fazit: OCR scheitert nicht, weil OCR schlecht ist. Sie scheitert, weil niemand vorher das Dokument in Ordnung gebracht hat. Fügen Sie diesen Scan-Schritt ein, und Ihre bestehende Automatisierung wird spürbar zuverlässiger.

Sie möchten den Unterschied sehen? Schicken Sie ein echtes Dokument durch den ScanKit-Scanner, ganz ohne Kreditkarte.