Rechnungs-OCR 2026: Der Test beginnt dort, wo die Demo endet
Eine OCR-API spart erst dann Zeit, wenn falsche Beträge nicht unbemerkt weiterlaufen. So testen Teams Erkennung, Review und Export als einen Rechnungsprozess.
Eine Rechnung kommt am Freitag um 16:47 Uhr herein: schiefer Scan, zwei Seiten, Skonto-Hinweis im Kleingedruckten. Die OCR liest den Bruttobetrag richtig, verwechselt aber das Leistungsdatum mit dem Rechnungsdatum. Wer nur auf eine hohe Erkennungsquote schaut, bemerkt den Fehler erst im Zielsystem. Wer einen brauchbaren Prozess gebaut hat, sieht eine Unsicherheit, prüft genau dieses Feld und lässt den Rest weiterlaufen.
Darum ist die Frage nach der besten Rechnungs-OCR falsch gestellt. Nicht eine API bearbeitet Rechnungen, sondern ein Ablauf aus Eingang, Extraktion, Plausibilitätsprüfung, menschlicher Ausnahmebehandlung und Export. Das Tool ist wichtig. Die Stelle, an der es stoppen darf, ist wichtiger.
Für einen einzelnen, nicht vertraulichen Dokumenttest ohne API gibt es den kostenlosen Utildesk-OCR-Testbetrieb. Das Ergebnis sollte vor einer Buchung oder weiteren Verarbeitung geprüft werden.
Erst entscheiden: Daten herausziehen oder Rechnungen verarbeiten?
Für einen kleinen Workflow reicht oft eine API, die eine PDF in strukturiertes JSON verwandelt. Mindee oder Veryfi passen in dieses Bild: Ein Entwickler sendet ein Dokument, erhält Felder zurück und baut die Regeln selbst. Das ist gut, wenn es um wenige klar definierte Belegtypen geht und jemand die Fehlerpfade verantwortet.
Sobald Rechnungen aus vielen Quellen kommen, wird OCR zum Prozessproblem. Rossum und ABBYY Vantage zielen stärker auf Review, Rollen und wiederkehrende Dokumentenabläufe. Das kann mehr Einrichtung bedeuten, verhindert aber, dass die Korrekturarbeit unsichtbar in E-Mail-Postfächern und Tabellen verschwindet.
Cloud-nahe Teams wählen oft Azure AI Document Intelligence, Google Document AI oder AWS Textract, weil Rechte, Logging und Speicher bereits in der vorhandenen Plattform liegen. Das ist kein Qualitätsurteil über die Erkennung. Es ist eine Betriebsentscheidung: Wer überwacht die Verarbeitung, wo liegen die Dokumente und wie gelangen Korrekturen zurück in den Ablauf?
Die vier Prüfungen, die eine Demo nicht zeigt
Ein realistischer Testkorpus enthält nicht nur saubere Standardrechnungen. Er braucht unterschiedliche Lieferanten, mehrseitige PDFs, schlechte Scans, Gutschriften, Fremdwährungen, Tabellenpositionen und mindestens ein Dokument mit zwei angehängten Belegen. Für jedes Dokument wird vorher festgelegt, welche Felder wirklich kritisch sind: Rechnungsnummer, Lieferant, Datum, Netto, Steuer, Brutto, Währung und Zahlungsziel.
Dann lohnt sich ein Blick auf vier Werte:
- Pflichtfelder korrekt: Nicht „wie viel Text wurde erkannt?“, sondern ob die Felder stimmen, die Buchung oder Freigabe beeinflussen.
- Unsicherheit sichtbar: Niedrige Confidence-Werte müssen an einem nachvollziehbaren Ort landen, nicht still als gültige Daten exportiert werden.
- Korrekturzeit: Eine gute Erkennung nützt wenig, wenn Mitarbeitende für jede Ausnahme zwischen drei Oberflächen wechseln.
- Export stimmt: JSON, CSV, Webhook oder ERP-Anbindung sind erst bestanden, wenn die Daten im Zielsystem plausibel ankommen.
Was automatisch laufen darf - und was nicht
Der sichere Einstieg ist schmal: Wiederkehrende Lieferanten, klarer Dokumenttyp, Beträge unter einer definierten Schwelle und ein Export, der noch keine Zahlung auslöst. Alles andere geht in eine Review-Queue. Das ist keine Niederlage der Automatisierung, sondern ihr Sicherheitsventil.
Ein praktisches Regelset kann etwa so aussehen: Wird Lieferant, Rechnungsnummer und Bruttobetrag mit hoher Sicherheit erkannt, prüft das System zusätzlich auf Dubletten und Pflichtfelder. Fehlt ein Feld, passt die Summe nicht oder erscheint ein neuer Lieferant, hält der Prozess an. Erst ein Mensch gibt den Datensatz frei. Mit den Korrekturen kann das Team später entscheiden, welche Fälle wirklich automatisierbar werden.
Das schützt auch vor einem typischen Denkfehler: OCR darf Daten vorbereiten, aber nicht eigenmächtig Buchungen, Zahlungen oder steuerlich relevante Entscheidungen auslösen. Für diese Grenze braucht es Verantwortliche, Rechte und ein Protokoll.
Datenschutz ist Teil der Architektur
Rechnungen enthalten Kontodaten, Ansprechpartner, Steuerinformationen und Geschäftsbeziehungen. Vor einem Produktivstart sollten Teams nicht nur den Preis prüfen, sondern Auftragsverarbeitung, Verarbeitungsregion, Subprozessoren, Aufbewahrung, Löschung und Request-Logs. Bei einem Cloud-Service ist außerdem wichtig, wer technisch auf Originaldokumente und extrahierte Daten zugreifen kann.
Klippa oder Nanonets können je nach Integrations- und Datenanforderung sinnvoll sein; die passende Wahl ergibt sich jedoch erst aus dem konkreten Prozess. Ein Pilot mit anonymisierten Testdaten ist gut für die Technik. Ein begrenzter Pilot mit echten, kontrollierten Rechnungen zeigt erst die betriebliche Wahrheit.
Eine Entscheidung nach zwei Wochen statt nach einer Demo
Für einen ersten Vergleich reichen 50 bis 100 typische Rechnungen. Nach zwei Wochen sollte ein Team beantworten können: Welche Pflichtfelder sind stabil? Welche Lieferanten erzeugen Ausnahmen? Wie viele Minuten kostet eine Korrektur? Welche Daten dürfen das Haus verlassen? Und ist der Export ins Zielsystem wirklich belastbar?
Wenn diese Antworten fehlen, fehlt nicht noch ein besseres OCR-Modell. Es fehlt die Prozessentscheidung. Wenn sie vorliegen, wird die Toolwahl plötzlich überschaubar: API-first für eigenen Code, Plattform für Review und Governance, Cloud-Service für den Anschluss an die bestehende Infrastruktur.
Die beste Rechnungs-OCR ist damit die, die im Alltag offen sagt: „Das weiß ich nicht sicher.“ Genau dort beginnt die Automatisierung, der die Buchhaltung vertrauen kann.
Quellen und weiterführende Dokumentation
- Azure AI Document Intelligence: Invoice model
- AWS Textract: AnalyzeExpense
- Google Document AI: processors
- Rossum Platform