Finance Agent SAP: AP/AR-Workflows bauen (2026)

Pexon Consulting | 11 Min. Lesezeit | 20.06.2026

TL;DR

Ein Finance Agent für SAP orchestriert mehrere spezialisierte Schritte — Beleg erfassen, gegen Bestellung prüfen, Differenzen klären, buchen und überfällige Posten mahnen — statt nur Belege per OCR zu lesen. Pexon baut das gegen S/4HANA via OData und MCP, mit Human-in-the-Loop für Grenzfälle. Best-in-Class-Teams erreichen so über 70 Prozent Dunkelverarbeitung.

Warum reine Belegerkennung nicht reicht

Die meisten „KI für die Buchhaltung“-Projekte hören da auf, wo die Arbeit anfängt. Ein OCR-Tool liest die Rechnung, extrahiert Lieferant, Betrag, Steuer — und legt das Ergebnis dann in eine Queue, in der ein Mensch dreimal nachprüft, ob der Betrag zur Bestellung passt, die Kontierung stimmt und ob er buchen darf. Das ist Datenerfassung, kein Workflow.

Genau hier klafft die Lücke. Branchenweit laufen erst 32,6 Prozent der Eingangsrechnungen ohne menschlichen Eingriff durch; die Spitzengruppe liegt über 70 Prozent (APQC/Ardent-Benchmarks 2026). Der Unterschied ist fast nie die Erkennungsrate — moderne Extraktion liegt längst über 95 Prozent. Der Unterschied ist, ob die Schritte nach der Extraktion automatisch laufen: 3-Way-Match, Toleranzprüfung, Klärfall-Dialog mit dem Lieferanten, Buchung, und auf der Debitorenseite die risikobasierte Mahnung.

Ein Finance Agent SAP schließt diese Lücke. Er ist kein einzelnes Modell, sondern eine Kette aus deterministischen Tools (OData-Calls gegen S/4HANA), deren Reihenfolge im Orchestrator festgelegt ist. Das LLM liefert den Inhalt, etwa die Extraktion aus dem Beleg oder die Begründung eines Klärfalls, und markiert, wann ein Mensch ran muss. Welcher SAP-Aufruf als Nächstes passiert, entscheidet der Ablauf, nicht das Modell. Das ist seit der SAP API Policy 4.2026a der Punkt, an dem sich zulässig und unzulässig trennt. Wir grenzen das bewusst von der reinen Dokumentenerkennung ab — wer nur Belege digitalisieren will, ist mit klassischer KI-Verarbeitung von Eingangsrechnungen besser und günstiger bedient.

Die fünf Stufen eines AP/AR-Agenten

Ein agentischer Finance-Workflow zerfällt in fünf Stufen, die jeweils ein eigenes Tool oder einen eigenen Prüfschritt brauchen. Die kurze Antwort auf „Was macht so ein Agent eigentlich?“: Er durchläuft Erfassen, Prüfen, Klären, Buchen, Mahnen — und ruft pro Stufe SAP-Funktionen über definierte Schnittstellen auf, statt im UI zu klicken.

Stufe 3 ist die unterschätzte. Im klassischen Prozess wandern alle Differenzen in dieselbe Queue, und ein Sachbearbeiter arbeitet sie nach Eingangsdatum ab. Der Agent kann eine 0,8-Prozent-Mengenabweichung innerhalb der Toleranz selbst durchwinken, bei einer Preisdifferenz automatisch die Bestellhistorie ziehen und nur den echten Streitfall — falscher Steuersatz, Doppelrechnung — an den Menschen geben. Das ist der Punkt, an dem aus 50 Prozent Dunkelverarbeitung 70 werden.

So bindet der Agent S/4HANA an: OData statt Bildschirm-Scraping

Der Agent spricht nicht das SAP-GUI, sondern die freigegebenen OData-Services. Für Kreditoren ist das API_SUPPLIERINVOICE_PROCESS_SRV — damit lassen sich Lieferantenrechnungen anlegen, lesen, freigeben und stornieren, mit Bezug auf Bestellung, Wareneingang oder G/L-Konto (SAP Business Accelerator Hub). Eine geparkte Rechnung wird so per HTTP-POST angelegt und kann anschließend gebucht werden.

Wichtig für die Architektur: Wir kapseln jeden SAP-Call als MCP-Tool. Das Model Context Protocol gibt dem LLM eine saubere, typisierte Werkzeug-Definition — der Agent „weiß“ dann, dass er create_supplier_invoice aufrufen kann, ohne dass die Anmeldedaten oder die OData-URL je im Prompt landen. Wichtig dabei: Die typisierte Werkzeug-Definition sagt, wie ein Aufruf aussieht, nicht, dass das Modell ihn frei auswählen darf. Welche SAP-Aufrufe in welcher Reihenfolge passieren, steht im Orchestrator; das ist der Unterschied, auf den Ziffer 2.2.2 der SAP API Policy abzielt. Wer den MCP-Hintergrund braucht: unser Leitfaden zur MCP-Integration für KI-Agenten erklärt das Pattern im Detail, und für SAP-Sprachabfragen lohnt der Blick auf SAP MCP mit Copilot Studio.

So sieht eine MCP-Tool-Definition für die Kreditoren-Buchung aus (Python, FastMCP — Stand Juni 2026):

# finance_agent/tools/sap_ap.py
# MCP-Tool: legt eine geparkte Lieferantenrechnung in S/4HANA an.
# Auth (OAuth2 Client Credentials) und Host kommen aus der Umgebung,
# NICHT aus dem LLM-Prompt — das LLM sieht nur die typisierte Signatur.
import os, httpx
from fastmcp import FastMCP

mcp = FastMCP("sap-finance")
SAP_HOST = os.environ["SAP_S4_HOST"]          # z.B. https://my300000-api.s4hana.cloud.sap

@mcp.tool()
async def create_supplier_invoice(
    lieferant: str,          # Kreditor-Nummer (BusinessPartner)
    bestellnummer: str,      # PurchaseOrder für den 3-Way-Match
    bruttobetrag: float,     # inkl. Steuer
    waehrung: str = "EUR",
    buchungskreis: str = "1000",
) -> dict:
    """Legt eine geparkte Lieferantenrechnung mit Bestellbezug an.

    Gibt die SupplierInvoice-Belegnummer zurück. Bucht NICHT automatisch
    durch — das Posten ist ein eigener, abgesicherter Schritt (siehe post_invoice).
    """
    url = f"{SAP_HOST}/sap/opu/odata/sap/API_SUPPLIERINVOICE_PROCESS_SRV/A_SupplierInvoice"
    payload = {
        "CompanyCode": buchungskreis,
        "DocumentDate": _heute(),
        "InvoicingParty": lieferant,
        "InvoiceGrossAmount": str(bruttobetrag),
        "DocumentCurrency": waehrung,
        "to_SuplrInvcItemPurOrdRef": {  # Position mit Bestellbezug
            "results": [{"PurchaseOrder": bestellnummer, "DocumentCurrency": waehrung}]
        },
    }
    async with httpx.AsyncClient(headers=_auth_header()) as c:
        r = await c.post(url, json=payload, timeout=30)
        r.raise_for_status()
        beleg = r.json()["d"]["SupplierInvoice"]
    return {"status": "geparkt", "belegnummer": beleg}

Die OAuth2-Token-Beschaffung und der CSRF-Token-Handshake (SAP verlangt bei schreibenden Calls ein x-csrf-token) stecken in _auth_header() — bewusst ausgelagert, damit das Tool eine schmale, prüfbare Oberfläche hat.

Der Orchestrierungs-Schritt: wann der Agent selbst bucht, wann der Mensch ran muss

Das Herzstück ist der Ablauf, der festlegt, welches Tool wann läuft – und das ist die Stelle, an der die meisten Eigenbauten scheitern. Zwei Gründe sprechen gegen eine freie Agenten-Schleife: Sie ist fachlich schlecht prüfbar, und Ziffer 2.2.2 der SAP API Policy 4.2026a untersagt genau das Muster, dass ein KI-System Abfolgen von SAP-API-Aufrufen selbst plant, auswählt oder ausführt, außer über von SAP vorgesehene Wege. Unsere Empfehlung: fester Ablauf, und keine vollautonome Buchung ohne Confidence-Gate. Der Agent darf erfassen, matchen und parken, aber das Durchbuchen über einem Schwellwert hängt an einer Freigabe.

# finance_agent/orchestrator.py
# Minimaler Orchestrator: 3-Way-Match + Confidence-Gate vor der Buchung.
# Bewusst kein "Agent bucht alles allein" — Grenzfälle gehen an den Menschen.
TOLERANZ_PROZENT = 2.0      # Mengen-/Preisabweichung, die der Agent selbst durchwinkt
AUTO_BUCHEN_LIMIT = 5000    # EUR — darüber immer 4-Augen-Freigabe

async def verarbeite_rechnung(beleg: dict, agent) -> str:
    # 1. Match gegen Bestellung (Tool-Call liefert Abweichung in %)
    match = await agent.call("three_way_match", bestellnummer=beleg["po"])
    abweichung = abs(match["abweichung_prozent"])

    # 2. Klärfall? -> Dialog-Tool zieht Bestellhistorie / öffnet Ticket
    if abweichung > TOLERANZ_PROZENT or match["doppelrechnung_verdacht"]:
        return await agent.call("eroeffne_klaerfall", beleg=beleg, grund=match["grund"])

    # 3. Innerhalb Toleranz: parken
    geparkt = await agent.call("create_supplier_invoice", **beleg)

    # 4. Confidence-Gate: nur kleine, saubere Belege bucht der Agent selbst
    if beleg["bruttobetrag"] <= AUTO_BUCHEN_LIMIT and match["confidence"] >= 0.95:
        await agent.call("post_invoice", belegnummer=geparkt["belegnummer"])
        return f"gebucht: {geparkt['belegnummer']}"

    return f"geparkt zur Freigabe: {geparkt['belegnummer']}"  # Human-in-the-Loop

Dieses Gate ist der Grund, warum agentische Finance-Projekte überhaupt durch die Revision kommen. Die Logik ist nachvollziehbar, jede Buchung trägt eine Begründung, und der Mensch entscheidet die teuren Fälle. Wir bauen die Orchestrierung deshalb mit einem expliziten State-Graph statt einer freien Agenten-Schleife, bei SAP-Aufrufen ohne Ausnahme – wer den Stack vergleichen will, findet die Optionen in unserem Überblick zur KI-Agenten-Orchestrierung.

Die Debitorenseite: risikobasiert mahnen statt Kalender-Blasts

Auf der AR-Seite verschiebt sich der Hebel von der Buchung zum Timing. Der klassische SAP-Mahnlauf feuert nach festem Kalender: Tag 14 Mahnstufe 1, Tag 30 Mahnstufe 2 — unabhängig davon, ob der Kunde sonst pünktlich zahlt oder chronisch schleppt. Ein Debitoren-Agent dreht das um: Er bewertet pro offenem Posten die Zahlungswahrscheinlichkeit und priorisiert die Mahn- und Kontaktreihenfolge danach.

Die Zahlen sprechen dafür. AR-Teams mit KI-gestützter, verhaltensbasierter Mahnung senken ihre Days Sales Outstanding um 15 bis 25 Tage, automatisierte Mahnstrecken heben die Inkasso-Quote im Schnitt um rund 30 Prozent (HighRadius AR-Benchmarks 2026). In unseren Projekten ist der größere Effekt oft die Entlastung: Ein Agent, der nur die wirklich gefährdeten Forderungen eskaliert, gibt dem Team die Zeit zurück, die heute in Standard-Mahnungen an zuverlässige Zahler fließt.

Technisch greift der Agent die offenen Posten über OData ab, scort sie und ruft den Mahn-Service nur für die priorisierten Fälle. Die Mahn-Texte erzeugt das LLM tonangepasst — ein A-Kunde mit einmaliger Verspätung bekommt eine andere Ansprache als ein Dauerschuldner. Wer SAP-Daten zunächst nur lesend per Sprache erschließen will, findet den Einstieg in SAP-Daten in Copilot Studio — der Schreibweg über Buchung und Mahnung ist der Schritt danach.

Was das kostet und wie lange es dauert

Kurz: Ein erster produktiver AP- oder AR-Teilprozess ist in sechs Wochen machbar, der Rest skaliert in 90-Tage-Schritten. Der Aufwand verteilt sich nicht auf das Modell, sondern auf die SAP-Anbindung und die Toleranz-/Freigaberegeln — die kennt jedes Unternehmen anders.

Zur Einordnung der Wirtschaftlichkeit: Best-in-Class-AP-Teams verarbeiten eine Rechnung für rund 2,78 US-Dollar bei knapp 50 Prozent Dunkelverarbeitung, der Branchenschnitt liegt bei 9,40 bis 14,93 US-Dollar (Ardent Partners 2026). Bei 50.000 Rechnungen im Jahr ist das eine Differenz im sechsstelligen Bereich — und sie entsteht fast vollständig in den Stufen 2 bis 4, nicht in der Erkennung.

Ein Frische-Hinweis zum Stack: SAP hat mit dem Business-AI-Release Q1 2026 (veröffentlicht 14.04.2026) Joule Studio allgemein verfügbar gemacht und liefert über 30 spezialisierte Agenten plus rund 2.500 Joule Skills aus, dazu das ABAP-Foundation-Model SAP-ABAP-1 (SAP News, April 2026). Das ist relevant für die Make-or-Buy-Frage: Standard-Szenarien deckt Joule zunehmend ab, der Custom-Agent lohnt dort, wo eigene Toleranzlogik, Drittsysteme oder spezielle Klärwege im Spiel sind.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Finance Agent SAP und reiner Rechnungs-OCR?

OCR liest den Beleg und gibt strukturierte Daten zurück — das ist Stufe 1 von fünf. Ein Finance Agent führt zusätzlich den 3-Way-Match aus, klärt Differenzen, bucht über die SAP-OData-Services und stößt auf der Debitorenseite die Mahnung an. Wer nur erkennen will, braucht keinen Agenten; wer den Buchungs- und Klärweg automatisieren will, schon.

Was kostet ein Finance-Agent-Projekt für SAP?

Der Pilot für einen Teilprozess liegt im Rahmen eines üblichen 6-Wochen-Festpreises; der Großteil des Aufwands steckt in der SAP-Anbindung und den Freigaberegeln, nicht im Modell. Über das Volumen rechnet es sich schnell: Die Differenz zwischen Branchenschnitt und Best-in-Class liegt bei rund 7 bis 12 US-Dollar pro Rechnung.

Bucht der Agent vollautomatisch — und ist das revisionssicher?

Nein, nicht pauschal. Wir setzen ein Confidence-Gate: kleine, sauber gematchte Belege darf der Agent selbst buchen, alles darüber geht in die Vier-Augen-Freigabe. Jede Aktion trägt eine maschinenlesbare Begründung, was die Prüfbarkeit gegenüber dem manuellen Prozess sogar erhöht.

Brauche ich S/4HANA, oder geht es auch mit SAP ECC?

Sauber dokumentierte OData-Services gibt es vor allem in S/4HANA (Cloud wie On-Premise). Bei ECC ist der Weg über BAPIs oder eine Middleware-Schicht möglich, aber aufwändiger. Wir prüfen im Vorprojekt, welche Schnittstellen Ihr System freigibt.

Wie hängt das mit MCP zusammen?

MCP (Model Context Protocol) ist die Schicht, über die das LLM die SAP-Funktionen als typisierte Werkzeuge aufruft, ohne Zugangsdaten im Prompt. Das trennt die Geschäftslogik sauber vom Modell und macht denselben SAP-Toolsatz für verschiedene Agenten und Frontends wiederverwendbar.

Was sagt die SAP API Policy 4.2026a zu so einem Agenten?

Ziffer 2.2.2 untersagt die Nutzung von SAP-APIs für die Anbindung generativer oder (teil-)autonomer KI-Systeme, die Abfolgen von API-Aufrufen planen, auswählen oder ausführen, außer über von SAP vorgesehene Architekturen, Datendienste oder dienstspezifische Wege; Ziffer 3 verbietet die Umgehung über eigenen Code, Proxys oder Gateways. Die Trennlinie liegt also nicht zwischen Lesen und Buchen, sondern zwischen „der Orchestrator legt die Aufruffolge fest“ und „das Modell wählt sie selbst“. Der hier beschriebene Aufbau liegt auf der ersten Seite dieser Linie: feste Stufen, deterministische Tool-Aufrufe, Confidence-Gate, Freigabe durch Menschen. Wer stattdessen einen frei wählenden Agenten gegen SAP will, geht über das MCP Gateway der SAP Integration Suite, SAP-eigene MCP-Server über Joule Studio oder A2A. SAP stellt in der CAP-Dokumentation ausdrücklich klar, dass ein selbst gebauter MCP-Adapter keine anerkannte Architektur im Sinne dieser Ziffer ist. Verbindlich ist für Ihre Landschaft nur Ihr SAP-Vertrag oder Ihr SAP-Account-Team; wir bringen die Frage im Vorprojekt auf den Tisch. Stand der zitierten SAP-Dokumente: 18.09.2026.

Nächster Schritt

Wenn Sie gerade evaluieren, ob ein agentischer AP/AR-Workflow für Ihr S/4HANA tragfähig ist: Der schnellste Weg zu einer belastbaren Antwort ist ein Workshop, in dem wir einen konkreten Prozess auf Automatisierbarkeit und Revisionssicherheit prüfen.