Die manuelle Last in der Buchhaltung und im Vertragswesen
In einem Schweizer E-Commerce-Unternehmen mit 350 Mitarbeitern landen täglich 400 bis 600 Lieferantenrechnungen im ERP-System. Die Buchhaltung muss jede Rechnung manuell erfassen, die Kategorie zuordnen, die Zahlungsbedingungen prüfen und die Daten in das Controlling-System übertragen. Gleichzeitig prüfen die Mitarbeiter der Rechtsabteilung 15 bis 20 Verträge pro Woche auf abweichende Klauseln. Die durchschnittliche Bearbeitungszeit pro Rechnung liegt bei 12 Minuten, die Fehlerquote bei 3,2 Prozent. Bei 500 Rechnungen pro Tag bedeutet das: 100 Stunden manuelle Arbeit pro Woche und 16 fehlerhafte Einträge, die nachträglich korrigiert werden müssen.
Das Problem ist nicht die Menge, sondern die Wiederholung. 80 Prozent der Rechnungen folgen demselben Muster, 70 Prozent der Verträge enthalten dieselben Standardklauseln. Die Mitarbeiter arbeiten nicht, weil die Aufgabe komplex ist, sondern weil das System keine intelligente Vorarbeit leistet. Die Buchhaltung ist überlastet, die Rechtsabteilung arbeitet im Stau, und das Controlling bekommt die Daten zu spät, um fundierte Entscheidungen zu treffen.
Warum OCR, RPA und generische LLMs nicht ausreichen
Die erste Reaktion auf dieses Problem ist oft die Anschaffung einer OCR-Lösung. Sie erkennt die Zahlen auf der Rechnung, aber sie versteht nicht, was die Zahlen bedeuten. Eine Rechnung über 4 500 Euro für „Logistik Q3“ wird korrekt erfasst, aber die Kategorisierung bleibt manuell. Die OCR-Lösung reduziert die Erfassungszeit von 12 auf 8 Minuten, aber die 4 Minuten für die Kategorisierung und die Prüfung der Zahlungsbedingungen bleiben. Die Fehlerquote sinkt kaum, weil die OCR keine Kontextinformationen nutzt.
Die zweite Reaktion ist die Einführung eines RPA-Bots. Er führt die Schritte aus, die ein Mensch ausführt: Daten kopieren, in ein anderes System einfügen, eine Regel anwenden. Aber RPA ist starr. Wenn sich das Format der Rechnung ändert, bricht der Bot. Wenn eine Klausel im Vertrag leicht anders formuliert ist, erkennt der Bot die Abweichung nicht. RPA automatisiert die Ausführung, aber nicht die Entscheidung.
Die dritte Reaktion ist die Nutzung eines generischen LLM über eine API. Das Modell kann die Rechnung verstehen und die Kategorie vorschlagen. Aber es kennt nicht die interne Kontenstruktur des Unternehmens, nicht die historischen Daten, nicht die spezifischen Klauseln, die im eigenen Vertragswerk verwendet werden. Die Vorschläge sind plausibel, aber nicht präzise genug für die Buchhaltung. Und die Daten verlassen das Unternehmen, was bei PCI-DSS-konformen Prozessen ein Problem ist.
Der Ansatz: pgvector, Open-Weight-Modelle und Human-in-the-Loop
Die Lösung liegt in einer Integration, die das bestehende System nicht ersetzt, sondern um eine intelligente Schicht ergänzt. Der Ansatz basiert auf drei Komponenten: Erstens, eine pgvector-basierte Embedding-Suche, die die historischen Rechnungsdaten und Vertragsklauseln als Vektoren speichert. Wenn eine neue Rechnung eingeht, wird sie in einen Vektor umgewandelt und mit den historischen Daten abgeglichen. Das System erkennt, dass diese Rechnung zur Kategorie „Logistik“ gehört, weil 92 Prozent der ähnlichen Rechnungen in der Vergangenheit so kategorisiert wurden.
Zweitens, ein Open-Weight-Modell auf der eigenen Hardware, das die Anreicherung und die Vertragsprüfung durchführt. Das Modell wird auf den spezifischen Daten des Unternehmens fine-tuned und kennt die interne Kontenstruktur, die Vertragsklauseln und die Compliance-Anforderungen. Die Daten verlassen das Gebäude nicht, was die PCI-DSS-Konformität sichert.
Drittens, eine Human-in-the-Loop-Architektur, die sicherstellt, dass jede Anreicherung und jede Vertragsprüfung von einem Menschen freigegeben wird, bevor sie im ERP gespeichert wird. Die KI reduziert die Vorarbeit um 70 bis 80 Prozent, aber die Entscheidung bleibt beim Menschen.
Vier konkrete Schritte für den Start
Der erste Schritt ist der Prozess-Audit. In zwei Wochen werden die Workflows der Buchhaltung und der Rechtsabteilung dokumentiert. Es werden die Metriken gemessen: Bearbeitungszeit pro Rechnung, Fehlerquote, Anzahl der manuellen Schritte. Der Audit liefert eine priorisierte Liste von drei bis fünf Workflows, die sich für die Automatisierung eignen. Der Pilot wird auf dem Workflow mit dem größten Hebel ausgewählt, typischerweise die Kategorisierung von Lieferantenrechnungen.
Der zweite Schritt ist die Anbindung an das ERP-System über die bestehenden REST-APIs und Webhooks. Das System liest die Rechnungen aus dem ERP, verarbeitet sie und schreibt die Anreicherung zurück. Kein Migrationsprojekt, keine doppelte Datenhaltung. Die Anbindung dauert 2 bis 3 Wochen.
Der dritte Schritt ist die Pilotphase mit einem begrenzten Datenumfang. 50 bis 100 Rechnungen pro Woche werden durch das System verarbeitet, die Ergebnisse werden mit den manuellen Ergebnissen verglichen. Die Metriken werden gemessen: Wie viele Vorschläge wurden akzeptiert? Wie viele mussten korrigiert werden? Wie viel Zeit wurde eingespart?
Der vierte Schritt ist die Ausweitung auf weitere Prozesse, typischerweise die Vertragsprüfung. Der fünfte Schritt ist die Übergabe an den Betrieb mit einer Schulung der Teams und einem Support-Vertrag.
Leave a Reply