Nachvollziehbarkeit: was ein KI-Agent gebucht hat und wo es steht

Die API-Nutzung im Bereich „KI-Agent & API“

• Zahl der Aufrufe der letzten 30 Tage (exakt gezählt) und Zeitpunkt des letzten Aufrufs.
• Häufigste Endpunkte, also die meistgenutzten Pfade; bei sehr vielen Aufrufen ausgewertet aus den 2.000 jüngsten.
• Je Schlüssel: Aufrufe, davon schreibende, davon mit Fehler, und wann er zuletzt genutzt wurde. Über eine Auswahl grenzen Sie die Ansicht auf einen Schlüssel ein.
• In der Schlüsselliste: Bezeichnung, Präfix, Rechte, „Zuletzt genutzt“ und Status (aktiv bis, läuft bald ab, abgelaufen, widerrufen).

Gespeichert wird je angenommenem Aufruf, welcher Schlüssel ihn gestellt hat, Methode, Pfad, Statuscode und Zeitpunkt; die Seite fasst diese Einträge je Schlüssel zusammen. Zu erfolgreichen Schreibaufrufen hält die Software außerdem die Kennungen der Objekte fest, die die Antwort nennt – angezeigt werden sie in der App derzeit nicht; was angelegt wurde, sehen Sie im Journal. Geben Sie deshalb jedem Agenten einen eigenen Schlüssel mit sprechender Bezeichnung: Dann zeigt die Nutzung je Schlüssel, welcher Agent was getan hat.

Wie ein Werkzeugaufruf im Protokoll erscheint

Der MCP-Server ruft für jedes Werkzeug die REST-API mit Ihrem Schlüssel auf. Im Protokoll steht deshalb der Pfad dieser Route, zum Beispiel:

create_journal_entry      → POST /journal-entries
storno_journal_entry      → POST /journal-entries/{id}/storno
import_journal_batch      → POST /journal-entries/batch
book_bank_transaction     → POST /bank-transactions/{id}/book
confirm_receipt           → POST /receipts/{id}/confirm
send_outgoing_invoice     → POST /outgoing-invoices/{id}/send
prepare_tax_filing        → POST /tax/operations
list_journal_entries      → GET  /journal-entries

Werkzeuge, die nur einen Download-Weg nennen – etwa export_bookkeeping für Buchungsstapel aus Kanzlei Software und das GoBD-Paket oder download_annual_report –, rufen die API dabei nicht auf; im Protokoll erscheint erst der Download selbst, den Sie mit dem Schlüssel ausführen.

Im Journal: Nummer, Herkunft, Storno

list_journal_entries und get_journal_entry liefern zu jeder Buchung die Felder, an denen Sie ihre Geschichte ablesen:

• entry_no: die Buchungsnummer, lückenlos je Gesellschaft. Mit since_entry_no holen Sie nur Buchungen nach der zuletzt geprüften Nummer.
• source_type: die Herkunft, etwa manual (Einzelbuchung), receipt (aus einem Beleg), bank_tx (Bankumsatz) oder csv_import (Stapel, auch per API).
• stapel_id für Buchungen aus einem Stapel, reverses_entry_id für Stornobuchungen mit Verweis auf das Original, is_finalized für festgeschriebene Buchungen, created_at, Belegnummer (belegfeld1) und verknüpfter Beleg.

Buchungen über die API entstehen im Namen des Schlüssel-Inhabers. Über die Buchungsfelder einschließlich Ersteller und Zeitpunkt führt die Software je Gesellschaft eine Hash-Kette, in der jede Buchung den Wert ihrer Vorgängerin enthält – eine nachträgliche Änderung wäre erkennbar.

Beispiel: nur das Neue seit der letzten Durchsicht

Ein Auftrag im Chat: „Was hat der Import-Agent seit Buchung 2310 gebucht?“ Der Agent ruft auf:

{ "name": "list_journal_entries",
  "arguments": { "since_entry_no": 2310, "source_type": "csv_import", "limit": 200 } }

Die Antwort enthält nur Stapelbuchungen mit höherer Nummer, nach Buchungsnummer aufsteigend. Mit list_journal_batches sieht der Agent die zugehörigen Stapel; ist ein Stapel falsch, storniert storno_journal_batch ihn nach Ihrer Bestätigung als Ganzes. Merken Sie sich die höchste geprüfte Nummer für die nächste Durchsicht.

Storno statt Löschen

• storno_journal_entry verlangt einen Stornogrund; die Gegenbuchung verweist auf die ursprüngliche Buchung.
• storno_journal_batch schreibt den Grund in jede Gegenbuchung des Stapels.
• cancel_incoming_invoice verlangt einen Grund, der im Protokoll steht; Ausgangsrechnungen werden mit einer Stornorechnung mit eigener Nummer zurückgenommen.
• dismiss_receipt und discard_receipt protokollieren ihre Begründung; ein verworfener Beleg bleibt mit Datei aufbewahrt. delete_receipt löscht nur Dokumente, die nie geprüft, verworfen, gebucht oder verknüpft wurden.
• ignore_bank_transaction hinterlegt den Grund am Bankumsatz; er erscheint in der App.

Das entspricht den GoBD: Korrektur- und Stornobuchungen müssen auf die ursprüngliche Buchung rückbeziehbar sein (Rz. 64), und eine Buchung darf nicht so verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist (§ 146 Abs. 4 AO).

Stammdaten, Steuern, Webhooks

• Geschäftspartner: get_business_partner liefert die Änderungshistorie – welches Feld wann von welchem auf welchen Wert geändert wurde. Änderungen über die API stehen dort mit dem Schlüssel-Inhaber als Handelndem; auch IBAN und BIC, die nur in der App änderbar sind, werden historisiert.
• Konten: Änderungen mit upsert_account stehen in der Stammdaten-Historie. Die GoBD verlangen, dass auch eine Änderungshistorie nicht nachträglich veränderbar ist (Rz. 111).
• Steuern: list_tax_filings zeigt jede Meldung mit Status, Transferticket und Testmerker, gleich ob in der App oder über einen Freigabe-Link übermittelt; get_tax_operation zeigt einen vorbereiteten Vorgang mit Werten, Prüfwert und aktuellem Stand.
• Webhooks: Richtet ein Schlüssel ein neues Abonnement ein, erhält sein Inhaber eine E-Mail mit Zielserver und Ereignissen.

Grenzen des Protokolls

• Das Protokoll wird nebenher geschrieben und hält nie eine Antwort auf; fällt ein Eintrag aus, ist die Buchung trotzdem da – maßgeblich ist das Journal.
• Aufrufe ohne gültigen Schlüssel und Aufrufe, die schon an der Anfragegrenze scheitern, erscheinen nicht in der Nutzung eines Schlüssels.
• Gespeichert werden Pfade und Statuscodes, keine Beträge oder Inhalte der Anfragen; die stehen in den Buchungen selbst.
• Ihre Unterhaltung mit dem Agenten erreicht die Buchhaltung nicht. Warum etwas gebucht wurde, gehört deshalb in Buchungstext, Belegnummer oder Stornogrund.
• Die Seite zeigt die letzten 30 Tage. Für längere Nachweise halten Sie Ihre Durchsichten selbst fest.

Häufige Fragen

Sehe ich, welcher KI-Agent eine Buchung angelegt hat?

Indirekt: Die API-Nutzung zeigt je Schlüssel Aufrufe, schreibende Aufrufe und Fehler, und Buchungen über die API entstehen im Namen des Schlüssel-Inhabers. Geben Sie jedem Agenten einen eigenen Schlüssel mit sprechender Bezeichnung.

Kann ein Agent Buchungen löschen?

Nein. Es gibt keinen Weg, eine Buchung zu löschen oder zu überschreiben; korrigiert wird per Storno mit Verweis auf das Original. Löschen lassen sich nur Belege, die nie geprüft, verworfen, gebucht oder verknüpft wurden.

Wie lange sehe ich die API-Nutzung?

Die Seite im Bereich „KI-Agent & API“ zeigt die letzten 30 Tage, insgesamt oder je Schlüssel. Das Journal mit allen Buchungen bleibt unabhängig davon vollständig.

Werden fehlgeschlagene Aufrufe protokolliert?

Ja, mit ihrem Statuscode, sofern der Schlüssel gültig war; die Nutzung je Schlüssel zählt sie als Aufrufe mit Fehler. Aufrufe ohne gültigen Schlüssel erscheinen nicht.

Steht mein Prompt im Protokoll?

Nein. Die Buchhaltung erhält nur Werkzeugaufrufe; gespeichert werden Schlüssel, Methode, Pfad und Status. Der Chat bleibt in Ihrem KI-Programm.

Wie hole ich nur die neuen Buchungen eines Agenten?

Mit list_journal_entries und since_entry_no: Sie erhalten nur Buchungen mit höherer Buchungsnummer, auf Wunsch zusätzlich gefiltert nach Herkunft (source_type) oder Belegnummer (belegfeld1).