Rechnungen kommen als PDF per E-Mail, Belege werden eingescannt und Zahlungen erscheinen auf dem Kontoauszug. Für die Buchhaltung müssen diese Informationen zusammengeführt und den richtigen Buchungen zugeordnet werden. Was einfach klingt, verursacht im Alltag dennoch viele manuelle Arbeitsschritte.
Genau hier setzt unser Proof of Concept an: Wir haben eine Anwendung entwickelt, die Dokumente automatisch erfasst, Rechnungsdaten ausliest und passende Rechnungen den Kontobewegungen zuordnet. Die KI läuft dabei lokal über Ollama. Sensible Unternehmensdaten müssen für die Analyse also nicht an einen externen Cloud-KI-Dienst übertragen werden.
Das Ergebnis ist kein Versprechen einer vollständig autonomen Buchhaltung. Es ist ein praxisnaher Versuch, einen klar abgegrenzten, wiederkehrenden Prozess sinnvoll zu automatisieren – und dabei die Kontrolle über Daten und Entscheidungen zu behalten.
Der Ausgangspunkt: Dokumente und Zahlungen zusammenbringen
In vielen Unternehmen liegen die relevanten Informationen an unterschiedlichen Stellen. Eingangsrechnungen, Ausgangsrechnungen und gescannte Belege befinden sich in einem Dokumentenordner. Die tatsächlich erfolgten Zahlungen sind auf einem Kontoauszug zu sehen. Die Zuordnung erfolgt häufig manuell: Betrag, Datum, Lieferant oder Rechnungsnummer werden verglichen, anschließend wird die passende Rechnung zum Kontoauszug abgelegt.
Dieser Ablauf ist weder besonders komplex noch besonders kreativ. Er ist aber fehleranfällig und bindet Zeit. Außerdem muss die zuständige Person zwischen Dateien, PDF-Ansichten und Buchhaltungsdaten wechseln. Unser Ziel war deshalb, die wiederkehrenden Schritte in einem durchgängigen Prozess abzubilden.
Vom PDF zur strukturierten Information
Am Anfang steht die Dokumentenerfassung. Die Anwendung nimmt Eingangsrechnungen, Ausgangsrechnungen und Belege entgegen, erfasst sie und legt sie für die weitere Verarbeitung ab. Gleichzeitig werden die Dokumente indexiert, damit sie später gezielt gefunden und verarbeitet werden können.
Im nächsten Schritt wird der Inhalt der PDFs ausgelesen. Bei digital erzeugten Rechnungen ist der Text häufig direkt im PDF enthalten. Bei eingescannten Dokumenten fehlt diese Textebene. In diesem Fall kann eine OCR-Verarbeitung eingesetzt werden. OCR steht für optische Zeichenerkennung und wandelt den Text aus einem Dokumentbild in maschinenlesbaren Text um. Werkzeuge wie OCRmyPDF können dafür eine durchsuchbare Textebene in ein gescanntes PDF einfügen.
Damit entsteht zunächst eine einheitliche Grundlage: Unabhängig davon, ob ein Dokument aus einer E-Mail stammt oder eingescannt wurde, steht sein Inhalt anschließend als Text für die weitere Verarbeitung zur Verfügung.
Was das lokale LLM aus Rechnungen extrahiert
Die Textauslese allein beantwortet noch nicht die entscheidende Frage: Welche Information steht an welcher Stelle und welche Bedeutung hat sie? Dafür setzen wir ein lokal betriebenes Large Language Model ein.
Über Ollama kann die Anwendung ein ausgewähltes Modell lokal ansprechen. Das Modell analysiert den Rechnungstext und überführt ihn in eine vorgegebene strukturierte Form. Im Proof of Concept gehören dazu unter anderem:
- Rechnungsnummer
- Lieferant oder Rechnungsteller
- Rechnungsdatum
- Fälligkeitsdatum
- IBAN
- Nettobetrag
- Umsatzsteuer
- Bruttobetrag
Die strukturierte Ausgabe wird anschließend in einer Datenbank gespeichert. Dadurch bleiben die Informationen nicht nur als Freitext verfügbar. Sie können durchsucht, geprüft, mit anderen Daten verglichen und in weiteren Verarbeitungsschritten verwendet werden.
Wichtig ist dabei die Aufgabenteilung: Das LLM interpretiert den Inhalt eines Dokuments. Es entscheidet nicht allein, ob eine Buchung korrekt ist. Plausibilitätsprüfungen, Datenbanklogik und der anschließende Abgleich mit dem Kontoauszug bleiben Bestandteile der klassischen Anwendung.
Kontoauszüge als Liste von Transaktionen
Auch der Kontoauszug wird verarbeitet. Die Anwendung liest die enthaltenen Buchungen aus und zerlegt den Auszug in einzelne Transaktionen. Für jede Transaktion stehen damit relevante Vergleichsdaten zur Verfügung, beispielsweise Betrag, Buchungsdatum, Verwendungszweck und – sofern vorhanden – Angaben zum Zahlungspartner oder eine Rechnungsnummer.
Die einzelnen Transaktionen bilden die zweite Seite des späteren Matchings. Auf der einen Seite stehen die aus Rechnungen extrahierten Daten, auf der anderen Seite die tatsächlichen Kontobewegungen.
Matching mit Regeln und Score statt blindem Vertrauen
Die Zuordnung übernimmt ein selbst entwickelter Matcher. Er vergleicht Rechnungen mit den Transaktionen und berücksichtigt dabei mehrere Merkmale. Dazu zählen insbesondere der Betrag, das Datum, der Lieferant und die Rechnungsnummer.
Ein exakter Betrag kann beispielsweise ein starkes Indiz sein. Stimmen zusätzlich Rechnungsnummer oder Lieferant überein, steigt die Sicherheit der Zuordnung weiter. Abweichungen beim Buchungsdatum können dagegen vorkommen, etwa wenn eine Rechnung einige Tage vor der tatsächlichen Zahlung beglichen wurde.
Aus diesen Merkmalen bildet der Matcher einen Matching-Score. Dieser Score ist kein künstliches Gütesiegel, sondern eine nachvollziehbare Entscheidungshilfe: Je mehr relevante Merkmale zusammenpassen, desto höher fällt die Bewertung aus.
Übernommen werden nur Zuordnungen, die ausreichend sicher sind. Fälle mit geringer Sicherheit bleiben für eine manuelle Prüfung sichtbar. Dadurch ist die Anwendung nicht darauf angewiesen, für jede Transaktion eine automatische Entscheidung zu erzwingen. Gerade bei Finanzdaten ist es sinnvoller, Unsicherheit kenntlich zu machen, als eine scheinbar präzise, aber falsche Zuordnung zu erzeugen.
Das Ergebnis: Ein zusammengeführtes PDF
Nach dem Matching erzeugt die Anwendung ein neues PDF. Die gefundenen Rechnungen werden direkt hinter der jeweils zugehörigen Seite des Kontoauszugs eingefügt. Die Reihenfolge der Rechnungen entspricht dabei der Reihenfolge der Buchungen auf dem Kontoauszug.
So entsteht ein zusammenhängendes Dokument, das sich leichter prüfen und weitergeben lässt: Zuerst ist die Kontobewegung sichtbar, anschließend folgt der dazugehörige Beleg. Nicht automatisch zugeordnete Dokumente können separat betrachtet und manuell bearbeitet werden.
Dieser Schritt zeigt auch, warum eine solche Lösung mehr ist als ein Chatbot mit Rechnungsfunktion. Das LLM ist nur ein Baustein in einer Prozesskette aus Dateiverarbeitung, OCR, Datenbank, Matching-Logik und PDF-Erzeugung.
Eine Weboberfläche für den praktischen Einsatz
Damit der Proof of Concept nicht nur aus einzelnen Skripten besteht, haben wir eine Weboberfläche mit NiceGUI entwickelt. Darüber lassen sich Dokumente scannen, vorhandene Rechnungen anzeigen und die extrahierten Rechnungsdaten prüfen.
Außerdem können Nutzerinnen und Nutzer ein Ollama-Modell auswählen, einen Matching-Prozess starten und die erzeugten Ergebnisse verwalten. Die Oberfläche verbindet damit die technischen Verarbeitungsschritte mit einem nachvollziehbaren Arbeitsablauf.
NiceGUI eignet sich dafür, weil sich browserbasierte Benutzeroberflächen mit Python entwickeln lassen. Die Anwendung kann dadurch die bestehende Verarbeitungslogik direkt ansprechen, ohne dass für jeden Arbeitsschritt eine separate Bedienoberfläche entstehen muss.
Digitale Souveränität als praktischer Projektfaktor
Ein zentraler Grund für den lokalen Ansatz war der Umgang mit sensiblen Daten. Rechnungen und Kontoauszüge enthalten Informationen über Geschäftspartner, Zahlungsströme und interne Abläufe. Bei einer Cloud-Lösung müssen Unternehmen genau prüfen, wohin diese Daten übertragen werden, welche Vereinbarungen gelten und wie die Verarbeitung kontrolliert werden kann.
In unserem Proof of Concept erfolgt die KI-Verarbeitung lokal mit Ollama. Die Dokumente werden für die Analyse nicht grundsätzlich an einen externen KI-Dienst gesendet. Das vereinfacht die Kontrolle über den Datenfluss und unterstützt Szenarien, in denen Unternehmensdaten die eigene Infrastruktur nicht verlassen sollen.
Lokaler Betrieb bedeutet allerdings nicht automatisch, dass alle Fragen zu Datenschutz, Zugriffsschutz, Protokollierung oder Betriebssicherheit gelöst sind. Auch eine lokale Anwendung braucht klare Berechtigungen, sichere Speicherung, Backups und einen definierten Umgang mit Fehlern. Der Vorteil liegt darin, dass Unternehmen diese Rahmenbedingungen innerhalb der eigenen Umgebung gestalten und überprüfen können.
Was wir aus dem Proof of Concept mitnehmen
Das Projekt zeigt vor allem, dass der praktische Nutzen lokaler Large Language Models nicht von einer spektakulären Einzelanwendung abhängt. Entscheidend ist das Zusammenspiel verschiedener Komponenten:
- OCR macht gescannte Dokumente maschinenlesbar.
- Das lokale LLM interpretiert unstrukturierte Rechnungstexte.
- Die Datenbank speichert extrahierte Informationen dauerhaft und durchsuchbar.
- Regelbasierte Logik vergleicht Rechnungen und Kontobewegungen nachvollziehbar.
- Ein Matching-Score macht die Sicherheit einer Zuordnung bewertbar.
- Die Weboberfläche bringt den Prozess in einen nutzbaren Arbeitsablauf.
Gerade für mittelständische Unternehmen ist diese Kombination interessant. Sie erlaubt, bestehende Prozesse schrittweise zu erweitern, statt sofort eine komplette Systemlandschaft zu ersetzen. Ein lokales Modell muss dabei nicht jede Aufgabe übernehmen. Häufig reicht es, genau den Teil zu automatisieren, der bisher schwer strukturiert auszuwerten war.
Fazit: Lokale KI muss nicht groß anfangen
Unser Buchhaltungs-Proof-of-Concept begann mit einer überschaubaren Frage: Wie lassen sich Rechnungen und Kontoauszüge schneller und zuverlässiger zusammenführen?
Die Antwort ist eine Anwendung, in der lokale KI mit bewährten Softwarebausteinen kombiniert wird. Das LLM liest und strukturiert Inhalte. OCR erschließt gescannte Dokumente. Datenbanken speichern Ergebnisse. Ein selbst entwickelter Matcher bewertet mögliche Zuordnungen. Eine Weboberfläche macht den Ablauf bedienbar.
Damit zeigt das Projekt einen realistischen Weg für den Einsatz lokaler KI: nicht als Ersatz für Fachwissen oder Kontrolle, sondern als Bestandteil eines klar definierten Prozesses. Der nächste sinnvolle Schritt ist nicht möglichst viel Automatisierung, sondern die gezielte Weiterentwicklung dort, wo sie im Alltag messbar Arbeit spart und nachvollziehbare Ergebnisse liefert.
