AI-Agent für Rechnungsprüfung: 8-Wochen-Pilot im Schweizer E-Commerce

Hintergrund: Schweizer E-Commerce-Unternehmen mit 2.500 Mitarbeitern

Dieser Fall ist ein Composite aus Mustern, die Forfis in der Praxis beobachtet hat. Wir nennen keine echten Kundennamen, um die Vertraulichkeit zu wahren. Die folgende Geschichte basiert auf einem typischen Mandat im Schweizer E-Commerce-Sektor. Der Kunde ist ein mittelständischer Händler mit über 2.500 Mitarbeitern, der in der DACH-Region aktiv ist. Die operative Herausforderung lag im Backoffice: Die manuelle Erfassung von Lieferantenrechnungen und die Erstellung der monatlichen Berichtsdaten binden ein ganzes Team. Die IT-Infrastruktur besteht aus einem SAP-ERP-System und einer veralteten Dokumentenverwaltung. Das Ziel war klar: Die Kosten pro Support-Ticket senken, indem die manuelle Datenerfassung eliminiert wird, ohne das bestehende ERP zu ersetzen.

Herausforderung: Manuelle Datenerfassung und hohe Kosten pro Ticket

Der operative Druck war hoch. Die monatliche Berichtsphase dauerte bisher 10 Arbeitstage, da die Daten aus PDFs manuell in Excel kopiert und dann ins SAP-System übertragen wurden. Fehler bei der Währungsumrechnung oder der Zuordnung zu den falschen Kostenstellen führten zu Verzögerungen in der Finanzabteilung. Zudem stieg die Anzahl der Lieferanten, was die Komplexität der Rechnungsformate erhöhte. Die bestehende Lösung, eine einfache OCR-Software, konnte die semantischen Zusammenhänge nicht erfassen und scheiterte an neuen Layouts. Die Geschäftsführung forderte eine Lösung, die innerhalb von 8 Wochen einen messbaren Piloten lieferte, der die manuelle Arbeit für einen spezifischen Prozess reduziert.

Ansatz: RAG-Architektur mit pgvector und modell-agnostischer Integration

Forfis startete mit einem Prozess-Audit, um den Workflow mit dem höchsten Hebel zu identifizieren: die Lieferantenrechnungsprüfung. Der Pilot umfasste die Entwicklung eines AI-Agenten, der auf einer RAG-Architektur (Retrieval-Augmented Generation) basiert. Statt die Dokumente nur zu lesen, wurden die relevanten Kontexte aus der internen Dokumentation und den CRM-Daten über pgvector Embeddings abgerufen. Die Architektur ist modell-agnostisch: Für die Extraktion kamen offene Modelle auf der Hardware des Kunden zum Einsatz, während die semantische Einordnung über APIs von OpenAI und Anthropic erfolgte. Die Integration in SAP lief über die Standard-APIs. Der Scope war festgelegt: Nur die Rechnungsprüfung, keine anderen Prozesse. Die Lieferung erfolgte als Fixed-Scope Pilot mit klaren Abnahmekriterien.

Ergebnis: Messbare Reduktion der Durchlaufzeit und Fehlerquote

Nach 8 Wochen war der Pilot live. Die Ergebnisse waren messbar: Die Durchlaufzeit für die Rechnungsprüfung sank von durchschnittlich 45 Minuten pro Beleg auf 8 Minuten. Die Fehlerquote bei der Datenerfassung reduzierte sich von 12 Prozent auf unter 2 Prozent. Die Kosten pro Support-Ticket, die durch manuelle Nachfragen bei Lieferanten entstanden, sanken um 35 Prozent. Die monatliche Berichtsphase verkürzte sich von 10 auf 3 Arbeitstage. Die manuelle Arbeit wurde nicht eliminiert, sondern auf die 6 Prozent der Fälle reduziert, die die KI nicht sicher zuordnen konnte. Das Team konnte sich auf die Ausnahmen konzentrieren, statt auf die Routine. Die Integration in SAP funktionierte stabil, ohne dass das ERP-System angepasst werden musste.

Lektionen: Was ähnliche Teams daraus lernen können

1. Prozess-Audit vor Technologie: Die Auswahl des richtigen Workflows ist wichtiger als die Wahl des besten Modells. Ein Prozess mit klaren Eingaben und Ausgaben eignet sich besser für einen Piloten als ein komplexer, unstrukturierter Workflow. 2. Human-in-the-Loop ist Standard: Die KI entwirft, der Mensch genehmigt. Dies ist nicht nur eine Sicherheitsmaßnahme, sondern auch der Weg, um die Genauigkeit der Modelle durch Feedback zu verbessern. 3. Modell-Agnostik ist Flexibilität: Die Architektur sollte es erlauben, Modelle je nach Bedarf zu wechseln, ohne die gesamte Integration neu aufzubauen. 4. Feste Scope-Grenzen: Ein Pilot mit klarem Umfang liefert schneller messbare Ergebnisse als ein offenes Projekt. 5. Integration statt Ersetzung: Das System muss in die bestehende Infrastruktur passen, nicht umgekehrt.