Genehmigungs- und Prüfprozesse mit KI-Agenten: Architektur eines realen Falls

Ein KI-Agent für Genehmigungsprozesse sammelt Belege und Stammdaten, prüft Abweichungen und formuliert eine begründete Empfehlung. Der Mensch entscheidet. Unser Referenzfall ist die Eingangsrechnungs-Vorprüfung gegen Bestellung und Rahmenvertrag: Der Agent vergleicht Betrag, Mengen, Zahlungsziel, Skonto und Lieferantenfreigabe, markiert Abweichungen und legt einen Freigabe-Vorschlag vor. Kein autonomes Buchen. Typischer Festpreis bei Nentix als Entwicklungspartner: 8.000 bis 14.000 Euro für die erste produktive Version, Betrieb ab 800 Euro monatlich auf IONOS in Deutschland. Erfolg messen Sie an weniger Rückfragen (Ziel 30 bis 50 Prozent in 90 Tagen) und kürzerer Durchlaufzeit bis zur Freigabe.

Was soll der Agent leisten, was nicht?

Ja:

• Daten aus ERP, DMS und E-Rechnung zusammenführen
• Abweichungen strukturiert listen
• Natürlichsprachliche Begründung für Sachbearbeiter
• Vorschlag: freigeben, klären, ablehnen

Nein:

• Buchung in DATEV oder lexoffice
• Freigabe ohne menschlichen Klick
• Verhandlung mit Lieferanten

Das entspricht dem reifen Einsatzfall aus KI-Agenten im Mittelstand und ergänzt OCR reicht nicht, wenn die fachliche Validierung fehlt.

Architektur-Überblick

flowchart TB
  subgraph Ingest["Deterministisch"]
    E[E-Rechnung / PDF]
    OCR[OCR / XRechnung Parser]
    W1[n8n Workflow]
  end
  subgraph Agent["Agentisch"]
    AG[Prüf-Agent]
    T1[Tool: PO Lookup]
    T2[Tool: Vertrag-Auszug]
    T3[Tool: Lieferant Status]
  end
  subgraph Out["Freigabe"]
    UI[Freigabe-UI]
    H[Mensch]
    ERP[(ERP Freigabe)]
  end
  E --> OCR --> W1
  W1 --> AG
  AG --> T1
  AG --> T2
  AG --> T3
  AG --> UI
  UI --> H
  H --> ERP

Der Workflow macht alles Deterministische. Der Agent startet nur, wenn Pflichtfelder vorhanden sind und ein Vertragsbezug existiert. Details zum Mix: Regelbasiert vs. agentisch.

Tool-Use-Design

Tool	Typ	Daten	Risiko
get_purchase_order	read	PO-Nummer, Positionen	niedrig
get_contract_terms	read	Zahlungsziel, Skonto	niedrig
get_supplier_status	read	Freigabe, Sperre	niedrig
propose_approval	write-queue	Vorschlag + Begründung	mittel, HITL

MCP kapselt diese Tools optional (MCP für IT-Leiter). Sicherheitsregeln: MCP-Sicherheit.

Leitplanken-Design

System-Prompt (Auszug, sinngemäß):

• Prüfe nur die gelieferten Felder, erfinde keine Werte.
• Bei Abweichung > 2 Prozent oder fehlender PO: Status klaeren.
• Jede Empfehlung mit Bullet-Liste der Belege.
• Maximal 8 Tool-Aufrufe pro Rechnung.

Technische Leitplanken:

const guardrails = {
  maxSteps: 8,
  allowedTools: ["get_purchase_order", "get_contract_terms", "get_supplier_status"],
  writeTools: [], // propose läuft über separaten Service
  timeoutMs: 45_000,
  model: "claude-sonnet-4-20250514", // pinned version
};

Output-Schema (JSON):

{
  "status": "freigeben | klaeren | ablehnen",
  "abweichungen": [
    { "feld": "zahlungsziel", "erwartet": 30, "ist": 14, "schwere": "mittel" }
  ],
  "begruendung": "…",
  "quellen": ["PO-9921", "Vertrag V-2024-17"]
}

Die Freigabe-UI rendert das Schema, der Mensch sieht keine Roh-JSON-Payload.

Ablauf eines Durchlaufs

1. Rechnung landet im DMS, Workflow extrahiert Felder.
2. Workflow prüft Duplikat und Pflichtfelder (deterministisch).
3. Agent lädt PO und Vertrag, vergleicht Positionen und Konditionen.
4. Agent schreibt Ergebnis in Freigabe-Queue.
5. Sachbearbeiter sieht Ampel, Begründung, Links zu Belegen.
6. Bei Freigabe: Workflow setzt ERP-Status (deterministisch).

Durchlaufzeit Ziel: unter 2 Minuten Agent-Lauf, unter 1 Tag menschliche Entscheidung.

KPIs und ROI

KPI	Baseline typisch	Ziel nach 90 Tagen
Rückfragen pro 100 Rechnungen	25 bis 40	12 bis 20
Zeit bis Freigabe	3 bis 7 Tage	1 bis 4 Tage
Übersehene Abweichungen	messen	< 2 % Stichprobe

Bei 400 Rechnungen monatlich und 15 Minuten pro Rückfrage sind 30 Prozent weniger Rückfragen ca. 30 Stunden im Monat. Das rechtfertigt den Agenten oft neben dem OCR-Workflow.

Wann scheitert das Projekt?

• Keine verlässlichen PO-Daten im ERP
• Verträge nur als unstrukturierte Scans ohne Metadaten
• Management erwartet „vollautomatische Buchhaltung”
• Security verbietet Cloud-LLM, aber kein EU-Modell verhandelt

Dann zuerst Daten und Prozess fixen, nicht den Agenten skalieren.

Wie integriert sich die Freigabe-UI?

Die UI ist keine PowerPoint-Mockup, sondern eine schlanke Web-Anwendung als Freigabe-Oberfläche:

• Ampel pro Rechnung (grün, gelb, rot)
• Side-by-Side PDF und Agent-Begründung
• Ein-Klick-Freigabe mit ERP-Webhook
• Kommentarfeld für Rückfragen an Lieferant

Sachbearbeiter sollen in unter 30 Sekunden entscheiden können, ob der Agent recht hat. Wenn die UI länger braucht, stimmt das Agent-Output-Schema nicht.

Rollout ohne Big-Bang

Woche	Umfang	Ziel
1 bis 2	10 Prozent Rechnungen, Parallel	Fehlerrate messen
3 bis 4	30 Prozent, Agent schlägt vor	Rückfragen zählen
5 bis 8	70 Prozent	KPI gegen Baseline
9 plus	Optional Vollbetrieb	Retainer Monitoring

Parallelbetrieb heißt: Agent und Sachbearbeiter prüfen unabhängig, Abweichungen werden protokolliert. Erst bei unter 2 Prozent kritischer Abweichung skalieren.

Technologie-Stack (Referenz)

Schicht	Technologie	Rolle
Ingest	n8n auf IONOS	OCR, Routing, Pflichtfelder
Agent	Claude oder Azure OpenAI EU	Tool-Use, Begründung
Tools	MCP oder direkte API	read-only ERP
UI	Astro plus Tailwind	Freigabe-Oberfläche
Log	Loki oder Postgres	Audit

Nentix entwickelt als Entwicklungspartner aus Oberhausen den gesamten Stack mit Festpreis. Made in Germany bedeutet hier: Code, Hosting-Vertrag und Ansprechpartner in Deutschland.

Was tun bei Modell-Wechsel?

Wenn der Modellanbieter ein Update ausrollt, kann sich Tool-Calling-Verhalten verschieben. Pflicht:

1. Prompt- und Modell-Version in Git taggen
2. 20 Golden-Test-Rechnungen automatisch durchlaufen
3. Abweichungen manuell klassifizieren (Akzeptabel / Bug / Rollback)
4. Erst dann Produktion umstellen

Ohne Golden Tests ist jedes Modell-Update ein Blindflug.

Lessons Learned aus Discovery-Calls

Zu breiter Scope: Agent soll Rechnung, Vertrag, Einkauf und Mahnwesen prüfen. Ergebnis: kein Go-Live. Besser: nur Rechnung gegen PO und Vertrag.

Zu wenig Daten: Verträge liegen nur als unlesbare Scans. Ergebnis: Agent halluziniert Konditionen. Besser: erst OCR plus Metadaten, dann Agent.

Zu hohe Erwartung: GF will 100 Prozent Autonomie. Ergebnis: Security-Stopp. Besser: Vorprüfung mit KPI Rückfragen-Reduktion.

Diese drei Muster sehen wir monatlich. Wer sie kennt, spart Budget.

Schnittstellen zu bestehenden Modulen

Der Genehmigungs-Agent ersetzt weder DocFlow noch Belegworkflow, sondern sitzt danach in der Kette. OCR und ERP-Import bleiben deterministisch. Der Agent ist die fachliche Zweitmeinung vor der Freigabe.

Wer Rechnungseingang automatisieren Kosten vergleicht, sollte Agent-Kosten separat kalkulieren, nicht in denselben Topf werfen.

Beispiel-KPI-Dashboard für Steering

Woche	Rechnungen mit Agent	Rückfragen	Übersehene Abweichungen
1	40	12	1
4	120	28	2
8	280	45	3

Trend nach unten bei Rückfragen pro 100 Rechnungen ist das Signal für Skalierung. Trend bei übersehenen Abweichungen nach oben ist Stopp-Signal.

Planen Sie im Budget immer zwei Iterationen Leitplanken nach dem ersten Parallelbetrieb. Die erste Prompt-Version trifft selten alle Edge Cases im Vertragswerk.

Der Genehmigungs-Agent ist kein Ersatz für Rechnungsfreigabe-Workflow, sondern die intelligente Schicht davor. Beides zusammen bildet den vollständigen Belegprozess im Mittelstand. Starten Sie mit einem klaren KPI, nicht mit Technologie-Demos.

Nächster Schritt

Nentix entwickelt Custom-Agentic-Workflows mit Festpreis und Betrieb aus Oberhausen auf IONOS. Überblick: MCP-Integration. Für Buchhaltungs-Schnittstellen: MCP DATEV und lexoffice.

Im Potenzial-Check ordnen Sie ein, ob Ihr Prozess reif ist. Direkt mit uns sprechen für Architektur-Review mit echten Beispiel-Rechnungen (NDA).