Hintergrund: Wachstumsdruck im Back-Office
Dieser Fall ist ein Composite aus Mustern, die Forfis in der Praxis beobachtet hat. Wir benennen keine echten Kunden, um die Vertraulichkeit der Projekte zu wahren. Die beschriebene Firma ist ein fiktives, aber plausibles B2B-SaaS-Unternehmen mit 35 Mitarbeitern in Wien. Das Unternehmen befindet sich in der Wachstumsphase und nutzt ein Standard-ERP sowie Confluence für die Wissensdokumentation. Der operative Druck war hoch: Die Skalierung der Kundenbasis führte zu einem Anstieg der eingehenden Rechnungen um 60 % im Vorjahr, während das Back-Office-Team konstant blieb. Die Folge war eine wachsende Stauung im Rechnungsworkflow, die die Cash-Flow-Prognosen verzerrte und die Controller mit Routineaufgaben band, die eigentlich für die Finanzplanung reserviert waren.
Die Herausforderung: Routinearbeit bindet Kapazitäten
Die Kernproblematik war nicht die fehlende Software, sondern die mangelnde Orchestrierung. Manuelle Datenerfassung aus PDF-Rechnungen in das ERP war fehleranfällig und zeitintensiv. Zudem gab es keine klare Trennung zwischen der Extraktion und der Validierung. Senior-Controller verbrachten bis zu 12 Stunden pro Woche mit der manuellen Prüfung von Belegen und der Korrektur von Buchungsfehlern. Der Bedarf war eindeutig: Die Routinearbeit musste automatisiert werden, um das Senior-Team für strategische Analysen und die Vorbereitung der Jahresabschlüsse zu entlasten. Zusätzlich bestand der Bedarf an Compliance-Sicherheit im Hinblick auf den EU AI Act, da die Automatisierung finanzielle Transaktionen betraf.
Ansatz: Audit und Orchestrierung mit LangGraph
Forfis startete mit einer AI Automation Audit Phase, die zwei Wochen dauerte. Dabei wurden die bestehenden Workflows in Confluence analysiert und die Datenquellen (ERP-API, E-Mail-Postfächer) kartiert. Die technische Architektur basierte auf LangChain und LangGraph. LangGraph wurde genutzt, um den Workflow als Zustandsmaschine zu modellieren: Der Agent extrahiert die Daten, prüft sie gegen die in Confluence hinterlegten Buchungsrichtlinien (via RAG) und pausiert bei Unsicherheiten, bis ein Mensch die Freigabe erteilt. Die Integration erfolgte über die Confluence-API, um die internen Richtlinien als Kontext für den LLM bereitzustellen. Die Modellwahl war model-agnostic: Für die Extraktion kamen proprietäre APIs zum Einsatz, für die Orchestrierung offene Modelle auf eigener Hardware, um die Latenz zu minimieren.
Ergebnis: Messbare Effizienzsteigerung
Nach 8 Wochen war der Pilot live. Die Messung der Baseline vor dem Start zeigte eine durchschnittliche Durchlaufzeit von 4,5 Tagen pro Rechnung und eine Fehlerquote von 8 % bei der Kontenzuordnung. Nach dem Rollout sank die Durchlaufzeit auf 1,2 Tage, da die automatische Validierung die manuellen Prüfzyklen eliminierte. Die Fehlerquote reduzierte sich auf unter 1 %, da der Agent die Daten gegen die ERP-Referenzdaten abgleicht, bevor sie gebucht werden. Das Senior-Team konnte 40 % seiner Zeit in der Rechnungsverarbeitung einsparen und diese für die Liquiditätsplanung und die Analyse der Kundensegmente nutzen. Die Compliance-Anforderungen des EU AI Acts wurden durch den dokumentierten Human-in-the-Loop-Prozess und die transparente Logik der LangGraph-States erfüllt.
Lektionen für ähnliche Teams
- Baseline messen, bevor man baut: Ohne die genaue Erfassung der Durchlaufzeit und Fehlerquote vor dem Piloten lässt sich der ROI nicht belegen. Die Audit-Phase ist kein Overhead, sondern die Grundlage für die Erfolgsmessung.
- RAG für interne Richtlinien nutzen: Die Integration von Confluence oder Notion als Wissensquelle für den LLM reduziert Halluzinationen bei der Kategorisierung erheblich. Der Agent muss nicht „wissen“, wie man bucht, sondern kann die Richtlinien abfragen.
- Human-in-the-Loop ist Compliance: Im Kontext des EU AI Acts ist die menschliche Freigabe für finanzielle Transaktionen nicht nur eine Sicherheitsmaßnahme, sondern eine rechtliche Notwendigkeit. Die Architektur muss diese Pausenpunkte explizit in der Zustandsmaschine abbilden.
- Model-Agnostizität spart Kosten: Nicht jeder Schritt braucht das teuerste Modell. Die Trennung von Extraktion (hohe Qualität) und Orchestrierung (hohe Geschwindigkeit) optimiert die Betriebskosten pro Transaktion.
Leave a Reply