In fast jedem Erstgespräch über Dokumenten-Automatisierung liegt derselbe Stapel auf dem Tisch: Eingangsrechnungen. Und fast genauso oft gibt es schon einen gescheiterten Anlauf mit „OCR-Software“ — gekauft, eingerichtet, nach einem halben Jahr still beerdigt. Woran das lag und was heute tatsächlich funktioniert.
Der Prozess selbst ist unspektakulär und genau deshalb teuer: Rechnung kommt per Mail oder Post, jemand sichtet, tippt Betrag, Datum, Lieferant und Positionen in die Buchhaltung, ordnet zu, legt ab. Drei bis acht Minuten pro Rechnung, je nach Prozess — bei ein paar hundert Rechnungen im Monat sind das ganze Arbeitstage, jeden Monat wieder. Dass man das automatisieren will, ist offensichtlich. Die Frage ist nur, warum so viele Anläufe scheitern. Die Antwort in einem Satz vorweg: weil die meisten Projekte an der falschen Stelle investieren — in die Erkennung, die längst funktioniert, statt in Prüfung und Übergabe, die den Unterschied machen. Der Rest dieses Textes ist die lange Fassung dieses Satzes.
Warum klassisches Template-OCR an der Realität scheitert
Die OCR-Generation, mit der die meisten gescheiterten Projekte gebaut wurden, arbeitet mit Vorlagen: Pro Lieferanten-Layout wird einmal definiert, wo der Betrag steht, wo das Datum, wo die Rechnungsnummer. Das funktioniert erstaunlich gut — für die zwanzig Lieferanten, deren Rechnungen immer gleich aussehen. Es bricht an der Realität eines normalen Betriebs: hunderte Lieferanten, jeder mit eigenem Layout, dazu laufend neue. Jeder neue Lieferant heißt eine neue Vorlage, jede Layout-Änderung ein stiller Fehler, der erst in der Buchhaltung auffällt.
So wird die Vorlagen-Pflege zum eigenen Halbtagsjob — und irgendwann rechnet jemand nach, dass das Abtippen billiger war. Das ist der Punkt, an dem die Software still beerdigt wird. Nicht weil OCR nicht funktioniert, sondern weil starre Vorlagen und Layout-Vielfalt nicht zusammenpassen.
Wie moderne KI-Auslese arbeitet
Moderne Modelle lesen ein Dokument eher so, wie ein Mensch es tut: Sie verstehen, was eine Rechnungsnummer ist — unabhängig davon, wo sie steht. Fremde Layouts, gescannte Briefe, schiefe Handy-Fotos, englische Rechnungen zwischen deutschen: alles derselbe Weg, ohne dass jemand eine Vorlage pflegt. Wir betreiben dieses Muster seit Jahren produktiv — unter anderem in TaxCastle, wo Steuerkanzleien Belege fotografieren und DATEV-konforme Buchungssätze zurückbekommen.
Die unbequeme Wahrheit für alle, die gerade Anbieter vergleichen: Die Erkennung ist damit weitgehend gelöst und wird zum Standard. Genau deshalb ist sie nicht mehr die Stelle, an der Projekte scheitern. Gescheitert wird heute eine Etage höher.
Der Teil, der wirklich zählt: Validierung und Übergabe
Ein erkannter Betrag ist noch kein gebuchter Beleg. Zwischen Erkennung und Buchhaltung gehört eine Validierungsschicht, und die macht den Unterschied zwischen Spielzeug und Werkzeug:
- Rechnerische Prüfung: Netto plus Steuer gleich Brutto? Positionssummen gleich Rechnungssumme? Klingt banal, fängt aber sowohl Erkennungsfehler als auch fehlerhafte Rechnungen.
- Stammdaten-Abgleich: Ist der Lieferant bekannt? Passt die USt-IdNr.? Und der wichtigste Fall: Weicht die IBAN von der hinterlegten ab, ist das ein Alarmsignal — nicht nur ein Erkennungsproblem, sondern ein klassisches Betrugsmuster.
- Dublettenprüfung: Dieselbe Rechnung kommt per Mail und zwei Wochen später per Post. Ohne Prüfung wird sie zweimal gebucht — im schlimmsten Fall zweimal bezahlt.
- Konfidenz statt Bauchgefühl: Unsichere Felder werden markiert und landen in einer Prüf-Schleife beim Menschen — Original links, erkannte Felder rechts. Sichere Fälle laufen durch.
Und dann die Übergabe: Der geprüfte Datensatz muss strukturiert in das System, mit dem der Betrieb tatsächlich arbeitet — ERP, DATEV, Lexware und Co. Ohne diese Anbindung entsteht die klassische Insel: Die Erkennung funktioniert, aber jemand kopiert die Ergebnisse per Hand weiter, und die Ersparnis löst sich in Klicks auf. Die Anbindung ist unglamourös, kostet in Projekten oft mehr Zeit als die KI — und entscheidet trotzdem über alles.
Was „Übergabe“ konkret heißt, hängt am Zielsystem. Richtung DATEV heißt es: Buchungsvorschlag samt verknüpftem Belegbild, damit die Kanzlei prüfen statt erfassen kann. Richtung ERP oder Lexware und Co: der Beleg als vorerfasster Datensatz mit Kontierungsvorschlag, dem Original angeheftet. In allen Fällen gilt dieselbe Regel: Das führende System bleibt führend. Die Automatisierung liefert zu — sie baut keine zweite Buchhaltung daneben, in der nach einem Jahr niemand mehr weiß, welcher Stand stimmt.
Ab wann sich das rechnet
Die Rechnung ist dieselbe wie bei jeder Automatisierung: Belegvolumen mal Minuten pro Beleg, dagegen Bau und Betrieb. Grob sortiert: Unter etwa hundert Rechnungen im Monat reicht meist, was die eigene Buchhaltungssoftware inzwischen mitbringt — dafür würden wir keine eigene Strecke bauen. Ab einigen hundert Rechnungen im Monat beginnt sich eine eigene Strecke mit sauberer Validierung und Anbindung zu rechnen, mit Amortisation in Monaten statt Jahren. Und wer vierstellig pro Monat verarbeitet, verliert ohne Automatisierung nicht nur Zeit, sondern auch Qualität — bei dem Volumen tippt niemand mehr konzentriert.
Ein Rechenbeispiel mit runden Zahlen, zum Selbst-Einsetzen: 500 Rechnungen im Monat, konservativ fünf Minuten pro Stück, macht gut vierzig Stunden — eine halbe Stelle, nur für Sichten, Abtippen und Zuordnen. Übernimmt die Strecke davon realistisch drei Viertel, bleiben rund zehn Stunden Prüf-Arbeit übrig. Was die gesparten dreißig Stunden in Euro heißen, kann jeder mit den eigenen Personalkosten ausrechnen — und gegen ein Projektbudget halten, das einmal anfällt, während der Stapel jeden Monat wiederkommt.
Eine ehrliche Warnung gehört in jede dieser Rechnungen: Kalkuliert nie mit hundert Prozent Automatik. Ein realistischer Anteil läuft durch, der Rest — schlechte Scans, exotische Fälle, Handschriftliches — landet in der Prüf-Schleife beim Menschen. Diese Restquote plant man ein und misst sie, statt sie wegzuwünschen. Automatisierung, die auf dem Papier bei 100 Prozent liegt, liegt in der Praxis bei null — weil ihr niemand mehr traut.
Und die E-Rechnung? Der Kontext, der gern fehlt
Seit Anfang 2025 müssen Unternehmen in Deutschland im B2B-Geschäft E-Rechnungen empfangen können — strukturierte Formate nach EN 16931, in der Praxis XRechnung und ZUGFeRD. Die Pflicht, selbst so zu fakturieren, folgt gestaffelt in den kommenden Jahren. Auf dem Papier macht das die Erkennung überflüssig: Eine XRechnung ist ein Datensatz, kein Bild — da gibt es nichts zu erkennen, nur einzulesen.
In der Praxis verschwindet das Thema damit trotzdem nicht: Auslandsrechnungen, Kleinbetragsrechnungen, Quittungen und der jahrelange Bestand an PDF- und Papierrechnungen bleiben. Realistisch ist eine hybride Strecke — strukturierte Formate werden direkt eingelesen, der Rest läuft über die KI-Auslese, und beides mündet in dieselbe Validierung und Übergabe. Das ist auch die gute Nachricht für alle, die jetzt bauen: Die Validierungs- und Anbindungsschicht baut man einmal; das Einlese-Ende davor ist austauschbar und wird mit jeder E-Rechnung billiger.
Der Einstieg, ohne Big Bang
Der Anfang, den wir empfehlen, ist unspektakulär: einen Monat echter Eingangsrechnungen nehmen — nicht die zehn schönsten, sondern den ehrlichen Querschnitt samt Problemfällen — und daran messen, was die Auslese schafft. Danach liegen Zahlen auf dem Tisch: Erkennungsquote, Restquote, Minuten pro Fall. Mit denen lässt sich entscheiden, nicht mit Prospekt-Versprechen. Und die Buchhaltung, die das Werkzeug später täglich benutzen soll, sitzt von der ersten Stunde an mit am Tisch — sie erkennt die Problemfälle schneller als jedes Datenblatt und entscheidet am Ende über die Akzeptanz.
Genau diese Strecke — Auslese, Prüf-Oberfläche, Übergabe an das führende System — bauen wir als festes Paket mit Prototyp auf euren echten Belegen zuerst; die Details stehen auf der Seite zur Dokumenten-Automatisierung. Und wie dasselbe Muster jenseits von Rechnungen aussieht, zeigt unsere Werkstatt-Notiz zum Automatisieren von Lohnzetteln in Steuerkanzleien.
