Max Schreiber 
Autonome Agenten im Finance-Backoffice: McKinsey beschreibt konkrete AI-Use-Cases bei Rechnungsverarbeitung, Reporting und Kostenkontrolle. Goldman Sachs Research nennt makroökonomische Zahlen, die einem den Atem verschlagen. Aber wie weit ist die Realität wirklich? Klartext: zwischen Hype und hartem Deployment liegt ein gewaltiger Graben.
Seien wir ehrlich: Die meisten Unternehmen, die heute über „autonome Agenten im Finance“ reden, haben vor drei Jahren noch RPA-Bots eingeführt und waren stolz darauf. Robotic Process Automation war der erste Schritt – regelbasiert, stur, aber berechenbar. Ein Bot, der eine Tabelle zieht, eine PDF-Rechnung ausliest und einen Buchungssatz vorschlägt.
Was sich gerade ändert, ist fundamental anders. Finance Automation der neuen Generation bedeutet: LLM-basierte Agenten, die Ziele bekommen, selbst Schritte planen, Datenquellen anzapfen und Ergebnisse in natürlicher Sprache übergeben. Kein hartkodiertes Regelwerk mehr, das nach dem dritten Ausnahmefall bricht. Stattdessen Systeme, die unstrukturierte Rechnungen, mehrdeutige Kontenbezeichnungen und schwankende Lieferanterdaten eigenständig interpretieren.
Der Unterschied ist nicht graduell. Er ist strukturell. RPA braucht einen Prozess, der zu hundert Prozent definiert ist. Autonomous Agents brauchen ein Ziel und Werkzeuge. Das klingt nach Kleinigkeit. Es ist eine andere Kategorie Software.
Trotzdem: Voll autonomes Finance-Backoffice, bei dem kein Mensch mehr kontrolliert? Stand heute nicht realistisch. Was dokumentiert ist: AI-gestützte Co-Piloten, automatisierte Teilprozesse, menschlich überwachte Agenten-Workflows. Das ist nicht nichts. Das ist eine Menge. Aber es ist nicht das, was manche Headlines versprechen.
McKinsey hat Finance Automation und den Einsatz von Gen-AI in Finance-Funktionen detailliert beschrieben. Laut McKinsey setzen Finance-Teams Gen-AI heute vor allem in drei Bereichen produktiv ein: strategische Planung und Kontrolle, Cash- und Working-Capital-Management sowie Kostenoptimierung. Konkrete Use-Cases umfassen automatisierte Kostenkategorisierung, Predictive Analytics für Forecasting und interaktive Szenarioanalysen.
Das ist relevant. Das ist auch beeindruckend. Aber es ist kein „voll autonomer Backoffice-Agent“.
McKinsey-Consultants beschreiben Systeme, die Rechnungen und Bestellungen analysieren und automatisch in strukturierte Kostenkategorien einordnen. Das ist ein klassischer Finance-Automation-Case. Der Agent liest die Rechnung, vergleicht mit Stammdaten, schlägt eine Kontierung vor – ein Mensch im Finance-Team bestätigt oder korrigiert. Co-Pilot-Szenario, nicht Vollautomation.
Die harte Wahrheit: Wer McKinsey-Berichte mit „Goldman Sachs rollt autonome Agenten produktiv aus“ übersetzt, vermischt zwei völlig verschiedene Dinge. Goldman Sachs ist als Forschungslieferant bekannt – mit Makrostudien zum wirtschaftlichen Impact von Generative AI. Als Anwender mit öffentlich dokumentiertem vollautonomem Finance-Backoffice ist Goldman Sachs Stand heute nicht seriös belegt.
Goldman Sachs Research hat 2023 geschätzt, dass generative AI bis zu 300 Millionen Vollzeitjobs weltweit beeinflussen könnte und das globale BIP um rund sieben Prozent über zehn Jahre steigern kann. Das McKinsey Global Institute hat in einer oft zitierten Analyse errechnet, dass AI-Technologien bis 2030 einen zusätzlichen globalen Output von rund 13 Billionen US-Dollar erzeugen könnten. Diese Zahlen werden in der Debatte um Autonomous Agents und Finance Automation regelmäßig zitiert – wichtig dabei: Die MGI-Zahl stammt aus einer Pre-Gen-AI-Analyse und sollte mit dem entsprechenden Zeitstempel gelesen werden.
Näher an der Praxis sind RPA-Erfahrungswerte, die einen indirekten Anhaltspunkt für Finance-Automation-Projekte liefern: Im ersten Jahr lassen sich laut Branchenanalysen rund 15 Prozent ROI erzielen, bei reifen Implementierungen nach drei Jahren können es über 200 Prozent werden. Allerdings bindet die Implementierung und Wartung in den ersten Jahren typischerweise 30 bis 50 Prozent der Einsparungen. Wer autonome Finance-Agenten als billigen Quick-Win verkauft, lügt Sie an.
Automatisierung kann in geeigneten Finance-Anwendungen 20 bis 40 Prozent der Arbeitskosten senken. Aber das ist der Zielzustand nach Jahren, nicht nach der ersten Pilotphase.
Schluss damit, Deployment-Komplexität kleinzureden. Finance Automation mit autonomen Agenten funktioniert nicht überall gleich gut. Die realistischen Early-Win-Bereiche sind klar: automatisierte Verarbeitung von Eingangsrechnungen, Kontierung und Kostenkategorisierung, Erstellung standardisierter monatlicher Reports, Monitoring von Zahlungsströmen und Ausreißer-Alerts sowie Cash-Position-Überwachung im Treasury.
Gemeinsam ist diesen Use-Cases: strukturierte oder semi-strukturierte Datenlage, klare Regeln für Ausnahmen, hohe Wiederholungsfrequenz, messbares Ergebnis. Ein Agent, der täglich die gleichen 200 Eingangsrechnungen mit den gleichen Lieferanten kategorisiert, lernt schnell und macht wenig Fehler. Ein Agent, der über eine außerordentliche Restrukturierungsbuchung entscheiden soll, ist fehl am Platz.
Meiner Einschätzung nach werden Unternehmen, die jetzt mit einem eng begrenzten, hochvolumigen Prozess starten, in 18 Monaten einen belastbaren Business Case haben – während die, die auf „Finance komplett autonom“ setzen, noch in Governance-Diskussionen stecken. Pilotfähigkeit vor Vollautonomie. Immer.
Neuere Architekturen gehen einen Schritt weiter. Statt einem General-Purpose-Agent übernehmen mehrere spezialisierte Agenten unterschiedliche Aufgaben: einer für Datenbeschaffung aus ERP und Datawarehouse, einer für Validierung gegen Richtlinien und Budgets, einer für die eigentliche Reportingerstellung. Diese Multi-Agent-Workflows werden über Orchestrierungsebenen koordiniert – funktional ähnlich dem, was LangChain, LlamaIndex oder CrewAI im Open-Source-Bereich realisieren.
Das klingt elegant. Es ist auch komplex. Jeder Agent braucht definierte Inputs, Outputs, Fehlerpfade und Eskalationsregeln. In einer Großbank mit Dutzenden von Systemen, unterschiedlichen Datenmodi und regulatorischen Anforderungen in verschiedenen Jurisdiktionen wird Orchestrierung schnell zur Hauptarbeit. Der Deployment-Aufwand ist real.
Wer Finance-Automation-Projekte begleitet hat, kennt die wiederkehrenden Muster, an denen Piloten scheitern oder sich verzögern. An erster Stelle steht fast immer die Datenqualität: Stammdaten, die in verschiedenen Quellsystemen unterschiedlich gepflegt sind, Lieferantennamen in drei Schreibweisen, Kostenstellen, die im ERP anders heißen als im Reporting-Tool. Kein Agenten-Framework löst ein Datenhygiene-Problem – es macht es sichtbarer, schneller und in größerem Maßstab.
An zweiter Stelle folgt die Prozessdokumentation. Viele Finance-Prozesse laufen im Kopf erfahrener Mitarbeiterinnen und Mitarbeiter ab, nicht in schriftlichen Richtlinien. Wenn ein Agent diese impliziten Regeln nicht kennt, macht er Fehler, die auf den ersten Blick unerklärlich wirken. Vor dem Deployment ist Prozess-Dokumentation keine bürokratische Pflicht, sondern technische Voraussetzung.
An dritter Stelle steht das Change-Management. Finance-Teams, die fürchten, durch Automatisierung ersetzt zu werden, sabotieren Piloten – nicht immer bewusst, aber konsequent. Projekte, die von Anfang an klar kommunizieren, welche Aufgaben der Agent übernimmt und welche Entscheidungen beim Menschen bleiben, haben deutlich höhere Akzeptanz und schnellere Adoption.
Die harte Wahrheit über Finance Automation mit autonomen Agenten lautet: Governance entscheidet über Erfolg oder Misserfolg. Punkt.
In regulierten Finanzunternehmen ist Nachvollziehbarkeit keine nette Eigenschaft, sie ist gesetzliche Pflicht. Jede Buchung, jede Kostenkategorisierung, jeder Report muss einem Prüfer erklärbar sein. Das bedeutet: Agenten-Aktionen müssen lückenlos geloggt werden, Prompt-Versionen und Policies müssen versioniert sein, Human-Override-Mechanismen müssen jederzeit greifen, und für kritische Schritte wie Zahlungsfreigaben oder Jahresabschlussbuchungen muss das Vier-Augen-Prinzip technisch erzwungen sein.
Analysen zu Agentic AI in Financial Services zeigen, dass Banken und Finanzdienstleister beim Thema Governance nicht auf spätere Phasen warten. Sie bauen Kontrollschichten von Anfang an ein – oder sie deployen nicht. Das ist kein Vorsichtspessimismus, das ist professionelles Risikomanagement. Wer glaubt, Governance sei ein bürokratisches Hindernis auf dem Weg zur Finance Automation, hat in Finance noch nie einen Auditprozess erlebt.
Konkret bedeutet das für ein Deployment: Identity and Access Management für Agenten (welcher Agent darf auf welches System zugreifen?), automatisches Monitoring auf Anomalien in Agenten-Outputs, klare Eskalationspfade und regelmäßige Reviews der Agenten-Performance durch das Finance-Team. Kein einzelnes Element davon ist optional.
Autonome Agenten kommen nicht als Standalone-Lösung. Sie kommen als Schicht über bestehenden Systemen. ERP-Anbindung, Zugänge zum Treasury-Management-System, APIs zu BI- und Reporting-Plattformen, Lese- und manchmal Schreibrechte auf Datenbanken – das alles muss sauber definiert und gesichert sein, bevor der erste Agent produktiv läuft.
Typisch in Enterprise-Deployments: Ein LLM-basierter Agenten-Layer sitzt über einem Data Warehouse oder Data Lake, greift via API auf strukturierte Finanzdaten zu und gibt Ergebnisse strukturiert an Downstream-Systeme zurück. Fein abgestufte Zugriffsrechte sind dabei keine Kür, sie sind Standard. Ein Agent, der mehr sehen kann als er darf, ist ein Compliance-Risiko. Ein Agent, der weniger sehen kann als er für seinen Task braucht, ist wertlos.
Salesforce Agentforce zeigt im Backoffice-Kontext, wie eng Integration und Governance zusammenhängen müssen – ähnliche Muster gelten für Finance-Deployments. Und Open-Source-Frameworks wie LangChain oder LlamaIndex demonstrieren, wie orchestrierte Agenten-Stacks architektonisch aussehen können, wenn man volle Kontrolle über die Implementierung behalten will. Beide Ansätze haben ihre Berechtigung, je nach vorhandener Infrastruktur und IT-Kapazität.
Die Kritik an Finance Automation mit autonomen Agenten verdient mehr als eine Fußnote. Wer skeptisch bleibt, hat oft gute Gründe – und diese Gründe sollten jedes Deployment-Vorhaben informieren, nicht blockieren.
Das stärkste Gegenargument betrifft die Fehleranfälligkeit von LLMs bei numerischen Aufgaben. Sprachmodelle sind nicht primär für mathematische Präzision optimiert. In Finance-Kontexten, wo ein Dezimalstellenfehler erhebliche Folgen haben kann, ist blinder Verlass auf LLM-generierte Zahlen ein Risiko. Die Antwort darauf ist nicht, keine Agenten einzusetzen – sondern Validierungsschichten einzubauen, die Agenten-Outputs gegen Quelldaten und Plausibilitätsprüfungen abgleichen, bevor sie in Buchungssysteme fließen.
Ein weiteres berechtigtes Gegenargument: Vendor-Lock-in. Wer Finance-Automation auf einem proprietären Agenten-Framework aufbaut, macht sich abhängig von Pricing-Entscheidungen, Modell-Updates und API-Änderungen eines einzelnen Anbieters. Die Reaktion darauf ist Architektur-Disziplin: Abstraktionsschichten, die Modell-Wechsel ermöglichen, und klare vertragliche Regelungen zur Datenhaltung und Portabilität.
Schließlich: der Einwand, dass Automatisierung implizites Wissen vernichtet. Wenn ein Agent einen Prozess übernimmt, den bisher eine erfahrene Mitarbeiterin durchgeführt hat, geht das in ihr Kopf gespeicherte Kontextwissen verloren – Lieferantenhistorien, gewachsene Ausnahmeregelungen, situatives Urteilsvermögen. Gegenmaßnahme: Explizite Knowledge-Capture-Phase vor dem Deployment, bei der genau dieses implizite Wissen dokumentiert und in Agent-Policies oder System-Prompts überführt wird.
Hier kommt meine klare Meinung: Der beste Zeitpunkt für Finance-Teams, mit autonomen Agenten zu starten, war vor einem Jahr. Der zweitbeste ist jetzt. Aber mit Verstand, nicht mit Euphorie.
Schritt eins: Use-Case-Identifikation mit Business-Owner und messbarem Nutzen. Nicht „wir wollen AI im Finance“, sondern „wir verarbeiten 1.500 Eingangsrechnungen pro Monat, davon 80 Prozent von bekannten Lieferanten, und wollen die manuelle Kontierungszeit um 60 Prozent senken“. Konkreter Prozess. Messbare KPI. Klarer Owner.
Schritt zwei: Risiko-Assessment vor dem Piloten. Welche regulatorischen Anforderungen gelten für diesen Prozess? Welche Fehlertypen sind akzeptabel, welche nicht? Was passiert, wenn der Agent einen Fehler macht – wie schnell wird er erkannt, wie wird er korrigiert?
Schritt drei: Pilotendesign mit Human-in-the-Loop. Kein Vollautomations-Deployment im ersten Durchlauf. Der Agent schlägt vor, der Mensch bestätigt – mit vollem Logging. Erst nach Validierung der Fehlerquote kommt schrittweise mehr Autonomie. Iteratives Rollout ist nicht Schwäche, es ist professionelle Delivery.
Schritt vier: Daten- und IT-Voraussetzungen schaffen. Gut strukturierte Finanzdaten, saubere APIs, funktionierende Zugriffskontrollen. Wer hier spart, zahlt später doppelt – entweder in Debugging-Zeit oder in einem Audit-Vorfall.
Schritt fünf: Erfolgsmessung von Anfang an definieren. Welche Baseline-KPIs gelten vor dem Deployment – Durchlaufzeit, Fehlerquote, manuelle Eingriffe pro Prozess? Ohne Baseline kein belastbarer Nachweis des Nutzens. Und ohne belastbaren Nutzungsnachweis wird das nächste Budget-Gespräch schwierig.
Finance Automation mit autonomen Agenten ist real. Sie ist wirksam. Sie ist auch deutlich komplexer als jede McKinsey-Folie und jede Goldman-Sachs-Headline vermuten lässt. Die Technologie ist bereit für eingegrenzte, gut definierte Backoffice-Prozesse – mit Governance, mit Integration, mit Human-in-the-Loop. Vollautonomie im Finance ohne menschliche Kontrolle? Weder regulatorisch akzeptabel noch technisch empfehlenswert.
Was sich gerade verändert, ist trotzdem substanziell: Finance-Teams werden sich von Datenbeschaffer-Rollen hin zu Entscheidungspartnern verschieben. Neue Rollen entstehen – nicht im Sinne von PR-Prosa, sondern weil jemand die Agenten steuern, überwachen und kontinuierlich verbessern muss. Das ist auch eine Chance.
Die entscheidende Frage für jeden CFO und jeden Finance-Leiter lautet: Welchen Prozess in Ihrem Backoffice könnten Sie morgen als Piloten starten – und haben Sie die Governance-Strukturen, um ihn sicher zu deployen?
