Rechnungsautomatisierung mit offenen KI-Modellen im E-Commerce

Das Problem der manuellen Rechnungsverarbeitung im Mittelstand

In der Buchhaltung eines E-Commerce-Unternehmens mit 150 Mitarbeitern stapeln sich täglich hunderte Eingangsrechnungen. Die manuelle Erfassung in das ERP-System bindet zwei bis drei Fachkräfte vollständig. Das Problem ist nicht die Komplexität der Daten, sondern die Wiederholung: 80 Prozent der Rechnungen stammen von denselben Lieferanten und folgen denselben Layouts. Eine KI-Lösung, die diese Routinearbeit übernimmt, kann die Zykluszeit von der Rechnungseingangs bis zur Buchung von drei Tagen auf unter vier Stunden senken. Der entscheidende Punkt ist nicht die Automatisierung an sich, sondern die Integration in die bestehenden Prozesse. Das System darf das ERP nicht ersetzen, sondern muss als eine Schicht davor agieren, die die Daten bereinigt und klassifiziert, bevor sie in das Buchhaltungssystem fließen. Dieser Ansatz minimiert das Risiko und ermöglicht einen schrittweisen Rollout, bei dem die Mitarbeiter die Kontrolle behalten.

Die technische Architektur: Von der OCR bis zur ERP-Integration

Die Architektur basiert auf einer Pipeline, die in drei Stufen unterteilt ist. Zuerst wird das Dokument in ein einheitliches Format gebracht. Hier kommen OCR-Modelle wie Tesseract oder kommerzielle APIs zum Einsatz, die den Text aus dem PDF oder Scan extrahieren. Im zweiten Schritt übernimmt ein Large Language Model (LLM) die semantische Analyse. Das Modell identifiziert die relevanten Felder: Rechnungsnummer, Betrag, Steuern, Lieferant, Leistungszeitraum. Bei der Nutzung offener Modelle wie Llama 3 oder Mistral auf eigener Hardware bleibt das Dokument im Gebäude, was für Unternehmen mit sensiblen Daten ein entscheidender Vorteil ist. Die dritte Stufe ist die Validierung. Die extrahierten Daten werden gegen die Stammdaten im ERP geprüft. Stimmt der Lieferant, ist der Betrag plausibel, sind alle Pflichtfelder vorhanden? Erst wenn diese Checks bestehen, wird die Rechnung als ‘freigabefähig’ markiert. Die Kommunikation mit dem ERP erfolgt über REST-APIs. Bei SAP S/4HANA nutzt man die OData-Services, bei Dynamics 365 die Web Services. Die Daten werden als JSON-Objekte übertragen und im ERP als Buchungsantrag angelegt.

Trade-offs: Offene Modelle versus kommerzielle APIs

Die Wahl des Modells ist der wichtigste Hebel in der Architektur. Kommerzielle APIs von OpenAI oder Anthropic bieten die höchste Genauigkeit bei der semantischen Klassifikation, besonders bei unklaren Formulierungen oder mehrdeutigen Leistungsbeschreibungen. Der Nachteil: Die Daten verlassen das Unternehmen, was bei sensiblen Informationen problematisch sein kann. Offene Modelle auf eigener Hardware umgekehrt: Sie bieten volle Datenhoheit und keine laufenden Kosten pro Token, aber sie erfordern mehr Aufwand beim Feintuning. Für die reine Extraktion von Zahlen und Textfeldern genügen offene Modelle oft völlig. Für die Klassifikation von Kostenstellen oder die Zuordnung zu Projekten sind sie jedoch anfälliger. Die Lösung ist ein hybrides Setup: Die Extraktion läuft auf dem offenen Modell, die semantische Klassifikation auf der kommerziellen API. Oder man feintunt das offene Modell mit den eigenen Daten, bis es die gewünschte Genauigkeit erreicht. Dieser Trade-off muss pro Unternehmen individuell abgewogen werden.

Empfehlung: Der 3-Monats-Plan für einen erfolgreichen Rollout

Der Rollout in drei Monaten ist realistisch, wenn der Scope klar definiert ist. Woche eins: Prozessanalyse. Welche Rechnungsarten werden verarbeitet? Welche Felder sind Pflicht? Welche Lieferanten sind am häufigsten? Woche zwei bis vier: Entwicklung. Das Modell wird mit einer Stichprobe von 500 Rechnungen trainiert und evaluiert. Die Genauigkeit wird pro Feld gemessen. Woche fünf: Pilot. Das System läuft parallel zum manuellen Prozess. Die Ergebnisse werden verglichen. Woche sechs: Go-Live. Die manuelle Erfassung wird für die automatisierten Rechnungsarten eingestellt. Die Mitarbeiter prüfen nur noch die Ausnahmen. Wichtig ist, dass die Mitarbeiter von Anfang an eingebunden werden. Sie kennen die Stolpersteine: Welche Lieferanten senden Rechnungen mit unklaren Leistungsbeschreibungen? Welche Felder sind im ERP Pflicht? Dieses Wissen ist für das Feintuning des Modells unverzichtbar. Ohne diese Zusammenarbeit scheitert das Projekt an der Realität der Daten.

Stolperfallen und wie man sie vermeidet

Die größte Stolperfalle ist die Annahme, dass das Modell von Anfang an perfekt funktioniert. Das ist es nicht. In der Pilotphase werden Fehler sichtbar: Ein Lieferant ändert sein Layout, ein neues Feld wird eingeführt, die OCR erkennt eine Zahl falsch. Diese Fehler sind nicht das Ende, sondern der Anfang des Lernprozesses. Das System muss so aufgebaut sein, dass es leicht nachjustiert werden kann. Neue Layouts werden als Templates hinterlegt, die OCR-Parameter werden angepasst, das Modell wird mit den neuen Daten neu evaluiert. Ein weiterer Stolperstein ist die Erwartungshaltung der Mitarbeiter. Wenn das System 90 Prozent der Rechnungen automatisch verarbeitet, aber die restlichen 10 Prozent besonders fehleranfällig sind, fühlen sich die Mitarbeiter überfordert. Die Lösung ist eine klare Kommunikation: Das System ist ein Assistent, kein Ersatz. Es übernimmt die Routine, die Menschen übernehmen die Ausnahmen. Diese Erwartungssteuerung ist oft wichtiger als die technische Umsetzung.