Abweichungskommentare im Monatsabschluss mit KI: Eine Architektur, die mit der SAP API Policy vereinbar ist

Ein Sprachmodell kann Abweichungskommentare im Monatsabschluss entwerfen, wenn es nur formuliert und nicht rechnet. Die Zahlen kommen deterministisch aus SAP, das Modell erhält sie fertig aufbereitet, und das Controlling gibt jeden Kommentar frei. Aus unserer Sicht lässt sich der Fall so mit der SAP API Policy vereinbaren; die Einordnung ist im Pilot mit SAP zu bestätigen. Dieser Beitrag beschreibt die Architektur, die Grenzen und einen Pilot in sechs Wochen.

Wichtig vorab: Wir führen diesen Anwendungsfall als Konzept. Es ist ein Lösungsentwurf, den wir im Pilot umsetzen und messen, kein Produkt im Einsatz. Zahlen zum Zeitgewinn nennen wir bewusst nicht; die einzig belastbare Größe ist Ihre eigene Messung im Pilot.

Was am Abweichungskommentar Routine ist und was Urteil bleibt

Ein Abweichungskommentar beantwortet drei Fragen: Wie groß ist die Abweichung, wo sitzt sie, und warum ist sie entstanden? Die ersten beiden sind Rechenarbeit. Abweichung nach Sachkonto, Kostenstelle und Profit Center lässt sich aus den Belegen ermitteln, immer gleich und nachvollziehbar. Auch der Satzbau („Der Mehraufwand von … entfällt zu … auf …“) wiederholt sich Monat für Monat.

Die dritte Frage ist Urteil. Ob eine Preisabweichung bei Rohstoffen dauerhaft ist, ob eine Nachbuchung zum Vormonat ein Fehler war oder eine Korrektur, ob ein Effekt im Folgemonat zurückläuft: Das weiß, wer den Vorgang kennt. Ein Modell sieht nur, was ihm übergeben wird. Aus unserer Sicht gehört der Ursachenteil deshalb dem Controlling; das Modell kann ihn vorbereiten, etwa durch den Hinweis auf auffällige Einzelbelege, aber nicht entscheiden.

Arbeitsteilung: Zahlen rechnen, Text formulieren, Freigabe erteilen

Die Trennung ist der Kern der Architektur. Sie soll verhindern, dass ein Sprachmodell Beträge „schätzt“, und sie macht jeden Satz prüfbar.

Arbeitsschritt	System (SAP-Abfrage)	Sprachmodell	Controlling
Abweichung ermitteln, gegliedert nach Sachkonto, Kostenstelle, Profit Center	rechnet deterministisch	nicht beteiligt	legt Schwellen und Gliederung fest
Auffällige Belege auswählen	wendet feste Regeln an (z. B. größte Beträge)	nicht beteiligt	bestätigt die Regeln
Kommentar entwerfen	liefert Zahlen und Belegverweise	formuliert nur aus den gelieferten Werten	prüft
Ursache einordnen	liefert Vergleichsdaten	benennt Hinweise, ohne sie als Tatsache auszugeben	entscheidet und ergänzt Kontext
Freigabe	protokolliert	nicht beteiligt	gibt frei oder ändert

Jede Aussage im Entwurf trägt einen Nachweis: Betrag, Konto, Belegnummer. Eine Aussage ohne Nachweis wird nicht übernommen.

Die Architektur in fünf Stufen

Die folgenden Stufen sind unser Lösungsentwurf; die genannten SAP-Komponenten sind in der SAP-Dokumentation beschrieben, ihr Zusammenspiel in dieser Form ist unsere Konzeption.

1. SAP S/4HANA. Istwerte, auch die des Vorjahres, kommen aus dem Universal Journal, Planwerte aus Ihrer Planung in SAP oder dem Planungswerkzeug. Das sind die einzigen Zahlenquellen. Das Modell bekommt keine eigene Datenhaltung und rechnet nichts nach.

2. Lesender Zugriff. Ein festgelegter Satz von Abfragen liest über OData-Services und CDS-Views, mit den Berechtigungen des Kunden. Die Abfragen sind fest und werden geprüft; sie entstehen nicht erst zur Laufzeit. Für analytische Auswertungen unterhalb einer Vollreplikation nennt die SAP-FAQ ausdrücklich analytische CDS-Views und OData-V4-Analytikservices mit Filter, Aggregation und dem Operator $apply. Welche Views im konkreten System passen, klären wir im Pilot; hier nennen wir bewusst keine View-Namen.

3. Sprachmodell über SAP-Wege. Das Modell wird entweder über SAP AI Core angesprochen, genauer über den generative AI hub mit dem Orchestrierungsdienst und dem Modul Data masking, oder, wenn eine KI-Plattform selbst auf SAP-Schnittstellen zugreifen soll, über den MCP Gateway in der SAP Integration Suite. Nach unserem Entwurf sieht das Modell im ersten Fall nur die vorbereiteten Zahlen. Im zweiten läuft der Zugriff laut SAP-FAQ über einen kundenverwalteten Einstiegspunkt mit Authentifizierung, Autorisierung, Ratenbegrenzung und Audit-Protokoll.

4. Kontrolle und Freigabe. Jede Anfrage wird protokolliert, jede Aussage bekommt ihre Quelle, die Fachverantwortlichen geben frei. Aus unserer Sicht dient das Protokoll zugleich als Nachweis für Prüfer.

5. Ergebnis im gewohnten Werkzeug. Der freigegebene Kommentar erscheint dort, wo Ihr Controlling ihn heute pflegt, etwa im Berichtspaket oder in der Abschlussmappe. Eine neue Oberfläche ist dafür nicht nötig.

Was die SAP API Policy für diesen Fall bedeutet

Die Policy (Version 4.2026a) regelt in Abschnitt 2.2.2, dass außerhalb gebilligter Architekturen, Datendienste oder eigens vorgesehener Wege die „interaction or integration with (semi-) autonomous or generative AI systems that plan, select, or execute sequences of API calls“ untersagt ist. Zusätzlich untersagt sie Scraping und systematische, großvolumige Datenextraktion. Eine ausführliche Einordnung finden Sie in unserem Beitrag zur SAP API Policy für KI.

Entscheidend ist der Unterschied zwischen Auswerten und Handeln. Unser Entwurf ist eine reine Auswertung: Das Modell plant, wählt und führt keine Aufrufe aus. Die Abfragen sind vorab festgelegt, das Modell bekommt nur deren Ergebnis. Nach der FAQ fallen regelbasierte Werkzeuge mit vordefinierten, deterministischen Aufrufen nicht unter Abschnitt 2.2.2. Das beschreibt die FAQ für RPA; aus unserer Sicht überträgt sich der Gedanke auf feste Abfragen, verbindlich ist das aber nicht. Weil die FAQ ausdrücklich nicht Vertragsbestandteil ist, empfehlen wir, die Einordnung im Pilot mit dem SAP-Account-Team schriftlich zu bestätigen.

Soll das Modell dagegen selbst entscheiden, welche Schnittstellen es wann aufruft, etwa um Belege nachzuladen, ist das der Fall „Handeln“. Dann ist der MCP Gateway der von SAP gebilligte Weg; Drittanbieter-MCP-Server sind unter Bedingungen zulässig (siehe SAP API Policy für KI). Laut SAP Architecture Center hängt die Verfügbarkeit der MCP-Funktionen vom Servicetarif ab; Tarif, Aktivierung, Rollen und Anbindung der Systeme sind vorab zu prüfen. Die Policy ändert nach Angabe der SAP-FAQ keine Lizenzansprüche; die lizenzrechtliche Frage bleibt gesondert zu klären.

Datenschutz und Maskierung

Abweichungskommentare betreffen überwiegend Kostenarten und Organisationseinheiten; Belegtexte und Zuordnungen können aus unserer Sicht aber Personen- oder Vertragsdaten enthalten. Der Orchestrierungsdienst in SAP AI Core bietet dafür das Modul Data masking: Es anonymisiert oder pseudonymisiert Daten, bevor sie an das Modell gehen. Bei der Pseudonymisierung werden maskierte Werte in der Antwort wiederhergestellt, bei der Anonymisierung nicht.

Zwei Einschränkungen nennt die SAP-Dokumentation selbst: Die Erkennung ist automatisiert und kann nicht garantieren, dass alle personenbezogenen Daten erfasst werden. Und Anonymisierung kann Kontext entfernen, den das Modell braucht. Unsere Konsequenz: Wir geben dem Modell erst gar keine Freitexte aus Belegen, wenn die Zahlen genügen, und maskieren, wo Texte nötig sind. Rechtliche Einordnung, Auftragsverarbeitung und Verarbeitungsverzeichnis prüfen wir im Einzelfall; Grundlagen finden Sie unter KI und Datenschutz.

Messgröße: Zeit bis zum freigegebenen Kommentar

Ob sich der Aufwand lohnt, zeigt eine einzige Größe: die Zeit vom Abschluss der Buchungen bis zum freigegebenen Kommentar, gemessen im heutigen Ablauf und im Pilot, gegliedert nach Berichtseinheit. Ergänzend zählen wir, wie viele Entwürfe unverändert, geändert oder verworfen werden. Ein Entwurf, der mehr Korrektur kostet als ein neuer Text, ist kein Gewinn. Zahlen aus Herstellermeldungen oder fremden Projekten taugen dafür nicht; Ihre Ausgangslage ist die einzige belastbare Vergleichsbasis.

Grenzen

• Halluzination. Ein Sprachmodell kann plausibel klingende Aussagen erzeugen, die nicht stimmen. Der Nachweiszwang pro Aussage und die Freigabe begrenzen das Risiko, beseitigen es aber nicht.
• Fehlender Kontext. Dass ein Auftrag verschoben wurde oder ein Lieferant gewechselt hat, steht nicht im Journal. Dieses Wissen bringt nur das Controlling ein.
• Verantwortung. Der Kommentar bleibt Aussage des Controllings. Die Freigabe ist keine Formalität, sondern der Punkt, an dem die Verantwortung liegt.
• Datenqualität. Falsch kontierte Belege erzeugen falsche, aber sauber formulierte Kommentare.

Pilot in sechs Wochen

Der KI-Pilot Finance ist auf sechs Wochen angelegt:

• Woche 1: Anwendungsfall und Zielgröße festlegen, Ausgangszeit messen.
• Woche 2: Datenzugriff und Regeln klären: Abfragen, Berechtigungen, Maskierung, Zugriffsweg, Einordnung zur API Policy.
• Woche 3 bis 5: Prototyp bauen und mit echten Abschlussdaten des Vormonats testen.
• Woche 6: Messung und Entscheidung: weiter, anpassen oder beenden.

Das Ergebnis ist eine Entscheidungsgrundlage mit Ihren Messwerten, kein fertiges Produkt. Wie wir KI-Projekte für SAP grundsätzlich angehen, steht unter KI für SAP.

Was Sie jetzt tun können

1. Ausgangszeit erfassen. Messen Sie beim nächsten Abschluss, wie lange es von der letzten Buchung bis zum freigegebenen Kommentar dauert, je Berichtseinheit.
2. Regeln vorab festlegen. Bestimmen Sie Gliederung, Schwellenwerte und die Frage, welche Ursachenaussagen nur das Controlling treffen darf.
3. Zugriffsweg klären. Entscheiden Sie mit IT und SAP-Account-Team, ob feste, lesende Abfragen genügen oder ein Agent eigene Aufrufe planen soll, und halten Sie die Fassung von Policy und FAQ fest.

Gern besprechen wir Ihren Anwendungsfall in einem Erstgespräch mit Ihnen.