Einrichtungsanleitung

Bereitstellung

Voraussetzungen

• SAP BTP Subaccount mit Cloud-Foundry-Umgebung
• CF CLI mit dem MultiApps-Plugin: cf install-plugin multiapps
• Die folgenden gemanagten BTP-Dienste, bereitgestellt in Ihrem CF-Space:

App-Paket bereitstellen

Verwenden Sie das von ASAPIO bereitgestellte Deployment-Paket und stellen Sie es in Ihrem Ziel-Cloud-Foundry-Space bereit.

Terminal

# Deploy the provided MTA archive to Cloud Foundry
cf deploy <path-to-your-package>/asapio-spendlens_<version>.mtar

Der Deploy-Befehl erstellt oder aktualisiert drei CF-Anwendungen (asapio-spendlens-approuter, asapio-spendlens-srv, asapio-spendlens-db-deployer) und bindet sie an die oben genannten Dienste.

Standardmäßig generiert CF die Modul-Routen automatisch. Dies ist die empfohlene Konfiguration für Kundenbereitstellungen, da sie Host-Kollisionen und ein Abweichen der Route-Zuordnung über Spaces/Subaccounts hinweg vermeidet. Rufen Sie nach der Bereitstellung die aktive App-URL wie folgt ab:

cf apps

Der Modus mit ausschließlich generierten Routen ist Standard und empfohlen. Verlassen Sie sich für produktive Bereitstellungen nicht auf manuell zugeordnete feste Alias-Routen.

Checkliste für den ersten Start

Nach der Bereitstellung:

• Im BTP Cockpit: Weisen Sie die Role Collection SpendLens Admin mindestens einem Benutzer zu (siehe Rollen und Zugriff weiter unten)
• Melden Sie sich an der App an und öffnen Sie Settings (nur für Benutzer mit der Admin-Rolle sichtbar)
• Wählen Sie die S/4HANA-BTP-Destination aus und klicken Sie auf Test Connection
• Stellen Sie den Auth Mode passend zu Ihrem Destination-Typ ein (siehe Anbindung an S/4HANA)
• Konfigurieren Sie in den User Settings bei Bedarf die Bezeichnungen der Organisationseinheiten
• Weisen Sie die Role Collection SpendLens User allen weiteren Benutzern zu, die Zugriff benötigen

Nach dem Zuweisen oder Ändern einer Role Collection im BTP Cockpit müssen sich Benutzer ab- und wieder anmelden, damit das neue Token (mit den aktualisierten Scopes) wirksam wird. Verwenden Sie die Schaltfläche Log out im App-Header.

Rollen und Zugriff

Spend Lens verwendet SAP BTP XSUAA für die gesamte Authentifizierung. Es gibt keine lokalen Benutzerkonten.

Role Collections

Verbindungseinstellungen (mit welchem S/4HANA-System verbunden wird, welche Destination verwendet wird) sind global und ausschließlich für Admins. Eine Änderung durch einen Admin wird sofort für alle Benutzer wirksam.

Rolle im BTP Cockpit zuweisen

1. Öffnen Sie das BTP Cockpit und navigieren Sie zu Ihrem Subaccount.
2. Gehen Sie zu Security → Role Collections.
3. Öffnen Sie SpendLens Admin (oder SpendLens User).
4. Klicken Sie auf Edit, dann auf Users → Add User.
5. Geben Sie die E-Mail-Adresse des Benutzers ein und wählen Sie den Identity Provider, mit dem sich der Benutzer tatsächlich anmeldet (siehe unten).
6. Speichern Sie. Die Rolle wird bei der nächsten Anmeldung des Benutzers wirksam (der Benutzer muss sich ab- und wieder anmelden).

Weisen Sie SpendLens Admin nur Benutzern zu, die für die Systemkonfiguration verantwortlich sind. Alle anderen Benutzer sollten SpendLens User erhalten.

Welcher Identity Provider?

Role-Collection-Zuweisungen sind pro Identity Provider abgegrenzt. Eine Rolle wird nur wirksam, wenn sie unter demselben Identity Provider zugewiesen ist, mit dem sich der Benutzer anmeldet — die Zuweisung unter einem anderen ist die häufigste Ursache für einen „403 — lacking required roles"-Fehler, obwohl die Rolle zugewiesen zu sein scheint.

Welcher Identity Provider zu wählen ist, hängt von der Trust-Konfiguration Ihres Subaccounts ab:

• Verfügt Ihr Subaccount über keinen eigenen Identity Provider, authentifizieren sich Benutzer über den Default Identity Provider (SAP Cloud Identity / SAP ID Service) — weisen Sie die Rollen dort zu.
• Verwendet Ihre Organisation einen eigenen SAP Cloud Identity Services (IAS) Tenant (optional föderiert mit einem Unternehmens-IdP wie Microsoft Entra ID oder Okta), authentifizieren sich Benutzer über den Business-User-Trust dieses Tenants — weisen Sie die Rollen dort zu, nicht unter „Default".

Um die Identity Provider Ihres Subaccounts anzuzeigen, öffnen Sie BTP Cockpit → Security → Trust Configuration (jeder Eintrag zeigt seinen Purpose — wählen Sie den für Business users, nicht für Platform users). Dieselbe Liste ist über die SAP BTP CLI mit btp list security/trust verfügbar.

Fehlerbehebung „403 — lacking required roles". Erhält ein Benutzer diesen Fehler, nachdem die Rolle zugewiesen wurde: (1) Stellen Sie sicher, dass die Zuweisung unter dem Business-User-Identity-Provider erfolgt, mit dem sich der Benutzer tatsächlich anmeldet — nicht unter „Platform users" und nicht unter einem anderen IdP; (2) lassen Sie den Benutzer sich ab- und wieder anmelden (eine frische Sitzung, z. B. im Inkognito-Modus), damit ein neues Token mit der Rolle ausgestellt wird.

Anbindung an S/4HANA

Spend Lens liest aus drei standardmäßigen SAP-OData-APIs — API_PURCHASEORDER_2 (OData v4, Bestellungen), API_SUPPLIERINVOICE_PROCESS_SRV (OData V2, Lieferantenrechnungen) und API_BUSINESS_PARTNER (OData V2, Lieferantenstammdaten). Es sind kein S/4HANA-Add-on und keine kundenspezifische Entwicklung erforderlich. Die APIs sind auf SAP S/4HANA 2022+ (On-Premise / Private Cloud) und S/4HANA Cloud Public Edition verfügbar, und alle drei nutzen dieselbe BTP-Destination.

Die Verbindung wird von einem Admin unter Settings → Connection Settings konfiguriert: Wählen Sie die BTP-Destination, wählen Sie einen Auth Mode und klicken Sie auf Test Connection. Folgen Sie dem Abschnitt unten, der zu Ihrer S/4HANA-Bereitstellung passt.

S/4HANA On-Premise / Private Cloud

BTP-Destination

BasicAuthentication: ein gemeinsam genutzter technischer SAP-Benutzer. Alle Spend-Lens-Benutzer greifen unter derselben SAP-Identität auf S/4HANA zu. Einfach einzurichten; setzen Sie den Auth Mode in Spend Lens auf Technical user.

PrincipalPropagation: Die Identität des angemeldeten BTP-Benutzers wird über die Trust-Konfiguration des Cloud Connectors an S/4HANA weitergeleitet. Erfordert einen System-Trust zwischen BTP und S/4HANA. Wenn die ausgewählte Destination Principal Propagation verwendet, zeigt Spend Lens den Auth Mode als Principal Propagation (schreibgeschützt) an und speichert keine Anmeldeinformationen.

Per-user Basic Auth (Auth Mode in Spend Lens): nur relevant für On-Premise-BasicAuthentication-Destinations, bei denen keine Principal Propagation konfiguriert ist. Jeder Benutzer meldet sich mit seinen eigenen SAP-Anmeldeinformationen an. Zwei Speicheroptionen: nur sitzungsbezogen (A) oder serverseitig mit AES-256-GCM verschlüsselt (B, „Remember me").

Erforderliche Berechtigungen

Die verwendete SAP-Identität (technischer oder propagierter Benutzer) benötigt Lesezugriff auf die drei APIs. Feldwert-Einschränkungen (z. B. die Beschränkung von EKORG auf bestimmte Einkaufsorganisationen) werden berücksichtigt — Spend Lens zeigt nur Daten an, für deren Lesen der SAP-Benutzer berechtigt ist.

API_PURCHASEORDER_2

API_SUPPLIERINVOICE_PROCESS_SRV

API_BUSINESS_PARTNER (Supplier Profiles — optional)

Speist das Lieferanten-Datenblatt (Stammdaten, Adressen, Kontakte) auf der Suppliers-Seite. Optional: Ist es nicht verfügbar, funktioniert der Rest der Suppliers-Seite weiterhin — nur das Datenblatt-Panel bleibt leer.

S/4HANA Cloud Public Edition

BTP-Destination

OAuth2ClientCredentials: ein gemeinsam genutztes Service-Konto. Alle Spend-Lens-Benutzer greifen unter derselben Service-Identität auf S/4HANA zu. Setzen Sie den Auth Mode in Spend Lens auf Technical user.

OAuth2SAMLBearerAssertion: Die Identität des BTP-Benutzers wird über einen SAML-Bearer-Token-Austausch gegenüber S/4HANA nachgewiesen. Erfordert ein Communication Arrangement in S/4HANA, das Ihren BTP-Subaccount als Identity Provider vertraut. Setzen Sie den Auth Mode in Spend Lens auf Technical user (das Cloud SDK führt den SAML-Assertion-Austausch automatisch durch).

Basic Auth wird mit S/4HANA Cloud Public Edition nicht verwendet.

Kommunikationsszenarien

Erstellen Sie für jedes der folgenden Szenarien ein Communication Arrangement (Communication Management → Communication Arrangements). Alle drei können demselben eingehenden Kommunikationsbenutzer und demselben Kommunikationssystem zugewiesen werden.

Es ist keine separate BTP-Destination pro API erforderlich — die vorhandene Bestellungs-Destination wird für alle drei wiederverwendet. API_BUSINESS_PARTNER / SAP_COM_0009 ist optional (nur das Lieferanten-Datenblatt nutzt es).

Funktionen

Alle Analysen sind schreibgeschützt. Spend Lens schreibt keine Beschaffungsdaten nach S/4HANA zurück.

Währungsumrechnung

Beschaffungsbelege umfassen häufig mehrere Währungen. Standardmäßig behält Spend Lens jeden Betrag in seiner Belegwährung und kennzeichnet jede gemischte Summe; optional können Sie Global Display Currency aktivieren, um alles in einer Währung zu berichten. Beide Verhaltensweisen werden unten beschrieben. Konfigurieren Sie die Währung auf dem Tab Settings → Currency (nur Admin).

Standard: Belegwährung mit Schutz vor gemischten Währungen

Ist Global Display Currency deaktiviert, zeigt jede KPI-Kachel die dominierende Währung und ihren Anteil an der Ergebnismenge (z. B. „EUR 62%"). Deckt die dominierende Währung weniger als 80% der Gesamtsumme ab, zeigt die Kachel „Mixed (top: EUR 62%)", um zu kennzeichnen, dass die Zahl mehr als eine Währung bündelt und nicht als Summe einer einzelnen Währung gelesen werden sollte. Beträge in Tabellen werden als reine Zahlen dargestellt (z. B. 1.2M) mit einer separaten CCY-Spalte für den Belegwährungscode — in der Betragszelle ist kein Währungssymbol eingebettet, sodass ein USD-Wert niemals fälschlich mit einem €-Zeichen versehen werden kann.

Global Display Currency

Aktivieren Sie Global Display Currency, um alle Beträge in einer einzigen Währung zu berichten, sodass Dashboard, Diagramme, Top Suppliers, Purchase Orders und Invoices alle eine Währung ohne „Mixed"-Warnung anzeigen.

Wechselkurse von der EZB. Kurse für die 29 EZB-Referenzwährungen (USD, GBP, CHF, JPY, SEK, DKK, NOK, PLN, CZK, HUF, RON, ISK, TRY, AUD, CAD, CNY, HKD, INR, MXN, ZAR und weitere) werden vom ECB Data Portal mit EUR als Basis abgerufen.

ECB API & Netzwerk-Egress. „Pull from ECB" löst einen ausgehenden HTTPS-Aufruf vom Spend-Lens-Backend an die öffentliche Data API der Europäischen Zentralbank (SDMX-JSON) aus — kein Schlüssel und keine Registrierung erforderlich:

https://data-api.ecb.europa.eu/service/data/EXR/D.<currencies>.EUR.SP00.A?lastNObservations=1&format=jsondata

Die BTP-Umgebung (und jeder Egress-Proxy/jede Firewall) muss ausgehenden Zugriff auf data-api.ecb.europa.eu zulassen. Die Währungsumrechnung ist optional — wenn Sie Global Display Currency nie aktivieren, wird niemals ein ECB-Aufruf ausgeführt.

Die Einrichtung erfolgt in zwei Schritten:

1. Klicken Sie auf „Pull from ECB", um Live-Kurse für die 29 EZB-Referenzwährungen abzurufen.
2. Aktivieren Sie den Umschalter und wählen Sie die Anzeigewährung. Das Dropdown der Anzeigewährung listet nur Währungen auf, für die ein Kurs gespeichert ist, sodass Sie niemals eine Währung auswählen können, in die die App nicht umrechnen kann.

Für jede Belegwährung in Ihren Daten muss ein Kurs vorhanden sein; Zeilen in einer Währung ohne Kurs werden aus den umgerechneten Summen ausgeschlossen, und auf dem Dashboard erscheint ein „missing rates"-Banner.

Eigene Währungen & manuelle Kurse. Die Add / Update-Zeile der Exchange-Rates-Tabelle hat ein Feld für den Währungscode — geben Sie einen beliebigen Code (bis zu 5 Zeichen) und seinen Kurs (1 EUR = X) ein. Codes, die die EZB nicht veröffentlicht, zeigen eine Warnung, dass „Pull from ECB" sie nicht aktualisiert, sodass Sie deren Kurs manuell pflegen. Bearbeiten Sie einen vorhandenen Kurs direkt in der Zeile und klicken Sie auf Save oder entfernen Sie ihn mit der Schaltfläche ✕. „Pull from ECB" aktualisiert jede bereits in der Tabelle enthaltene, von der EZB abgedeckte Währung und lässt manuelle Einträge unberührt.

Eine Änderung anwenden

Nach dem Aktivieren von Global Currency oder dem Wechsel der Anzeigewährung bietet ein Banner eine Schaltfläche Sync Now — ohne dass Sie die Settings verlassen müssen. Die Summen sind sofort korrekt, auch für Daten, die vor dem Einschalten der Funktion synchronisiert wurden.

Die Tabellen lesen. Bei aktiviertem Global Currency fügen Tabellen neben dem Betrag in Belegwährung und seinem CCY-Code eine Converted-Spalte in der Anzeigewährung hinzu, sodass Sie stets sowohl den Original- als auch den umgerechneten Wert sehen.

Daten-Caching

Spend Lens fragt S/4HANA nicht bei jeder Interaktion ab. Es liest die relevanten Beschaffungsbelege aus den standardmäßigen OData-APIs, cacht sie und liefert das Dashboard aus diesem Cache. Dies begrenzt, wie oft Spend Lens Ihr S/4HANA-System aufruft. Alle Kennzahlen werden aus den gecachten Quellbelegen abgeleitet, sodass sie mit dem übereinstimmen, was Sie direkt in S/4HANA berechnen würden. Spend Lens ist schreibgeschützt und schreibt niemals zurück.

Aktualisierung und Time-to-Live

Gecachte Daten werden automatisch nach Ablauf einer Time-to-Live (TTL) aktualisiert sowie bei Bedarf, sobald Sie auf Refresh drücken. Purchase Orders und Supplier Invoices teilen sich ein einziges Lookback-Fenster, sodass kombinierte Ansichten und der Ausgabentrend niemals nicht übereinstimmende Zeiträume vermischen. Sowohl die TTL als auch das Lookback-Fenster sind pro Bereitstellung konfigurierbar:

Das Lookback-Fenster vs. Ihr Datumsfilter. Der Cache enthält Belege innerhalb des Lookback-Fensters (z. B. der letzten 25 Monate). Der Datumsfilter auf dem Dashboard grenzt ein, was Sie innerhalb der gecachten Daten sehen — er wird auf den Cache angewendet und löst keinen S/4HANA-Aufruf aus. Setzen Sie den Filter weiter zurück, als der Cache abdeckt, sind die älteren Belege noch nicht geladen, und das Dashboard zeigt ein Informationsbanner, das Sie zu einem Refresh auffordert, wodurch bis zum Startdatum Ihres Filters erneut aus S/4HANA geladen wird. Ein Datum innerhalb des Fensters verkleinert den Cache niemals.

Ist Global Display Currency aktiviert, werden Beträge für jede KPI, jedes Diagramm und jede Tabelle in Ihre gewählte Währung umgerechnet — siehe Währungsumrechnung.

Claude AI / MCP Access

Überblick

Spend Lens implementiert das Model Context Protocol (MCP) und ermöglicht Benutzern, Claude AI (claude.ai) mit ihrer Spend-Lens-Instanz zu verbinden und Beschaffungsdaten in natürlicher Sprache abzufragen. Benutzer authentifizieren sich mit ihren eigenen Anmeldeinformationen und sehen Daten gemäß ihren bestehenden Spend-Lens-Berechtigungen — es ist keine neue Rolle erforderlich. Alle Interaktionen sind schreibgeschützt; Claude kann keine Daten schreiben oder ändern.

Standardzustand: deaktiviert. Wenn Sie Spend Lens erstmals bereitstellen, ist der MCP-Zugriff ausgeschaltet und muss von einem Admin auf der Settings-Seite ausdrücklich aktiviert werden.

Einrichtung

1. Admin aktiviert MCP. Gehen Sie in Spend Lens zu Settings → Connection → AI / MCP Access und aktivieren Sie „Enable MCP Access". Dies ist ein globales Feature-Flag; das Deaktivieren trennt sofort alle aktiven Claude-Sitzungen.
2. MCP-URL finden. Es ist die App-URL mit angehängtem /mcp — z. B. https://asapio-spendlens.cfapps.eu10-004.hana.ondemand.com/mcp. Um Ihren eigenen Host zu finden, führen Sie cf app asapio-spendlens-approuter aus und verwenden Sie dessen Route.
3. Benutzer verbindet den MCP-Client. Öffnen Sie in Claude (Desktop oder Web, mit einem Plan, der eigene Connectors erlaubt) Settings → Connectors → Add custom connector, geben Sie die MCP-URL ein und bestätigen Sie. Claude startet einen OAuth-2.1-Login-Flow mit PKCE. Andere MCP-Clients (z. B. Microsoft Copilot / Copilot Studio, VS Code) verbinden sich auf dieselbe Weise — siehe Unterstützte Clients unten.
4. Einmalige Anmeldung. Claude öffnet ein Anmeldefenster; der Benutzer meldet sich mit seinen SAP/IAS-Anmeldeinformationen an (derselbe Identity Provider wie die Spend-Lens-Oberfläche). Spend Lens führt seinen eigenen OAuth-Authorization-Code-Flow direkt gegen IAS aus — es verwendet nicht den App-Router-Login, sodass der Flow innerhalb des Pop-up-Fensters von Claude funktioniert.
5. Autorisierung. Nach der Anmeldung stellt Spend Lens Claude ein opakes Access-Token und ein Refresh-Token aus. Diese sind Stellvertreter für die zugrunde liegenden XSUAA-Tokens — Claude sieht die SAP-Identitätstokens niemals direkt. Die Verbindung bleibt 30 Tage gültig und erneuert den S/4HANA-Zugriff automatisch im Hintergrund; danach autorisiert der Benutzer einmal erneut.
6. Claude fragt Spend Lens ab. Jede Anfrage enthält das Access-Token; der MCP-Server entschlüsselt das gespeicherte XSUAA-Token und ruft die internen CAP-OData-Services auf. Der bestehende asapio.spendlens.user- / asapio.spendlens.admin-Scope des Benutzers wird durchgesetzt — es ist keine spezielle MCP-Rolle erforderlich.

Was Claude leisten kann

Nach der Verbindung verfügt Claude über diese schreibgeschützten Tools. Jede analytische Antwort enthält zudem einen Deep Link zurück in die relevante Spend-Lens-Ansicht.

Zeitraum. Jedes analytische Tool deckt standardmäßig die letzten 90 Tage ab und gibt einen period-Block zurück, der genau angibt, welchen Bereich die Zahlen abdecken, sodass eine Antwort niemals mehrdeutig ist. Andere Bereiche sind über einen vordefinierten range-Parameter (mtd, lastMonth, qtd, lastQuarter, ytd, lastYear, allTime) oder ein explizites dateFrom/dateTo-Fenster verfügbar — passend zu den Datums-Presets des SpendLens-Dashboards.

Unterstützte Clients & Verbindung

Sie konfigurieren nur die eine MCP-URL (/mcp); alle OAuth-Endpunkte werden automatisch aus den Well-Known-Metadaten ermittelt (/.well-known/oauth-protected-resource und /.well-known/oauth-authorization-server). Der Server identifiziert Clients auf zwei Arten und wählt jene, die der Client verwendet:

• Client ID Metadata Document (CIMD) — verwendet von Claude, dessen client_id eine URL ist (claude.ai). Der Origin ist auf der Allowlist.
• Dynamic Client Registration (RFC 7591) — verwendet von Clients wie Microsoft Copilot / Copilot Studio und VS Code, die sich am registration_endpoint (/oauth/register) registrieren und eine generierte client_id erhalten. Nur öffentliche Clients (PKCE, kein Secret).

Die Registrierung ist eingegrenzt: Eine Redirect-URI wird nur akzeptiert, wenn ihr Host auf der Allowlist steht (claude.ai, copilot.microsoft.com, copilotstudio.microsoft.com, teams.microsoft.com, vscode.dev) oder es sich um eine http(s)://127.0.0.1-/localhost-Loopback-Adresse handelt (Desktop / VS Code). Jeder andere Host wird abgelehnt. Verwendet ein neuer MCP-Client einen anderen Callback-Host, fügen Sie ihn der Allowlist in srv/oauth/register.js hinzu.

Sicherheit

• OAuth 2.1 mit PKCE S256. Jeder Login-Flow verwendet eine PKCE-Code-Challenge zum Schutz vor dem Abfangen des Authorization Codes.
• Token-Verschlüsselung. Die XSUAA-Access- und -Refresh-Tokens werden in der Datenbank mit AES-256-GCM verschlüsselt gespeichert. Der Verschlüsselungsschlüssel wird aus dem XSUAA-Client-Secret via HKDF abgeleitet.
• Refresh-Token-Rotation. Wenn Claude sein Access-Token erneuert, wird das alte Refresh-Token invalidiert und ein neues ausgestellt.
• Kill-Switch. Ein Admin kann den MCP-Zugriff jederzeit unter Settings → Connection → AI / MCP Access deaktivieren. Das Deaktivieren der Funktion liefert allen aktiven Claude-Sitzungen sofort HTTP 401 zurück und löscht alle gespeicherten Sitzungen aus der Datenbank.
• Audit-Log. Jede MCP-Aktivierungs-/Deaktivierungsaktion wird im unveränderlichen Audit Log mit der Benutzer-ID des Admins und einem Zeitstempel aufgezeichnet.
• Keine Schreibvorgänge. Die MCP-Tools rufen nur schreibgeschützte CAP-OData-Funktionen auf. Claude kann keine Spend-Lens-Daten erstellen, aktualisieren oder löschen.
• Redirect-URI-Allowlist. Die Authorize- und Registrierungs-Endpunkte akzeptieren nur den CIMD-claude.ai-Callback oder Redirect-URIs, deren Host auf der Allowlist steht / eine Loopback-Adresse ist, und ein dynamisch registrierter Client darf nur eine von ihm registrierte Redirect-URI verwenden — was Open-Redirect-/SSRF-Angriffe verhindert.

Architekturhinweis: Spend Lens agiert als OAuth Authorization Server gegenüber claude.ai (Proxy-Modus) und zugleich als OAuth Client gegenüber XSUAA/IAS (mit einem eigenen Authorization-Code-Flow). Die tatsächliche Identität des Benutzers bleibt stets erhalten; Claude sieht dieselben Daten, die der Benutzer in der Spend-Lens-Oberfläche sehen würde.

Markenrechte

SAP, S/4HANA, SAP Fiori, SAP BTP und andere hier genannte SAP-Produkte sind Marken oder eingetragene Marken der SAP SE (oder eines mit SAP verbundenen Unternehmens) in Deutschland und anderen Ländern. Claude und Anthropic sind Marken von Anthropic, PBC. Das Model Context Protocol (MCP) ist ein von Anthropic eingeführtes offenes Protokoll. Microsoft und Microsoft Copilot Studio sind Marken der Microsoft-Unternehmensgruppe. Alle anderen Produkt- und Firmennamen sind Marken ihrer jeweiligen Inhaber.

ASAPIO Spend Lens ist ein eigenständiges Produkt der ASAPIO GmbH und steht in keiner Verbindung zu SAP SE, Anthropic, PBC oder Microsoft, wird von diesen weder unterstützt noch gesponsert. Marken werden ausschließlich zu Identifikations- und Beschreibungszwecken verwendet.