OCR oder KI in der Rechnungsprüfung? Warum Texterkennung an ihre Grenzen stößt

Klassische OCR liest Zeichen, versteht aber nicht, was sie liest. Wo template-basierte Texterkennung strukturell scheitert – an §13b-Bauleistungen, Anzahlungsverrechnung, mehreren Steuersätzen – und warum ein KI-/LLM-Ansatz diese Fälle meistert.

„KI-Rechnungsprüfung" und „OCR-Rechnungsprüfung" klingen nach demselben, sind aber zwei grundverschiedene Dinge. Der Unterschied entscheidet darüber, ob eine Software eine Rechnung nur lesen oder auch verstehen kann. Und genau daran hängt, ob teure Fehler vor der Zahlung auffallen oder nicht.

OCR liest Zeichen, mehr nicht

OCR (optical character recognition, optische Zeichenerkennung) macht aus einem gescannten Bild wieder Text: Aus Bildpunkten werden Buchstaben und Ziffern. Das ist eine reife, nützliche Technik, aber sie endet beim Text. OCR weiß nicht, *was* der Text bedeutet.

Damit aus dem erkannten Text strukturierte Felder werden (Lieferant, Rechnungsnummer, Nettobetrag), braucht klassische OCR-Software Vorlagen (Templates): „Der Nettobetrag steht bei diesem Lieferanten unten rechts." Für jeden neuen Lieferanten mit anderem Layout muss eine solche Vorlage gepflegt werden. Bei hunderten Lieferanten wird das zur Dauerbaustelle, und ein umgestaltetes Rechnungsformular bricht die Erkennung stillschweigend.

KI versteht die Bedeutung

Ein KI-Ansatz auf Basis eines Sprachmodells (LLM) geht anders vor: Er erfasst den Beleg semantisch. Er erkennt den Nettobetrag, *weil er versteht, was ein Nettobetrag ist*, nicht, weil er an einer bestimmten Stelle steht. Deshalb funktioniert er ohne Template-Pflege und layoutunabhängig, auch bei einem Lieferanten, dessen Rechnung die Software noch nie gesehen hat, und auch in fremder Sprache.

Der entscheidende Sprung ist aber nicht die Extraktion allein, sondern was danach möglich wird: fachliche Prüfung. Wer die Bedeutung der Werte kennt, kann Zusammenhänge bewerten, die reiner Text nicht hergibt.

Wo template-OCR strukturell scheitert

Drei Fälle, an denen der Unterschied nicht kosmetisch, sondern geldwert ist:

1. Die §13b-Reverse-Charge-Falle bei Bauleistungen

Erbringt ein Subunternehmer eine Bauleistung an einen bauleistenden Auftraggeber, schuldet nach § 13b UStG der Empfänger die Umsatzsteuer; der Rechnungssteller muss netto ohne USt fakturieren. Weist er trotzdem USt aus, ist sie nach § 14c unrichtig und nicht als Vorsteuer abziehbar. Wer die Rechnung brutto zahlt, zahlt die Steuer doppelt: einmal an den Subunternehmer (unwiederbringlich) und einmal per § 13b ans Finanzamt.

OCR liest hier brav „Rechnung", eine USt-Zeile und einen Bruttobetrag, meldet aber nichts. Sie *kann* nichts melden, weil sie nicht weiß, dass es sich um eine Bauleistung handelt und was daraus folgt. Ein KI-Ansatz mit Fachwissen erkennt die Konstellation und warnt, bevor gezahlt wird.

2. Anzahlungs- und Abschlagsverrechnung

Im Anlagenbau und am Bau wird über Anzahlungen und Abschläge fakturiert. Eine Schluss- oder weitere Abschlagsrechnung muss die bereits gezahlten Beträge verrechnen, sonst wird doppelt bezahlt. Das ist keine Frage des Ablesens, sondern des Rechnens über mehrere Belege hinweg: Welche Anzahlung gehört zu diesem Vorgang, und ist sie abgezogen? Reine Texterkennung sieht nur Zahlen auf einem Blatt; sie hat kein Konzept von „bereits verrechnet".

3. Mehrere Steuersätze auf einem Beleg

Eine Hotelrechnung mischt 7 % (Übernachtung) und 19 % (Frühstück, Parken); eine Handelsrechnung mischt Waren mit unterschiedlichen Sätzen. Die Pflichtangabe nach § 14 UStG verlangt den Steuerbetrag je Satz. Template-OCR, die auf *ein* Feld „Steuersatz" trainiert ist, kippt hier: sie erwartet einen Wert, findet mehrere und ordnet falsch zu. Verständnis der Steueraufschlüsselung löst das sauber.

Ist OCR damit schlecht? Nein, aber begrenzt

Fairerweise: Für große Mengen immer gleicher, formularartiger Belege (etwa standardisierte EDI-nahe Dokumente eines einzigen Absenders) ist OCR schnell, günstig und völlig ausreichend. Die Grenze liegt nicht in der Menge, sondern in der Vielfalt und der fachlichen Tiefe: sobald Layouts variieren und Rechnungen rechtlich bewertet werden müssen, reicht Lesen nicht mehr aus.

Viele „KI-Rechnungsprüfung"-Werkzeuge sind im Kern übrigens weiterhin OCR mit etwas Mustererkennung obendrauf. Der aussagekräftige Test ist einfach: Erkennt das System eine §13b-Bauleistung ohne Reverse-Charge-Hinweis als Risiko? Verrechnet es Anzahlungen? Kommt es mit zwei Steuersätzen klar? Wer diese Fragen mit Ja beantwortet, versteht Rechnungen; wer sie mit „dafür bräuchte es ein Template" beantwortet, liest sie nur.

Der Ansatz von BelegrAIdar

BelegrAIdar extrahiert Belege mit einer KI (LLM), auf Wunsch als lokales Modell (in Ihrer eigenen oder einer souveränen Cloud), sodass Belegdaten Ihre Umgebung nicht verlassen und nicht an eine Cloud-OCR gehen. Auf die Extraktion setzt eine fachliche Prüfschicht auf, die genau die oben beschriebenen Fälle kennt: § 13b, § 48 Bauabzugsteuer, Anzahlungsverrechnung, mehrere Steuersätze, Dubletten und geänderte Bankverbindungen. So wird aus „gelesen" ein belastbares „geprüft", und teure Fehler fallen vor der Zahlung auf, nicht danach.