Geplante KI-Agenten: Buchhaltungsaufgaben automatisch jede Woche und jeden Monat

Welche Aufgaben sich für einen Zeitplan eignen

Claude Code ohne Oberfläche

Ein Ordner mit .mcp.json, einer Auftragsdatei und einem kleinen Skript genügt. Ein Lauf mit -p verbindet die Server aus der .mcp.json ohne Rückfrage; die Regeln geben nur die lesenden Werkzeuge frei:

# ~/buchhaltung-agent/.mcp.json
{
  "mcpServers": {
    "buchhaltung": {
      "type": "http",
      "url": "https://api.jahresabschluss.io/functions/v1/bookkeeping-mcp",
      "headers": { "Authorization": "Bearer ${JAB_API_KEY}" }
    }
  }
}

# ~/buchhaltung-agent/monatsbericht.sh
set -euo pipefail
cd "$HOME/buchhaltung-agent"
export JAB_API_KEY="$(cat "$HOME/.config/jab/lesen.key")"   # jab_live_… nur mit Leserecht
claude -p "$(cat auftraege/monatsbericht.md)" \
  --permission-mode dontAsk \
  --allowedTools "mcp__buchhaltung__list_*,mcp__buchhaltung__get_*" \
  --max-turns 40 \
  --output-format json > "berichte/$(date +%Y-%m).json"

# crontab -e: am 2. jedes Monats um 7 Uhr
0 7 2 * * bash $HOME/buchhaltung-agent/monatsbericht.sh

• --permission-mode dontAsk lehnt jeden Aufruf ab, der sonst eine Rückfrage auslösen würde; erlaubt bleibt, was --allowedTools freigibt.
• Regeln wie mcp__buchhaltung__list_* geben alle Werkzeuge eines Servers frei, deren Name so beginnt — hier also nur lesende.
• --output-format json legt Ergebnis, Sitzungskennung und eine geschätzte Kostenangabe ab; --max-turns begrenzt die Schritte eines Laufs.
• Mit --bare startet Claude Code ohne .mcp.json, Hooks und CLAUDE.md; dann übergeben Sie den Server mit --mcp-config und schließen andere mit --strict-mcp-config aus.
• Für unbeaufsichtigte Läufe beschreibt die Claude-Code-Dokumentation claude setup-token, das ein langlebiges Token für Skripte und CI erzeugt.

Codex mit codex exec

Codex liest seine MCP-Server aus ~/.codex/config.toml. Mit enabled_tools sieht das Modell nur die Werkzeuge, die der Bericht braucht:

# ~/.codex/config.toml
[mcp_servers.buchhaltung]
url = "https://api.jahresabschluss.io/functions/v1/bookkeeping-mcp"
bearer_token_env_var = "JAB_API_KEY"
enabled_tools = ["list_open_items", "list_bank_transactions", "list_receipts", "list_tax_deadlines", "get_saldenliste", "list_fiscal_years"]

# Lauf, z. B. aus cron
codex exec --skip-git-repo-check --ephemeral \
  -o "berichte/woche-$(date +%G-%V).md" "$(cat auftraege/wochenbericht.md)"

codex exec läuft standardmäßig in einer eigenen Ausführungs-Sandbox von Codex, die nur lesen darf — sie begrenzt, was Codex auf Ihrem Rechner tun darf. Fortschritt schreibt der Lauf auf stderr, die letzte Antwort auf stdout; -o legt sie zusätzlich in einer Datei ab, --ephemeral speichert keine Sitzungsdateien. Ohne Git-Ordner braucht der Lauf --skip-git-repo-check. Wie Codex in diesem Modus mit Freigaben für MCP-Werkzeuge umgeht, beschreibt die Dokumentation nicht — prüfen Sie deshalb den ersten Lauf von Hand, bevor Sie ihn planen. Ein Schlüssel nur mit Leserecht macht die Frage für Berichte ohnehin gegenstandslos.

Der Auslöser: cron, GitHub Actions oder n8n

• cron auf einem eigenen Rechner oder Server ist der einfachste Weg; der Schlüssel liegt dort in einer Datei, die nur Ihr Benutzer lesen darf.
• GitHub Actions plant mit on.schedule und Cron-Syntax. Standard ist UTC, mit timezone wählen Sie zum Beispiel Europe/Berlin. Das kürzeste Intervall sind 5 Minuten, zu Stundenbeginn kann es Verzögerungen geben, und in öffentlichen Repositorys werden geplante Abläufe nach 60 Tagen ohne Aktivität abgeschaltet. Für Codex empfiehlt OpenAI in Abläufen die Codex-GitHub-Action (openai/codex-action) statt einer selbst installierten Kommandozeile.
• n8n startet einen Ablauf mit dem Zeitplan-Auslöser (Schedule Trigger) in Minuten, Stunden, Tagen, Wochen, Monaten oder per Cron-Ausdruck. Der Ablauf muss gespeichert und veröffentlicht sein; die Uhrzeit folgt der Zeitzone des Ablaufs oder der Instanz.
• Nicht jeder geplante Lauf braucht ein Modell: Eine Liste überfälliger Posten liefert schon ein einzelner REST-Aufruf. Das Modell lohnt sich, wo bewertet, verglichen oder formuliert werden muss.

# .github/workflows/wochenbericht.yml
name: Wochenbericht Buchhaltung
on:
  schedule:
    - cron: '0 7 * * 1'
      timezone: "Europe/Berlin"
  workflow_dispatch:
jobs:
  bericht:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Überfällige Forderungen lesen (ohne Modell)
        env:
          JAB_API_KEY: ${{ secrets.JAB_API_KEY }}
        run: |
          curl -sf -H "Authorization: Bearer $JAB_API_KEY" \
            "https://api.jahresabschluss.io/functions/v1/bookkeeping-api/v1/open-items?kind=debitor&status=overdue" \
            -o ueberfaellig.json
          ./scripts/wochenbericht.sh ueberfaellig.json

Schreiben nur mit Bestätigung

Ein geplanter Lauf ist niemand, der zurückfragen kann. Deshalb trennen Sie Vorschlag und Ausführung: Der planmäßige Lauf mit Leseschlüssel legt eine Vorschlagsdatei ab — etwa die Zuordnung offener Bankumsätze zu Rechnungen samt neuer UUIDs als idempotency_key. Sie lesen die Datei, streichen, was nicht passt, und starten dann einen zweiten, beaufsichtigten Lauf mit Schreibschlüssel, der genau diese Zeilen ausführt.

Wo ein schreibendes Werkzeug einen Probelauf kennt (dry_run, etwa bei book_incoming_invoice, import_journal_batch und den Zahlungswerkzeugen), gehört er in den Vorschlag: Die Antwort nennt die Buchungszeilen, ihre Wirkung auf die Konten und auf die Kennzahlen der Voranmeldung. Der idempotency_key wird beim Probelauf nicht gespeichert, die Ausführung kann ihn also wiederverwenden — und eine versehentliche Wiederholung erzeugt keinen zweiten Vorgang.

Protokoll und Nachvollziehbarkeit

• Bewahren Sie jede Ausgabe auf — die JSON-Datei von claude -p oder die Antwortdatei von codex exec, dazu die Auftragsdatei in der Fassung, mit der der Lauf startete.
• In der App zeigt „KI-Agent & API“ die API-Nutzung der letzten 30 Tage je Schlüssel: Zahl der Aufrufe, davon schreibende und fehlerhafte, den letzten Aufruf und die häufigsten Endpunkte. Ein eigener Schlüssel je geplantem Lauf macht dort sichtbar, welcher Lauf wie oft und ob er geschrieben hat; was im Einzelnen gebucht wurde, steht im Journal.
• Buchungen bleiben im Journal unveränderbar; Korrekturen entstehen als Storno und Neubuchung. Das entspricht § 146 Abs. 4 AO: Eine Buchung darf nicht so verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist.
• Für die Verfahrensdokumentation halten Sie fest, welcher Lauf wann mit welchen Rechten läuft und wer seine Vorschläge freigibt.

Grenzen

• Übermittlungen an das Finanzamt gehören in keinen Zeitplan: Ein vorbereiteter Vorgang ist 30 Minuten gültig, der Freigabe-Link 7 Tage, und übermittelt wird in der App mit Ihrer PIN.
• Festschreiben (finalize) und Rechnungsversand (send) bleiben beaufsichtigten Läufen vorbehalten.
• Schlüssel laufen spätestens nach 366 Tagen ab. Notieren Sie das Ablaufdatum, damit ein geplanter Lauf nicht unbemerkt mit 401 endet.
• Je Schlüssel gelten 120 Anfragen pro Minute; bei 429 wartet ein Lauf die in Retry-After genannte Zeit ab.
• Bankabrufe und neue Belege kommen über die Anbindungen der App, nicht über den geplanten Agenten.

Häufige Fragen

Kann ein KI-Agent meine Buchhaltung jeden Monat automatisch erledigen?

Er kann jeden Monat automatisch prüfen, zusammenfassen und Vorschläge ablegen. Gebucht wird am besten in einem zweiten, beaufsichtigten Schritt, nachdem Sie die Vorschläge bestätigt haben.

Welchen Schlüssel braucht ein geplanter Bericht?

Einen Schlüssel nur mit Leserecht. Der Buchhaltungs-Server meldet diesem Schlüssel keine schreibenden Werkzeuge, ein geplanter Bericht kann also nichts buchen.

Wie starte ich Claude Code ohne Oberfläche?

Mit claude -p und dem Auftrag als Text. Mit --allowedTools geben Sie die erlaubten Werkzeuge frei, mit --permission-mode dontAsk werden alle übrigen abgelehnt statt nachgefragt.

Läuft codex exec ohne Rückfragen?

codex exec arbeitet standardmäßig in einer Ausführungs-Sandbox von Codex, die nur lesen darf. Wie Freigaben für MCP-Werkzeuge in diesem Modus behandelt werden, beschreibt die Dokumentation nicht; prüfen Sie den ersten Lauf von Hand.

In welcher Zeitzone laufen geplante GitHub-Abläufe?

Standardmäßig in UTC. Mit dem Schlüssel timezone im schedule-Eintrag legen Sie eine IANA-Zeitzone wie Europe/Berlin fest.

Was passiert, wenn der Schlüssel abläuft?

Die API weist Anfragen dann ab. Legen Sie rechtzeitig einen neuen Schlüssel an und tauschen Sie ihn in der Umgebung des Laufs aus.