Jahresabschluss.io
ENAnmeldenRegistrieren →

OpenAI Assistants anbinden

OpenAI Assistants API an die Buchhaltung anbinden

Function Calling von OpenAI macht ein Sprachmodell zum Steuerpult Ihrer Buchhaltung: Jede Function bildet genau einen REST-Endpunkt ab, das Modell schlägt den passenden Aufruf mit Argumenten vor, und Ihr eigener Code führt ihn mit dem Bearer-Schlüssel aus. Die Assistants API hat OpenAI am 26. August 2026 abgeschaltet; dasselbe Prinzip läuft heute über die Responses API oder Chat Completions. Das Modell ist dabei Ihr Werkzeug — es läuft in Ihrem eigenen OpenAI-Konto und ist kein Bestandteil unserer Software. Wir liefern ausschließlich die offene REST-API mit festen Endpunkten, Scopes und GoBD-Sicherheit, gegen die Ihre Functions arbeiten.

Was Function Calling hier bedeutet

Wichtig vorab: OpenAI hat die Assistants API am 26. August 2026 abgeschaltet; Function Calling läuft heute über die Responses API oder Chat Completions. Das Prinzip bleibt gleich: Das Modell schlägt vor, Ihr Code führt aus — und Ihr Schlüssel verlässt nie das Haus.

Der Assistant schlägt vor, Ihr Code führt aus

Das Modell entscheidet nur, WELCHE Function mit welchen Argumenten aufgerufen werden soll. Den eigentlichen HTTP-Aufruf gegen unsere REST-API führt Ihr eigener Code aus. Dort — und nur dort — liegt der Bearer-Schlüssel.

Jede Function = ein fester Endpunkt

Sie definieren pro Function ein JSON-Schema, das exakt einem Endpunkt entspricht: saldenliste_abrufen, buchung_anlegen, offene_posten_lesen. Es gibt keine freie SQL-Ebene und keine improvisierten Pfade — der Assistant kann nur das, was ein Endpunkt erlaubt.

Der Agent ist Ihr Werkzeug

Der Assistant gehört Ihnen und läuft in Ihrer eigenen OpenAI-Umgebung. Er ist kein Teil unserer Software; wir stellen nur die Endpunkte, die Scopes und die Prüfungen bereit. Sie könnten dieselbe API genauso an Claude, Cursor oder n8n hängen.

Functions definieren — jede bildet einen Endpunkt ab

Eine Function-Definition ist reines JSON-Schema. Auffällig: Es gibt keinen Firmen-Parameter. Die Gesellschaft wird serverseitig aus dem Schlüssel abgeleitet, ein Schlüssel gehört zu genau einer Firma. So kann der Assistant nie versehentlich die falsche Gesellschaft ansprechen.

{
  "type": "function",
  "function": {
    "name": "saldenliste_abrufen",
    "description": "Liest die Saldenliste eines Geschäftsjahres der Firma.",
    "parameters": {
      "type": "object",
      "properties": {
        "fiscal_year_id": { "type": "string", "description": "UUID des Geschäftsjahres aus GET /fiscal-years" }
      },
      "required": ["fiscal_year_id"]
    }
  }
}

// Ausführung in Ihrem eigenen Code (Schlüssel bleibt hier):
// GET /saldenliste?fiscal_year_id=...
// Authorization: Bearer jab_live_...

Der Ablauf: Aufruf vorschlagen, ausführen, Ergebnis zurückgeben

Bis zur Abschaltung folgte der Ablauf dem Standard der Assistants API: Sie legten einen Thread an, hängten die Nutzerfrage als Nachricht an und starteten einen Run mit Ihren Functions als Werkzeugen. Brauchte der Assistant Zahlen aus der Buchhaltung, wechselte der Run in den Status requires_action und lieferte tool_calls mit Function-Namen und Argumenten. In der Responses API heißen die Bausteine function_call und function_call_output; Ihr Code bleibt derselbe Vermittler.

Dann ist Ihr Code am Zug: Er liest den Aufruf saldenliste_abrufen, ruft den zugehörigen REST-Endpunkt mit dem Bearer-Schlüssel auf und gibt das Ergebnis an das Modell zurück — in der Assistants API hieß das submit_tool_outputs, in der Responses API ist es ein function_call_output. Kommen mehrere Aufrufe auf einmal, sammeln Sie alle Antworten und übergeben sie gebündelt. An OpenAI gehen dabei nur das JSON-Schema Ihrer Functions und die von Ihnen zurückgegebenen Ergebnisse — der Schlüssel selbst wird nie übertragen.

Weil jeder Aufruf synchron durch Ihren eigenen Code läuft, behalten Sie die volle Kontrolle: Sie können schreibende Aufrufe vor dem Absenden manuell bestätigen lassen, jeden Endpunktaufruf protokollieren oder ihn auf bestimmte Konten und Zeiträume begrenzen, bevor das Modell seine Antwort mit den echten Zahlen fortsetzt.

Werkzeuge sauber auf Functions abbilden

Die Buchhaltung stellt 91 Werkzeuge bereit — 43 lesende, 45 schreibende, je eines für Rechnungsversand und Festschreibung sowie eines für die Übermittlung an ELSTER, dessen Recht derzeit noch nicht vergeben wird. Sie definieren so viele Functions, wie Ihr Anwendungsfall braucht.

  • Lesend: Stammdaten, Saldenliste, Buchungsjournal, offene Posten, Ausgangs- und Eingangsrechnungen, Zahlungen, Belege, Bankumsätze, Kontenrahmen, Anlagen und die Kennzahlen der Umsatzsteuer-Voranmeldung.
  • Schreibend: Buchung anlegen und stornieren, Ausgangsrechnung erstellen, Eingangsrechnung, Zahlung und Beleg buchen, Bankumsatz zuordnen, dazu Kasse, Anlagen, Rückstellungen, Abgrenzungen und Stammdaten.
  • Nur lesen gewünscht? Definieren Sie ausschließlich lesende Functions und vergeben Sie einen Schlüssel ohne write-Scope — der Assistant kann dann strukturell nichts verändern.
  • Jede Function trägt eine klare Beschreibung, damit der Assistant den richtigen Endpunkt trifft, statt einen Aufruf zu improvisieren.

Sicherheit: Scopes, ein Schlüssel je Firma, GoBD

Scopes statt Vertrauen

Der Schlüssel trägt read- oder write-Scope. Ein reiner Lese-Schlüssel lässt schreibende Endpunkte serverseitig abweisen — unabhängig davon, was der Assistant vorschlägt. So können Sie erst read-only testen, bevor Sie Schreibrechte freigeben.

Ein Schlüssel = eine Firma

Der Schlüssel beginnt mit jab_live_ und ist genau einer Gesellschaft zugeordnet. Die Firma ist kein Function-Parameter, sondern wird aus dem Schlüssel abgeleitet. Ein Assistant kann damit prinzipiell nicht in die Bücher einer anderen Mandantin schreiben.

GoBD bleibt erzwungen

Schreibende Aufrufe laufen durch denselben Buchungskern wie die App: append-only, Festschreibung, Soll gleich Haben, Storno statt Löschen. Ein Assistant kann keine Buchung entfernen — nur eine korrekte Stornierung erzeugen. Das gilt serverseitig, egal welcher Client anfragt.

Function Calling oder MCP-Server?

Function Calling gegen die REST-API bleibt der native Weg — seit der Abschaltung der Assistants API über die Responses API oder Chat Completions: Sie definieren die Functions, führen die Aufrufe in Ihrem eigenen Code aus und behalten den Schlüssel dort. Das ist maximal transparent.

Alternativ gibt es unseren MCP-Server, der dieselben Werkzeuge als Adapter über die gleiche REST-API bereitstellt — sinnvoll für MCP-native Clients wie Claude Code, Claude Desktop oder Codex. Angebunden wird er über die gehostete URL. Für eine Anbindung mit eigenem Code bleiben Sie am besten bei REST plus Function Calling.

Häufige Fragen

Muss ich meinen API-Schlüssel an den Assistant geben?

Nein. Der Bearer-Schlüssel liegt ausschließlich in Ihrem eigenen Code, der die Function ausführt. An OpenAI gehen nur die JSON-Schemata Ihrer Functions und die Ergebnisse, die Sie zurückgeben. Der Schlüssel selbst wird nie an das Modell oder in einen Prompt übertragen.

Kann der Assistant über die API einen Jahresabschluss oder eine E-Bilanz erstellen?

Nein. Der Assistant kann Belege buchen, Salden und offene Posten lesen oder Rechnungen erstellen — also die Zahlen vorbereiten. Jahresabschluss und E-Bilanz entstehen in der App, mit Ihrer Freigabe; Steuermeldungen kann er über die API amtlich prüfen und vorbereiten, übermittelt wird über den Freigabe-Link in der App.

Wie viele Functions muss ich definieren?

So viele, wie Ihr Anwendungsfall braucht; mehr als die Endpunkte der API gibt es nicht. Für eine reine Auswertungs-Assistenz genügen die lesenden Functions. Jede Function bildet genau einen festen REST-Endpunkt ab; freie Datenbankzugriffe gibt es bewusst nicht.

Wie stelle ich sicher, dass der Assistant nichts löscht?

Löschen ist gar nicht vorgesehen. Der Buchungskern erzwingt GoBD-Regeln: append-only, Festschreibung, Soll gleich Haben und Storno statt Löschen. Eine falsche Buchung wird also nur durch eine ordentliche Stornobuchung ausgeglichen. Zusätzlich können Sie einen Schlüssel ohne write-Scope vergeben, dann werden schreibende Endpunkte serverseitig komplett abgewiesen.

Woher weiß die API, für welche Firma gebucht werden soll?

Aus dem Schlüssel. Jeder jab_live_-Schlüssel gehört zu genau einer Gesellschaft. Die Firma ist deshalb kein Parameter in Ihren Function-Schemata — das Modell kann sie weder setzen noch verwechseln. Für mehrere Mandanten legen Sie mehrere Schlüssel an und wählen in Ihrem Code den passenden.

Ist der Assistant Teil Ihrer Software?

Nein. Der Assistant ist Ihr eigenes Werkzeug und läuft in Ihrem OpenAI-Konto. Wir stellen ausschließlich die offene REST-API mit festen Endpunkten, Scopes und GoBD-Sicherheit bereit. Sie könnten dieselbe API genauso gut an einen anderen KI-Agenten anbinden — die Buchhaltung bleibt unverändert.

Vom selben Anbieter: Jahresabschluss nach HGB – der komplette Leitfaden auf jahresabschluss.io.