LLM-Rechnungsprüfung in SAP: On-Premise-Pilot in 3 Monaten

Das Problem: Manuelle Rechnungsprüfung bindet Kapazität in der Finanzabteilung

E-Commerce-Unternehmen mit 501 bis 2.000 Mitarbeitern in Deutschland stehen vor einem strukturellen Problem: Der manuelle Aufwand für die Rechnungsprüfung und das monatliche Reporting in SAP oder Microsoft Dynamics ERP bindet 40 bis 60 Prozent der Kapazität der Finanzabteilung. Die Belege kommen aus verschiedenen Kanälen, die Kontierung folgt komplexen Regeln, und die Antwortzeit auf interne Anfragen zu offenen Posten liegt oft über 24 Stunden. Ein LLM-System, das direkt in die bestehende ERP-Landschaft integriert wird, kann diese Prozesse automatisieren. Der Ansatz ist ein Fixed-Scope-Pilot: In 3 Monaten wird ein spezifischer Teilbereich der Buchhaltung mit einem Conversational Agent ausgestattet, der auf Open-Weight-Modellen auf eigener Hardware läuft. Das Ziel ist eine 24/7-Antwortfähigkeit und eine messbare Reduktion der Zykluszeit für die Rechnungsprüfung.

Voraussetzungen: Hardware, Daten und API-Zugriff

Bevor der erste Code geschrieben wird, müssen vier Voraussetzungen erfüllt sein. Erstens: Ein definierter Pilotumfang. Wählen Sie ein spezifisches ERP-Modul, z. B. nur die Kreditorenbuchhaltung für Lieferanten aus dem Bereich Logistik. Zweitens: Hardware. Ein Server mit mindestens 2x NVIDIA A100 (80 GB VRAM) oder 4x NVIDIA L40S im Rechenzentrum des Kunden. Drittens: API-Zugriff. Read-Only-Zugriff auf die relevanten SAP- oder Dynamics-Tabellen (z. B. BSEG, BKPF in SAP) und Schreibzugriff auf die Freigabe-Endpunkte. Viertens: Datenbasis. Mindestens 6 Monate historische Rechnungsdaten für das Training des RAG-Systems und die Kalibrierung der Kontierungsregeln. Ohne diese Basis ist die Fehlerquote im Pilot nicht messbar.

Schritte: Vom Prozess-Audit zum laufenden Piloten

1. Prozess-Audit durchführen. Dokumentieren Sie den aktuellen Workflow der Rechnungsprüfung. Messen Sie die Zykluszeit von der Belegannahme bis zur Buchung und die Fehlerquote bei der Kontierung. Nutzen Sie die ERP-Logs aus den letzten 6 Monaten als Baseline. 2. Pilotumfang festlegen. Definieren Sie die Grenzen des Pilots: Welche Rechnungsarten, welche Lieferanten, welches ERP-Modul? Dokumentieren Sie diese Grenzen in einem Scope-Statement, das von der Geschäftsführung signiert wird. 3. Hardware aufsetzen. Installieren Sie den LLM-Server im Rechenzentrum. Konfigurieren Sie vLLM oder TGI (Text Generation Inference) als Inferenz-Engine. Laden Sie ein quantisiertes Open-Weight-Modell, z. B. Llama-3-70B-Instruct oder Mistral-7B, mit 4-Bit-Quantisierung. 4. RAG-Pipeline aufbauen. Erstellen Sie eine Vektordatenbank (z. B. Weaviate oder Qdrant) und indexieren Sie die historischen Rechnungsdaten. Verknüpfen Sie die Vektoren mit den ERP-Metadaten (Kontonummern, Kostenstellen, Lieferanten-IDs). 5. Conversational Agent implementieren. Entwickeln Sie den Agenten mit LangChain oder LlamaIndex. Der Agent empfängt Anfragen über eine Web-Oberfläche oder E-Mail, durchsucht die Vektordatenbank und schlägt die Kontierung vor. 6. Human-in-the-Loop einbauen. Implementieren Sie eine Freigabe-Schleife: Der Agent schlägt vor, ein Buchhalter prüft und bestätigt. Loggen Sie jede Interaktion für die Audit-Trail-Anforderungen. 7. Pilot starten und messen. Führen Sie den Piloten für 12 Wochen durch. Messen Sie wöchentlich die Zykluszeit, die Fehlerquote und die Antwortzeit des Agents. Vergleichen Sie die Werte mit der Baseline aus Schritt 1.

Häufige Stolperfallen und wie Sie sie erkennen

Die häufigsten Fehler bei der Implementierung sind: Unklare Datenqualität. Wenn die historischen Rechnungsdaten im ERP unvollständig oder fehlerhaft sind, lernt das RAG-System falsche Muster. Erkennen Sie das durch eine hohe Abweichungsrate in der Testphase (über 15 Prozent). Zu enger Pilotumfang. Wenn weniger als 500 Belege pro Woche verarbeitet werden, ist die statistische Signifikanz zu gering, um eine echte Effizienzsteigerung zu belegen. Fehlende Human-in-the-Loop-Prozesse. Wenn der Agent ohne menschliche Freigabe bucht, entstehen automatische Fehlbuchungen, die erst im Monatsabschluss auffallen. Hardware-Engpässe. Bei Spitzenlasten (z. B. Monatsabschluss) kann die GPU-Utilisation 100 Prozent erreichen und die Warteschlange wächst. Erkennen Sie das durch Monitoring der GPU-Utilisation und der Antwortzeiten. Unklare Verantwortlichkeiten. Wenn nicht definiert ist, wer für die Freigabe verantwortlich ist, stockt der Prozess. Definieren Sie klare Rollen: Der Agent schlägt vor, der Buchhalter prüft, der Controller bestätigt.

Fazit: Vom Piloten zur Managed-Operation

Nach 12 Wochen liegt der Pilotbericht vor. Er enthält die gemessenen Werte: Zykluszeit, Fehlerquote, Antwortzeit und die Anzahl der verarbeiteten Belege. Vergleichen Sie diese Werte mit der Baseline aus dem Prozess-Audit. Wenn die Zykluszeit um mindestens 30 Prozent gesunken ist und die Fehlerquote unter 5 Prozent liegt, ist der Pilot erfolgreich. Der nächste Schritt ist die Ausrollung auf weitere ERP-Module oder Abteilungen. Dafür benötigen Sie eine erweiterte Hardware-Kapazität und eine Anpassung der RAG-Pipeline an die neuen Datenquellen. Die Managed-Operation übernimmt die Wartung des LLM-Servers, das Monitoring der GPU-Utilisation und die kontinuierliche Verbesserung des RAG-Systems durch Feedback-Schleifen. Das System bleibt model-agnostic: Wenn ein neues Open-Weight-Modell mit besserer Qualität verfügbar wird, kann es ohne Änderung der ERP-Anbindung eingespielt werden.