Function Calling (auch: Tool Use) bezeichnet den Mechanismus, der einem Large Language Model ermöglicht, externe Funktionen, APIs oder Code durch das Ausgeben einer strukturierten JSON-Anfrage aufzurufen. Die Host-Anwendung führt die Funktion aus und gibt das Ergebnis an das Modell zurück, wodurch aus einem Textgenerator ein Agent wird, der Systeme auslesen und reale Aktionen auslösen kann.
Function Calling, auch Tool Use genannt, versetzt ein Large Language Model in die Lage, externe Funktionen, APIs oder Codebausteine aufzurufen, statt nur Text zu erzeugen. Das Modell beantwortet eine Frage also nicht in Prosaform, sondern gibt ein strukturiertes JSON-Objekt aus, das die aufzurufende Funktion benennt und die zugehörigen Argumente festlegt. Die Host-Anwendung führt diese Funktion aus und liefert das Ergebnis an das Modell zurück. Anhand dieses Ergebnisses formuliert das Modell dann seine nächste Antwort oder entscheidet über den nächsten Schritt.
Genau diese Fähigkeit unterscheidet einen Chatbot von einem KI-nativen Agenten. Ein einzelnes LLM kann eine E-Mail zusammenfassen, eine Mahnung entwerfen oder einen Abzug erklären. Mit Function Calling schlägt dasselbe Modell den Kunden im ERP-System nach, ruft die Fälligkeitsanalyse ab, entwirft die Mahnung und terminiert einen Rückruf mit dem Kundenbetreuer. Für Finanzverantwortliche, die agentische KI für Debitorenbuchhaltung und O2C bewerten, ist Function Calling der architektonische Grundbaustein, der alles Weitere erst möglich macht.
Bei allen Anbietern läuft es nach demselben Muster ab. Zuerst meldet die Host-Anwendung dem Modell eine Reihe verfügbarer Tools. Jedes Tool hat einen Namen, eine Beschreibung seiner Funktion in natürlicher Sprache und ein JSON-Schema, das die Parameter festlegt. Zweitens stellt der Nutzer eine Anfrage. Drittens entscheidet das Modell, ob es direkt antwortet oder ein Tool aufruft. Wählt es ein Tool, gibt es ein strukturiertes tool_call-Objekt zurück. Dieses enthält den Funktionsnamen und die Argumente, die zum Schema passen.
Viertens führt die Host-Anwendung die Funktion aus, nicht das Modell. Das Modell greift selbst nie auf eine Datenbank zu und verschickt auch keine E-Mail. Die Host-Anwendung führt den Code aus, erfasst das Ergebnis und speist es als Tool-Ergebnisnachricht zurück in die Konversation. Fünftens liest das Modell dieses Ergebnis und formuliert entweder eine endgültige Antwort an den Nutzer oder löst einen weiteren Tool-Aufruf aus. Diese Schleife kann viele Aufrufe aneinanderreihen, und genau so entstehen mehrstufige agentische Workflows.
OpenAI führte Function Calling im Jahr 2023 ein und fasste das Konzept später unter dem Oberbegriff Tools zusammen. Anthropic bietet dieselbe Fähigkeit über die Claude-3-Familie und deren Nachfolger hinweg an und nennt sie Tool Use. Bei Google heißt die entsprechende Funktion in Gemini Function Declarations. Die Begriffe unterscheiden sich, doch dahinter steckt jeweils dasselbe Prinzip.
Rasant verändert sich vor allem die Ebene der Standardisierung oberhalb der einzelnen Anbieter-APIs. Das Model Context Protocol, kurz MCP, ist ein offener Standard. Damit stellen Sie Tools, Ressourcen und Prompts für jeden kompatiblen KI-Agenten bereit, unabhängig davon, welches Modell den Workflow steuert. Auch anbieterspezifische Agenten-Frameworks wie das OpenAI Agents SDK reifen zusehends. Für IT-Verantwortliche in Unternehmen heißt das konkret: Tools, die Sie heute für MCP entwickeln, lassen sich immer leichter über verschiedene Modellanbieter hinweg nutzen. Das senkt in einem schnelllebigen Markt das Risiko, sich an einen einzelnen Anbieter zu binden.
Function Calling macht einen Debitoren-Agenten überhaupt erst praktisch nutzbar. Ein Agent für den Zahlungsabgleich (Cash Application) verfügt zum Beispiel über Werkzeuge wie lookup_open_invoices(customer), match_payment(invoice_ids, amount) und post_to_gl(allocation). Das Modell erhält eine Zahlungsavis-Mail, ruft die Lookup-Funktion auf, wertet die offenen Posten aus, startet den Matcher und bucht die Zuordnung. Bei sauberen Treffern muss dabei kein Mensch mehr eingreifen.
Ein Agent für das Streitfallmanagement nutzt Werkzeuge wie get_invoice_history(customer), draft_response(dispute_id) und create_credit_memo(amount, reason), um Abzüge zu sichten und zu beantworten. Ein Agent für das Forderungsmanagement ruft get_aging(customer), send_dunning(template_id) und schedule_call(account_mgr) auf und arbeitet so die Mahnstufen ab. Ein Agent für die Cashflow-Prognose nutzt query_ar_ledger(filters), pull_payment_history(customer) und build_forecast(horizon), um eine 13-Wochen-Liquiditätsplanung bei Bedarf zu aktualisieren. In jedem Fall ist das Modell das Gehirn, die Werkzeuge sind seine Hände.
Der Weg von der Demo zum produktiven KI-Agenten im Forderungsmanagement bringt eine Reihe absehbarer technischer Herausforderungen mit sich. An erster Stelle steht ein sauberes Schema. Ist eine Tool-Beschreibung mehrdeutig, wählt das Modell das falsche Tool oder übergibt die falschen Argumente. Behandeln Sie Tool-Beschreibungen deshalb wie ernstzunehmende technische Dokumentation.
Idempotenz zählt bei jedem Tool, das den Zustand verändert. Netzwerkaussetzer und wiederholte Aufrufe lassen sich nicht vermeiden. Deshalb muss sich post_to_gl auch zweimal ausführen lassen, ohne die Buchung doppelt zu erfassen. Berechtigungen und Autorisierung sollten Sie pro Nutzer abgrenzen: Der Agent sieht nur die Tools, die der jeweilige Nutzer verwenden darf. Sonst wird er zum Einfallstor für eine unbefugte Rechteausweitung. Latenz und Kosten sind betriebliche Faktoren. Jeder Tool-Aufruf bedeutet einen zusätzlichen Roundtrip zum Modell und einen weiteren Schwung Tokens. Konzepte, die unnötige Aufrufe reduzieren, zahlen sich schnell aus.
In Finanzteams haben sich mehrere Sicherheitsmuster bewährt: Lesende Tools führen Sie automatisch aus, für schreibende Tools oberhalb eines Schwellenwerts verlangen Sie dagegen eine menschliche Freigabe. Finanzaktionen wie Gutschriften oder Rückerstattungen versehen Sie mit einem Rate-Limit. Jeden Tool-Aufruf protokollieren Sie mit Eingaben, Ausgaben und der Argumentationskette des Modells. Und für zerstörerische oder unumkehrbare Vorgänge bauen Sie einen expliziten Bestätigungsschritt ein. Häufige Fallstricke sind: dem Modell zu viele Tools auf einmal zu geben, vage Beschreibungen, fehlende Fehlerbehandlung bei Tool-Ausfällen und kein Schutz vor Endlosschleifen, in denen sich der Agent unendlich oft selbst aufruft.
Function Calling wird häufig mit Retrieval-Augmented Generation verwechselt, kurz RAG. Beide ergänzen sich, sind aber nicht austauschbar. RAG ist ein reines Lesemuster: Es speist dem Modell frisches, domänenspezifisches Wissen in das Kontextfenster ein und beantwortet die Frage Was weiß das Modell? Function Calling beantwortet eine andere Frage: Was kann das Modell tun?
Ein praxistauglicher Debitoren-Agent nutzt beides. RAG verankert das Modell in Ihrer Regelung zum Streitfallmanagement, Ihrem Mahn-Playbook und Ihren Kundenstammdaten. Function Calling versetzt dasselbe Modell in die Lage, auf diesem Wissen zu handeln: Es fragt aktuelle Salden ab, bucht Zuordnungen und versendet E-Mails. Betrachten Sie den Abruf als Bibliothek und Function Calling als Werkstatt. Zusammen machen sie aus einem generischen LLM ein agentisches System, das Aufgaben tatsächlich durch die Prozesse des Zahlungsabgleichs, des Abzugsmanagements und des Forderungsmanagements bewegt.
Ja. OpenAI spricht von Function Calling, Anthropic bei Claude von Tool Use und Google bei Gemini von Function Declarations. Das Prinzip dahinter ist bei allen drei Anbietern identisch: Das Modell gibt strukturiertes JSON aus, das eine aufzurufende Funktion beschreibt, und die Host-Anwendung führt sie aus.
Nein. Das Modell erzeugt lediglich eine strukturierte Anfrage. Die Host-Anwendung führt die Funktion gegen Ihre Datenbanken, APIs oder Dienste aus und gibt das Ergebnis an das Modell zurück. Genau diese Trennung erlaubt es Ihnen, Berechtigungen durchzusetzen, Audit-Logs zu führen und Freigabe-Workflows einzuziehen.
RAG liest nur: Es speist relevante Dokumente in den Kontext des Modells ein, damit es mit aktuellem Wissen antwortet. Function Calling dient dem Handeln, etwa ein Live-System abzufragen, einen Datensatz zu schreiben oder eine Nachricht zu versenden. Produktive Debitoren-Agenten nutzen in der Regel beides: RAG liefert den Richtlinienkontext, Function Calling erledigt die eigentliche Arbeit.
Agenten für den Zahlungsabgleich, die offene Rechnungen nachschlagen und Zuordnungen buchen; Agenten für das Streitfallmanagement, die die Rechnungshistorie abrufen und Gutschriften erstellen; Agenten für das Forderungsmanagement, die Fälligkeitsanalysen ziehen und Mahnläufe auslösen; sowie Agenten für die Prognose, die 13-Wochen-Liquiditätsplanungen aus aktuellen Buchhaltungsdaten aktualisieren.
Mehrdeutige Tool-Beschreibungen, die zur falschen Auswahl führen; nicht-idempotente Schreib-Tools, die bei einem erneuten Versuch doppelt buchen; zu weit gefasste Berechtigungen, die den Agenten zum Einfallstor für Rechteausweitung machen; fehlende Audit-Logs; und keine menschliche Freigabestufe für unumkehrbare Finanzvorgänge wie hohe Gutschriften oder Rückerstattungen.
Weniger, als Sie vielleicht denken. Das Model Context Protocol (MCP) entwickelt sich zu einem offenen Standard, um Tools für jeden kompatiblen Agenten bereitzustellen, und die meisten Enterprise-Plattformen für die Debitorenbuchhaltung abstrahieren die Anbieterebene. Konzipieren Sie Ihre Tools als sauber beschriebene, idempotente Dienste, dann lassen sie sich mit geringem Anpassungsaufwand zwischen OpenAI, Anthropic und Google portieren.
