Belegerkennung: Datensatz, Textebene oder Bild

Über Belegerkennung wird meist gesprochen, als wäre sie ein einziges Verfahren, das mal besser und mal schlechter funktioniert. Tatsächlich sind es drei verschiedene Wege, und welcher greift, entscheidet sich lange bevor eine Software beteiligt ist.

Weg eins: der strukturierte Datensatz

Bei einer E-Rechnung liegen die Daten als Felder vor. Rechnungsnummer, Datum, Steuersätze, Nettobeträge, Steuerbeträge, Positionen und die Angaben zu beiden Beteiligten stehen exakt fest.

Es wird nichts gelesen und nichts geschätzt. Was im Datensatz steht, ist der Wert. Bei einer XRechnung liegt er als reines XML vor, bei ZUGFeRD als XML in einer PDF-Datei.

Für die Verarbeitung ist das der beste denkbare Ausgangspunkt, und es ist der Grund, warum die E-Rechnungspflicht der Automatisierung mehr hilft als jede Verbesserung der Texterkennung. Der aufwendigste und fehleranfälligste Schritt entfällt vollständig.

Ein häufiger Fehler in der Praxis: Ein ZUGFeRD-PDF wird als Bild behandelt und durch die Texterkennung geschickt, obwohl das XML danebenliegt. Das Ergebnis ist schlechter als es sein müsste, und niemand merkt es, weil das Ergebnis meistens trotzdem stimmt. Bei der Auswahl eines Systems lohnt hier eine gezielte Nachfrage.

Weg zwei: die Textebene

Ein digital erzeugtes PDF, etwa aus einem Rechnungsprogramm, enthält seinen Text bereits. Er muss nicht erkannt, sondern nur ausgelesen werden.

Fehler entstehen hier nicht beim Lesen der Zeichen, sondern bei der Zuordnung. Welche der fünf Zahlen auf dem Blatt ist der Rechnungsbetrag, welche das Datum der Leistung und welche das der Rechnung, und gehört diese Nummer zum Kunden oder zum Auftrag?

Das ist eine Frage der Anordnung, und Rechnungslayouts sind beliebig. Verlässlich wird die Zuordnung über Schlüsselwörter, über die Position im Dokument und über Plausibilität: Der Bruttobetrag ist der größte Betrag, das Leistungsdatum liegt nicht nach dem Rechnungsdatum.

Weg drei: das Bild

Ein Foto, ein Scan oder ein ausgedrucktes und wieder eingescanntes PDF hat keine Textebene. Der Text muss aus Pixeln gewonnen werden, und erst hier entstehen echte Lesefehler.

Typisch sind:

• verwechselte Zeichen, etwa 1 und 7, 8 und 3, O und 0
• verlorene oder falsch gesetzte Trennzeichen, wodurch aus 1.234,56 leicht 123456 wird
• zusammengezogene Zeilen, sodass zwei Beträge zu einem verschmelzen
• vollständig unlesbare Bereiche bei verblasstem Thermopapier

Der letzte Punkt ist im Kanzleialltag der häufigste. Ein Kassenbon, der drei Monate im Handschuhfach lag, ist unter Umständen für niemanden mehr lesbar, auch nicht für einen Menschen.

Handschrift ist der Sonderfall. Ein handschriftlich ergänztes Trinkgeld auf einem Bewirtungsbeleg steht direkt neben einer gedruckten Zahl und verändert den Gesamtbetrag. Wird es übersehen, stimmt der gebuchte Betrag nicht mit der Zahlung überein, und die Differenz fällt erst beim Bankabgleich auf.

Warum die Zuordnung schwieriger ist als das Lesen

Ein verbreitetes Missverständnis: Die Schwierigkeit liege im Erkennen der Zeichen. Bei digital erzeugten Dokumenten liegt sie woanders, nämlich in der Frage, was eine erkannte Zahl bedeutet.

Auf einer durchschnittlichen Rechnung stehen zwischen zehn und dreißig Zahlen. Kundennummer, Rechnungsnummer, Auftragsnummer, Steuernummer, mehrere Datumsangaben, Einzelpreise, Mengen, Zwischensummen, Rabatte, Steuerbeträge, Endsumme, Bankverbindung, Zahlungsziel. Der Text ist vollständig lesbar, und trotzdem ist unklar, welche dieser Zahlen der Rechnungsbetrag ist.

Die Zuordnung gelingt über drei Wege, die sich ergänzen:

Schlüsselwörter in der Nähe. Steht neben einer Zahl das Wort Gesamtbetrag, Rechnungsbetrag oder Zahlbetrag, ist die Sache meist klar. Problematisch wird es bei Rechnungen ohne solche Beschriftung oder mit ungewöhnlichen Bezeichnungen.

Die Position im Dokument. Der Endbetrag steht typischerweise unten rechts, das Rechnungsdatum oben. Diese Heuristik trägt weit und scheitert bei ungewöhnlichen Layouts.

Plausibilität und Rechnung. Der Bruttobetrag ist der größte Betrag auf dem Dokument. Das Leistungsdatum liegt nicht nach dem Rechnungsdatum. Netto plus Steuer ergibt Brutto. Diese Prüfungen sind die zuverlässigsten, weil sie unabhängig vom Layout funktionieren.

Ein Verfahren, das nur den ersten Weg nutzt, arbeitet bei Standardrechnungen gut und bei allem anderen schlecht. Für die Bewertung heißt das: Nicht die Rechnung eines Großlieferanten vorlegen, sondern die eines kleinen Handwerksbetriebs mit selbstgebautem Layout.

Die Belegtypen nach Schwierigkeit sortiert

Nicht jeder Beleg ist gleich anspruchsvoll. Eine grobe Rangfolge, die sich in fast jedem Bestand bestätigt:

Die letzten drei Zeilen erklären, warum die Belegqualität beim Mandanten wichtiger ist als die Wahl der Software. Ein Verfahren kann aus einem unlesbaren Beleg nichts machen, und ein Mensch übrigens auch nicht.

Der Sonderfall Handschrift

Handschriftliche Ergänzungen sind der schwierigste Fall überhaupt, und sie kommen häufiger vor, als man denkt: Trinkgeld auf dem Bewirtungsbeleg, ein nachgetragener Betrag auf einer Quittung, eine Notiz zur Kostenstelle, die Unterschrift auf einem Eigenbeleg.

Kritisch ist dabei nicht die Handschrift an sich, sondern ihre Wirkung. Ein handschriftlich ergänztes Trinkgeld steht direkt neben oder unter einer gedruckten Zahl und verändert den Gesamtbetrag. Wird es übersehen, stimmt die Buchung nicht mit der Zahlung überein, und die Differenz taucht erst beim Abgleich mit dem Bankkonto auf, wo sie als unerklärte Abweichung erscheint.

Zwei Umgangsweisen sind praktikabel:

Aussteuern statt raten. Erkennt ein Verfahren handschriftliche Anteile im Bereich der Beträge, gehört der Beleg vorgelegt. Das ist ehrlicher als eine Zahl, die vielleicht stimmt.

Der Zahlungsabgleich als Netz. Weicht der gebuchte Betrag von der Zahlung ab, wird die Differenz sichtbar. Das fängt genau die Fälle, in denen etwas übersehen wurde, siehe Bankabgleich.

Die Prüfung, die Lesefehler abfängt

Der wirksamste Schutz ist keine bessere Erkennung, sondern eine Rechnung:

Netto + Steuerbetrag = Brutto
Netto × Steuersatz   = Steuerbetrag

Stimmen beide Gleichungen, sind die drei Zahlen mit hoher Wahrscheinlichkeit richtig gelesen. Stimmt eine nicht, ist mindestens eine falsch, und der Beleg gehört angesehen.

Das klingt banal und fängt den größten Teil aller Zahlenfehler ab, weil ein Lesefehler die Beziehung zwischen den drei Werten fast immer zerstört. Ein System, das diese Prüfung nicht macht, übernimmt falsche Beträge kommentarlos.

Ergänzend hilft der Abgleich mit der Zahlung: Ein Rechnungsbetrag, der von der Überweisung abweicht, ist entweder ein Lesefehler, ein Skontoabzug oder eine Teilzahlung. Alle drei Fälle gehören sichtbar gemacht statt stillschweigend gebucht.

Die Rechenprobe an einem Beispiel

Wie zuverlässig die Prüfung arbeitet, zeigt sich an einem konkreten Fall. Eine Rechnung lautet über 1.234,56 Euro netto, 234,57 Euro Umsatzsteuer und 1.469,13 Euro brutto. Beim Lesen wird aus der Ziffer 3 im Nettobetrag eine 8.

Beide Prüfungen schlagen fehl, und zwar mit derselben Differenz von 50 Euro. Damit ist nicht nur bekannt, dass ein Fehler vorliegt, sondern auch, in welchem Feld er steckt: Der Bruttobetrag stimmt mit der Zahlung überein, der Steuerbetrag passt zum ursprünglichen Nettobetrag, also ist das Nettofeld falsch gelesen. Ein System, das diese Herleitung mitliefert, spart dem Bearbeiter den Blick auf den Beleg.

Ebenso wichtig ist zu wissen, was die Rechenprobe nicht findet. Sie prüft die innere Stimmigkeit von drei Zahlen, nicht ihre Richtigkeit im Verhältnis zum Beleg. Drei Fehlerarten laufen deshalb ungehindert durch.

Der Periodenfehler. Rechnungsdatum und Leistungsdatum werden vertauscht oder das Jahr falsch gelesen. Alle Beträge stimmen, die Buchung liegt im falschen Monat, und die Voranmeldung ist betroffen.

Der falsche Beteiligte. Auf einer Rechnung stehen zwei Anschriften. Wird die des Empfängers als Aussteller gedeutet, ist der Beleg rechnerisch einwandfrei und dem falschen Lieferanten zugeordnet.

Die vollständig plausible Falschzahl. Werden Netto und Steuer gemeinsam aus einer Zwischensumme gelesen, etwa aus einer Positionszeile statt aus der Endsumme, ist die Rechenprobe erfüllt und der Betrag trotzdem falsch. Dagegen hilft nur der Abgleich mit der Zahlung.

Ein zweiter Punkt betrifft Belege mit mehreren Steuersätzen. Eine Hotelrechnung über 205,00 Euro mit 180,00 Euro Übernachtung zu 7 Prozent und 25,00 Euro Verpflegung zu 19 Prozent enthält 15,77 Euro Umsatzsteuer. Ein Verfahren, das den Gesamtbetrag pauschal mit dem Regelsteuersatz herausrechnet, kommt auf 32,73 Euro und liegt um 16,96 Euro daneben. Die Rechenprobe muss deshalb je Steuersatz geführt werden und nicht über die Summe. Ein System, das nur ein Steuerfeld je Beleg kennt, kann diesen sehr häufigen Belegtyp grundsätzlich nicht korrekt abbilden.

Belege, die aus der Form fallen

Neben der Frage, wie gut gelesen wird, entscheidet die Vorverarbeitung über das Ergebnis. Die folgenden Fälle treten in jedem Bestand auf und haben mit Zeichenerkennung nichts zu tun.

Mehrere Belege in einer Datei. Ein Sammelscan enthält acht Kassenbons hintereinander. Ohne Trennung entsteht ein einziger Vorgang mit acht Beträgen, und keiner davon ist der Rechnungsbetrag. Die Trennung gelingt über Seitenwechsel, Formatwechsel oder erkannte Belegköpfe und muss vor allem anderen stattfinden.

Ein Beleg über mehrere Seiten. Rechnung, Lieferschein und Allgemeine Geschäftsbedingungen in einer Datei. Der Endbetrag steht auf Seite zwei, weitere Beträge auf den anderen Seiten. Ein Verfahren, das nur die erste Seite auswertet, findet den falschen Betrag oder gar keinen.

Der doppelt eingereichte Beleg. Dieselbe Rechnung kommt per E-Mail und zusätzlich als Foto vom Mandanten. Ohne Dublettenerkennung über Aussteller, Rechnungsnummer, Datum und Betrag wird sie zweimal gebucht. Das ist der Fehler, der am ehesten zu einer doppelten Zahlung führt und der sich am leichtesten verhindern lässt.

Gedrehte und kopfstehende Seiten. Ein häufiger und banaler Fall, der ohne automatische Ausrichtung die Erkennung vollständig scheitern lässt. Bei Fotos kommt die perspektivische Verzerrung hinzu.

Das Dokument, das gar kein Beleg ist. Angebote, Auftragsbestätigungen, Lieferscheine, Mahnungen und Zahlungserinnerungen sehen aus wie Rechnungen und dürfen keine Buchung auslösen. Besonders heikel ist die Mahnung, weil sie den Rechnungsbetrag und die Rechnungsnummer trägt und deshalb bei einer reinen Feldauswertung wie das Original wirkt. Die Belegart gehört deshalb vor der Feldauswertung bestimmt.

Gutschriften und Stornos. Sie tragen dieselben Felder mit umgekehrter Wirkung. Wird das Vorzeichen nicht erkannt, addiert sich ein Aufwand, der abgezogen gehört, und der Fehler ist doppelt so groß wie der Betrag.

Diese sechs Punkte erklären, warum zwei Systeme mit vergleichbarer Zeichenerkennung im Alltag sehr unterschiedliche Ergebnisse liefern. Der Unterschied entsteht vor und nach dem Lesen, nicht beim Lesen selbst. Wie sich diese Schritte in den Gesamtablauf einfügen, ist unter digitale Belegstrecke beschrieben.

Wo der Hebel wirklich liegt

Die Diskussion dreht sich meist um die Qualität der Texterkennung. Der größere Hebel liegt davor, nämlich beim Anteil der Belege, die überhaupt als Bild ankommen.

Drei Maßnahmen wirken stärker als jede Softwareauswahl:

Rechnungen als Datei weiterleiten, nicht ausdrucken. Ein per E-Mail empfangenes PDF hat eine Textebene. Der Ausdruck davon, abfotografiert, hat keine mehr. Diese eine Gewohnheit verschiebt einen erheblichen Teil des Aufkommens von Weg drei auf Weg zwei.

Belege beim Entstehen erfassen. Ein Bon, der beim Kauf fotografiert wird, ist lesbar. Derselbe Bon nach drei Monaten möglicherweise nicht. Nebenbei erfüllt das die Anforderung an die zeitgerechte Sicherung.

Lieferanten auf E-Rechnung ansprechen. Bei wiederkehrenden Lieferanten mit hohem Belegaufkommen lohnt die Nachfrage, ob sie strukturiert liefern können. Mit der Ausstellungspflicht ab 2027 für größere Unternehmen erledigt sich ein Teil davon ohnehin.

Konfidenzwerte und Schwellen

Jedes Erkennungsverfahren liefert neben dem Wert eine Einschätzung, wie sicher es ist. Wie damit umgegangen wird, entscheidet über den praktischen Nutzen mehr als die reine Erkennungsleistung.

Ein Wert je Beleg genügt nicht. Eine Angabe wie 92 Prozent für das gesamte Dokument ist nicht handhabbar, weil sie nicht sagt, welches Feld unsicher ist. Brauchbar wird die Angabe erst je Feld: Der Lieferant ist sicher, das Rechnungsdatum ist sicher, der Steuerbetrag ist es nicht. Dann kann der Bearbeiter ein Feld prüfen statt eines Belegs.

Die Angabe muss kalibriert sein. Wenn ein System für hundert Felder eine Sicherheit von 90 Prozent angibt, sollten etwa zehn davon falsch sein. Sind es dreißig, ist die Angabe wertlos und die daraus abgeleitete Schwelle ebenfalls. Das lässt sich prüfen, indem man über einen Monat die Korrekturen den angegebenen Sicherheiten gegenüberstellt.

Die Schwelle gehört dem Anwender. Ab welchem Wert ein Beleg vorgelegt wird, ist eine Abwägung zwischen Prüfaufwand und Fehlerrisiko, und sie fällt je Mandat unterschiedlich aus. Bei einem Mandat mit hohem Belegaufkommen und kleinen Beträgen ist eine niedrigere Schwelle vertretbar als bei einem mit wenigen großen Rechnungen.

Die Schwelle sollte betragsabhängig sein. Ein unsicher gelesener Betrag über 12 Euro und einer über 12.000 Euro verdienen nicht dieselbe Behandlung. Eine feste Schwelle über alle Belege hinweg erzeugt entweder zu viel Prüfarbeit im Kleinen oder zu wenig Kontrolle im Großen.

Wo die grundsätzlichen Grenzen dieser Verfahren liegen, ist unter Grenzen der KI-Buchhaltung beschrieben.

Kennzahlen für die Erkennungsqualität

Die in Verkaufsgesprächen genannte Trefferquote ist selten definiert und deshalb selten vergleichbar. Vier Größen sind es.

Die vierte Zeile ist die entscheidende und die, die am seltensten erhoben wird. Ein System lässt sich beliebig auf eine hohe Durchlaufquote einstellen, indem es die Schwelle senkt. Die Quote steigt, die Arbeit sinkt, und die Fehler wandern in die Buchführung. Ohne die vierte Kennzahl ist die zweite bedeutungslos.

Die Feldgenauigkeit gehört getrennt nach Feldern ausgewiesen, weil die Felder unterschiedlich schwer und unterschiedlich wichtig sind. Der Bruttobetrag wird fast immer erkannt, die Rechnungsnummer häufig, der Steuersatz je Position deutlich seltener. Ein Durchschnittswert über alle Felder verdeckt genau die Schwäche, die im Alltag stört. Zur Messung des Gesamtverfahrens siehe Automatisierungsquote messen.

Für einen belastbaren Vergleich genügt ein Testpaket von etwa fünfzig Belegen aus dem eigenen Bestand, in der Verteilung, in der sie tatsächlich anfallen. Wer nur die schwierigen Fälle hineinlegt, erhält ein zu schlechtes Bild, wer nur die einfachen nimmt, ein zu gutes. Die tatsächliche Mischung ist die einzige, die etwas über den späteren Alltag aussagt.

Was das für die Bewertung eines Systems heißt

Ein Anbietertest mit einer sauberen PDF-Rechnung eines bekannten Großlieferanten sagt wenig aus, weil dieser Fall in jedem System funktioniert.

Aussagekräftig ist ein Testpaket aus dem eigenen Bestand mit den Fällen, an denen es tatsächlich hakt: ein verblasster Thermobon, ein schräg fotografierter Beleg, eine Hotelrechnung mit zwei Steuersätzen, ein Bewirtungsbeleg mit handschriftlichem Trinkgeld und eine Kreditkartenabrechnung. Was ein System mit diesen fünf Belegen macht, entspricht dem, was es im Alltag leisten wird.

Abgrenzung: Erkennung, Kontierung, Prüfung

Drei Schritte werden im Gespräch häufig als eine Leistung behandelt, obwohl sie unterschiedliche Fragen beantworten und unterschiedlich zuverlässig sind.

Die Erkennung beantwortet, was auf dem Beleg steht. Sie ist eine Frage der Datenqualität und im Grundsatz objektiv überprüfbar: Entweder der erkannte Betrag entspricht dem gedruckten oder nicht. Bei strukturierten Daten entfällt sie vollständig, siehe E-Rechnung in der KI-Buchhaltung.

Die Kontierung beantwortet, wohin der Vorgang gehört. Sie setzt auf den erkannten Werten auf und ist eine fachliche Entscheidung, die auch bei perfekt gelesenen Daten falsch ausfallen kann. Der Ablauf ist unter wie KI Belege kontiert beschrieben.

Die Prüfung beantwortet, ob der Beleg trägt. Ob die Pflichtangaben vollständig sind, ob der Vorsteuerabzug in Betracht kommt, ob der Aussteuerung ein Grund entgegensteht. Diese Frage ist von den ersten beiden unabhängig: Ein perfekt gelesener und korrekt kontierter Beleg kann formell unzureichend sein.

Die Unterscheidung ist mehr als eine Begriffsfrage. Sie bestimmt, wo eine Fehlerquote gemessen und wo eine Verbesserung angesetzt wird. Wer über eine schlechte Erkennung klagt, meint häufig die Kontierung, und wer die Kontierung verbessern will, scheitert manchmal daran, dass die Erkennung die falschen Felder liefert. Ohne die Trennung wird an der falschen Stelle nachgebessert.