Rechnungsprüfung in 18 Minuten statt 2 Stunden.
Ein Agent liest eingehende PDFs, gleicht mit Bestellungen ab und bucht im ERP.
„Der Agent macht genau das, wofür wir ihn gebraucht haben. Nicht mehr, nicht weniger. Das war neu für uns."
Ausgangslage.
Eine mittelständische Logistikfirma aus Nordrhein-Westfalen, rund 85 Mitarbeiter, rund 340 eingehende Rechnungen pro Monat von etwa 120 wiederkehrenden Lieferanten. Spediteure, Treibstoff, Reparaturen, Zollabwicklungen. Die Rechnungen kommen per E-Mail, als PDF-Anhang, in etwa 40 verschiedenen Formaten.
Der bestehende Prozess war vollständig manuell. Eine Mitarbeiterin öffnete jede Rechnung, las Lieferant, Beträge und Bestellreferenz ab, wechselte in das ERP — ein langjährig eingesetztes mittelständisches System ohne moderne API —, erfasste die Daten und glich mit der dort hinterlegten Bestellung ab. Bei Übereinstimmung wurde gebucht. Bei Abweichungen entstand ein Klärungsprozess über E-Mail oder Telefon, der häufig mehrere Tage dauerte.
Die durchschnittliche Bearbeitungszeit lag bei 15 bis 20 Minuten pro Rechnung. Bei 340 Rechnungen im Monat entsprach das etwa 90 Stunden — ein halber Personenmonat, der allein für eine Tätigkeit aufgewendet wurde, die keinerlei fachliches Urteil erforderte, sondern schlichtes Abgleichen von Zahlen.
Die Folge: Die Fachkraft in der Buchhaltung arbeitete den Großteil ihrer Zeit an einer Aufgabe, für die sie überqualifiziert war. Ausfallzeiten, Urlaub oder Krankheit führten zu Zahlungsverzögerungen und zu Rückfragen aus dem Einkauf. Die Geschäftsführung wollte die Situation geändert haben, ohne zusätzliche Stellen zu schaffen.
Erschwerend kam hinzu, dass Skonto-Fristen regelmäßig nicht eingehalten wurden. Bei einer angesetzten Skonto-Quote von 2 Prozent auf durchschnittlich 280.000 Euro monatlichem Einkaufsvolumen verloren dem Unternehmen rechnerisch zwischen 2.500 und 4.000 Euro pro Monat — nur weil die Rechnung an Tag 12 statt an Tag 10 gebucht wurde.
Eine frühere Überlegung, die Buchhaltung mit einem klassischen OCR-Werkzeug auszurüsten, war daran gescheitert, dass die Vielfalt der Rechnungsformate die handelsüblichen Schablonen-Ansätze überforderte. Jedes neue Format hätte eine separate Konfiguration erfordert, und die Fehlerquote bei variablen Layouts lag zu hoch, um die Buchhaltung tatsächlich zu entlasten.
Unser Vorgehen.
Wir haben einen Tag im Haus verbracht. Die Buchhaltungs-Mitarbeiterin hat uns den Prozess gezeigt — nicht die dokumentierte Version, sondern den tatsächlichen. Mit allen Sonderfällen, Abkürzungen und informellen Absprachen. Das war der wichtigste Teil der gesamten Analyse.
Drei Erkenntnisse aus diesem Tag. Erstens: Die 40 Rechnungsformate ließen sich auf fünf Grundmuster zurückführen — ein Befund, der die technische Komplexität deutlich reduzierte. Zweitens: Etwa 80 Prozent der Rechnungen waren „sauber" — eindeutige Bestellreferenz, übereinstimmende Beträge, kein Klärungsbedarf. Drittens: Die Abweichungen in den übrigen 20 Prozent waren inhaltlich, nicht technisch — zum Beispiel nachträgliche Preisänderungen, Teillieferungen, Mengenrabatte, die der Agent nie eigenständig entscheiden dürfte.
Zusätzlich haben wir einen Katalog von Edge-Cases aufgenommen, die für die Mitarbeiterin Routine waren, von außen aber leicht zu übersehen: Gutschriften, die sich auf eine frühere Rechnung beziehen; Sammelrechnungen mit mehreren Teilbestellungen; Währungsumrechnungen bei Lieferanten aus dem Euro-Ausland; Steuersätze, die je nach Produktgruppe wechseln. Jeder dieser Fälle bekam eine eigene Regel zugewiesen.
Daraus entstand eine klare Aufgabenabgrenzung. Der Agent sollte die 80 Prozent automatisch bearbeiten und die 20 Prozent mit qualifizierter Eskalationsnotiz an die Buchhaltung weiterleiten. Keine Entscheidung über strittige Fälle — dafür deutlich bessere Aufbereitung der Fälle, die Menschen entscheiden müssen.
Bevor wir mit dem Bau begannen, haben wir dieses Scope-Dokument mit der Mandantin gegengelesen. Die Buchhaltungs-Mitarbeiterin hat drei Präzisierungen beigesteuert, die wir im Alleingang übersehen hätten — zum Beispiel dass bestimmte Lieferanten in den Sommermonaten regelmäßig Rechnungen mit fehlerhaften Bestellnummern senden, die durch einen Abgleich über den Betrag dennoch zuverlässig zugeordnet werden können.
Die Umsetzung.
Technisch bestand der Agent aus drei Komponenten. Ein E-Mail-Listener, der eingehende Nachrichten an eine dedizierte Adresse abgreift und in ein internes Verarbeitungs-Postfach einsortiert. Ein Extraktions-Schritt, der die PDF mit einem Sprachmodell (Claude Sonnet, EU-gehostet) in ein strukturiertes JSON-Objekt überführt — Lieferant, Rechnungsnummer, Positionen, Beträge, Steuer, Bestellreferenz. Und ein ERP-Adapter, der das JSON gegen die Stammdaten und offenen Bestellungen prüft und — bei Übereinstimmung — die Buchung auslöst.
Der ERP-Adapter war der aufwändigste Teil. Das ERP hatte keine API. Wir haben einen Zugriff über die mitgelieferten Datei-Import-Schnittstellen gebaut — strukturierte CSV-Dateien, die in einem bestimmten Verzeichnis abgelegt und vom ERP-Scheduler alle fünf Minuten eingelesen werden. Die Logik zum Abgleich mit den offenen Bestellungen läuft im Adapter, nicht im Sprachmodell — so bleibt die Entscheidung deterministisch und prüfbar. Das Sprachmodell liefert nur die Interpretation der unstrukturierten PDF-Daten.
Drei Prinzipien haben wir durchgehalten. Erstens Nachvollziehbarkeit: Jede Entscheidung des Agents ist mit dem Original-PDF, dem extrahierten JSON, der Regelanwendung und dem Zeitstempel protokolliert. Alle Entscheidungen sind rückverfolgbar und exportierbar. Zweitens Konfidenz: Unterschreitet das Modell eine festgelegte Schwelle, eskaliert der Agent an die Buchhaltung — mit dem konkreten Hinweis, woran es gelegen hat. Drittens Datenhoheit: Die PDFs werden ausschließlich in einer EU-gehosteten Infrastruktur verarbeitet, kein Training auf den Geschäftsdaten, kein Datenabfluss an Dritt-Dienste.
Die Entwicklung lief in drei zweiwöchigen Auslieferungen. Nach zwei Wochen stand der Extraktions-Schritt und lief gegen einen Satz von 300 historischen Rechnungen, um die Extraktions-Qualität zu messen. Erste Durchläufe zeigten 94 Prozent korrekte Extraktion — genug, um in die ERP-Integration zu investieren. Nach vier Wochen war die ERP-Integration funktional und konnte Test-Buchungen durchführen. In den letzten zwei Wochen haben wir Edge Cases gehärtet, Eskalations-Templates verfeinert und das Logging produktionsreif gemacht. Eine Woche Schatten-Betrieb parallel zum manuellen Prozess gab der Mandantin die Sicherheit, den echten Livegang zu wagen.
Ergebnis nach sechs Monaten.
Der Agent läuft seit dem Livegang stabil im Betrieb. Von 340 Rechnungen pro Monat verarbeitet er zwischen 260 und 280 vollautomatisch. Die verbleibenden 60 bis 80 Rechnungen landen mit Eskalations-Notiz bei der Buchhaltung und werden dort in durchschnittlich drei Minuten abgeschlossen — gegenüber 15 bis 20 Minuten im alten Prozess.
Die Entlastung summiert sich auf etwa 18 Stunden pro Woche, also rund 80 Stunden pro Monat. Die Buchhaltungs-Mitarbeiterin nutzt die gewonnene Zeit für Kassenabstimmungen, für das Vier-Augen-Prinzip bei größeren Zahlungen und für die monatliche Abstimmung mit dem Einkauf — Tätigkeiten, die im alten Regime regelmäßig liegen geblieben sind und die fachlich eigentlich ihre eigentliche Aufgabe waren.
Messbar ist auch die Durchlaufzeit: Rechnungen werden im Schnitt am Tag ihres Eingangs gebucht, nicht mehr erst nach zwei oder drei Tagen. Die Skonto-Quote ist von vormals 40 Prozent auf inzwischen 92 Prozent gestiegen. Bei 280.000 Euro monatlichem Einkaufsvolumen und 2 Prozent Skonto rechnet die Geschäftsführung mit rund 40.000 Euro zusätzlicher Ersparnis pro Jahr — allein aus diesem Nebeneffekt.
Die Eskalations-Quote liegt aktuell bei etwa 22 Prozent und hat sich in den letzten Wochen stabilisiert. Sie spiegelt nahezu genau die Quote der fachlich nicht eindeutigen Fälle wider — das Ziel, dass Menschen nur noch entscheiden, wo es etwas zu entscheiden gibt, ist damit erreicht.
Was wir gelernt haben.
Der schwierigste Teil war nicht die Technik, sondern die saubere Aufgabenabgrenzung im ersten Projekttag. Ohne das klare „Welche 80 Prozent, welche 20 Prozent" wäre der Agent entweder zu mutig geworden — und hätte zweifelhafte Fälle eigenmächtig verbucht — oder zu zurückhaltend, und die Einsparung wäre verpufft. Dieser eine Tag Analyse vor Projektbeginn war mehr wert als jede zusätzliche Woche Entwicklung.
Die zweite Lektion: ERP-Integration über Datei-Import ist weniger elegant als über eine API, aber sie funktioniert zuverlässig. Wir haben in diesem Projekt wieder bestätigt bekommen, dass auch alte Systeme integrierbar sind, wenn man das Integrations-Format dem System anpasst, nicht umgekehrt. Der Kunde muss nicht sein ERP wechseln, um zu automatisieren.
Drittens: Das Logging wurde im Nachhinein zum wichtigsten Feature. Zwei Monate nach Livegang hat die Mandantin eine Rückfrage eines Wirtschaftsprüfers bekommen, zu einer konkreten Buchung. Innerhalb von Minuten konnte sie das Ursprungs-PDF, die Extraktion, die Regelanwendung und die Zeitstempel zeigen. Das hat mehr Vertrauen geschaffen als jeder Demo-Termin zuvor — und es ist das, was wir heute bei jedem neuen Projekt von Anfang an einbauen.
Eine vierte Erkenntnis betraf den Betrieb nach Livegang. Wir hatten mit zwei bis drei Wochen intensiver Begleitung gerechnet, bis der Agent stabil lief. Tatsächlich war nach einer Woche alles ruhig — die sorgfältige Vorarbeit hatte sich ausgezahlt. Die Begleitzeit haben wir stattdessen genutzt, um gemeinsam mit der Mandantin einen Prozess für Regeländerungen aufzusetzen: Wer darf Schwellen anpassen, wie wird dokumentiert, wie wird getestet. Dieser Governance-Prozess ist heute ebenso Teil des Projekts wie der Agent selbst.