Digital Access und Indirect Access bei SAP: Drittanbieter-Integrationen lizenzrechtlich steuern

Jedes System, das über eine Schnittstelle Dokumente in SAP erstellt, kann eine Lizenzpflicht auslösen. SAP nennt das Digital Access. In der Praxis treffen diese Regeln die meisten Portfolios mit Drittanbieter-Integrationen, ohne dass das systematisch erfasst ist. Wer die neun Dokumenttypen kennt, die Unterscheidung zwischen Named User und Document-Based Licensing versteht und seinen Integrationsbestand dokumentiert, behält die Steuerung: und erkennt den Steuerungsmoment, bevor SAP ihn im Audit setzt.

Inhaltsverzeichnis

1. Was ist Indirect Access und was ist Digital Access?
2. Das Digital Access Adoption Program (DAAP)
3. Die neun Dokumenttypen: Welche Zugriffe eine Lizenzpflicht auslösen
4. Named User vs. Document-Based Licensing: Die zwei Wege zur Compliance
5. Digital Access in RISE-Verträgen: Was inkludiert ist und was nicht
6. Welche Drittanbieter-Systeme typischerweise Digital Access auslösen
7. Static Read, Export-Regel und andere Ausnahmen
8. RISE-Integrationslandschaft und BTP Integration Suite
9. Audit-Risiko: Wie SAP Indirect Access prüft und was auf dem Spiel steht
10. Compliance-Dokumentation: Der Integrationsbestand als Steuerungsbasis
11. Digital Access im Vertragswerk: Supplement, DAAP-Amendment, Order Form
12. Laufende Steuerung: Vier Steuerungsmomente bei Digital Access
13. FAQ
14. Nächste Schritte

---

Was ist Indirect Access und was ist Digital Access? {#was-ist-indirect-access-und-digital-access}

Wer heute mit SAP-Lizenzfragen konfrontiert ist, begegnet beiden Begriffen: Indirect Access und Digital Access. Sie werden in der Praxis häufig synonym verwendet. Sie beschreiben jedoch zwei unterschiedliche Phasen der SAP-Lizenzpolitik, und ihre Unterscheidung ist der Ausgangspunkt für jeden belastbaren Steuerungsmoment.

Indirect Access als historischer Begriff (vor 2018)

Indirect Access war bis 2018 der Sammelbegriff für alle Zugriffe auf SAP-Daten oder SAP-Funktionen, die nicht über eine direkte SAP-Anmeldesession erfolgen. Jedes Drittsystem, das über eine Schnittstelle mit SAP kommunizierte, konnte als indirekter Zugriff eingestuft werden, mit einer potenziellen Lizenzpflicht als Konsequenz.

Das Problem: Der Begriff war nie präzise definiert. Weder SAP noch die Kunden hatten eine einheitliche Antwort auf die Frage, wann genau ein Drittanbieter-System lizenzpflichtig war. Dieses Spannungsfeld führte zu jahrelanger Rechtsunsicherheit, die sich in öffentlich dokumentierten Rechtsstreitigkeiten mit Großkunden wie Diageo und AB InBev materialisierte (Quelle: Gartner Research). Die Klagen machten deutlich, dass das Indirect-Access-Modell in seiner undefinierten Form nicht tragfähig war.

Digital Access als Nachfolgemodell (seit 2018/2019)

SAP reagierte 2018 mit einem strukturell neuen Modell: Digital Access. Statt am Zugriff selbst setzt die Lizenzpflicht nun am Ergebnis dieses Zugriffs an. Entscheidend ist nicht mehr, ob ein Drittsystem mit SAP kommuniziert, sondern ob es dabei einen der neun definierten Dokumenttypen in SAP erstellt.

Das schafft eine wesentlich klarere Steuerungslogik. Lizenzpflicht entsteht durch das Erstellen bestimmter Dokument-Items, nicht durch den Zugriff als solchen. Messgröße ist das Dokumentvolumen, nicht die Nutzeranzahl.

Das Digital Access Adoption Program (DAAP) ermöglicht Kunden, historische Indirect-Access-Verpflichtungen in Document-Based Licensing zu überführen. Viele Kunden haben diesen Übergang noch nicht vollständig vollzogen.

Was sich in der Praxis ändert

Mit dem Wechsel zu Digital Access wurde Named User als Lizenzweg für Drittanbieter-Zugriffe nicht abgeschafft, sondern bleibt eine gleichwertige Option. Für Szenarien mit wenigen, identifizierbaren externen Nutzern ist Named User oft der einfachere Weg. Für hochvolumige, automatisierte oder anonyme Zugriffe bietet Document-Based Licensing eine wirtschaftlich attraktivere und betrieblich skalierbare Alternative.

Die Entscheidung zwischen den beiden Wegen erfordert ein vollständiges Integrations-Inventar. Das wiederum ist ein Steuerungsmoment, der in vielen Portfolios zum Zeitpunkt einer RISE-Migration oder eines Enhanced Audits erstmals systematisch bearbeitet wird.

Warum das Thema 2025 und 2026 an Relevanz gewinnt

Integrationslandschaften werden komplexer. CRM-Plattformen schreiben Aufträge in SAP, Warehouse-Management-Systeme buchen Warenbewegungen automatisiert, RPA-Bots verarbeiten Eingangsrechnungen, E-Commerce-Plattformen erzeugen täglich tausende Sales Orders. Jede dieser Integrationen ist potenziell ein Digital-Access-Trigger.

RISE-Migrationen bringen zusätzliche Dynamik: On-Premise-Integrationslandschaften werden in die Cloud überführt, ohne dass der Lizenzstatus jeder einzelnen Schnittstelle systematisch überprüft wird. Gleichzeitig erhöht das PCE Metering (Private Cloud Edition Metering) die Prüftiefe von SAP bei Cloud-Kunden erheblich. Die technische Infrastruktur für eine automatisierte Compliance-Prüfung ist auf SAP-Seite vorhanden. Auf Kundenseite ist sie in vielen Portfolios noch nicht im Steuerungsrhythmus verankert.

---

Das Digital Access Adoption Program (DAAP) {#daap}

Das DAAP ist die formale Vertragsgrundlage für den Wechsel von der historischen Indirect-Access-Logik auf das neue dokumentenbasierte Lizenzmodell. Viele Kunden haben das Programm noch nicht abgeschlossen. Teils weil der Bedarf nicht erkannt wurde, teils weil die RISE-Migration andere Prioritäten gesetzt hat.

Was DAAP ist

Das DAAP ist ein freiwilliges Programm, das SAP seit 2018 anbietet. Es erlaubt Kunden, historische Indirect-Access-Verpflichtungen einmalig und retrospektiv zu bereinigen und auf Document-Based Licensing umzusteigen. Das Ergebnis ist ein formales Amendment zum bestehenden SAP-Vertrag: das Digital Access Supplement.

Der Kern des Programms: SAP räumt für den Übergangszeitraum eine Amnestie für historische Unterlizenzierung ein, wenn der Kunde in Document-Based Licensing wechselt. Kunden erhalten damit Planbarkeit und Audit-Schutz für die abgedeckten Dokumenttypen.

Wie DAAP in der Praxis funktioniert

Das DAAP-Verfahren folgt einem strukturierten Ablauf. In einem ersten Schritt erfasst ein SAP-Measurement-Tool den aktuellen Dokumentvolumen über einen repräsentativen Messzeitraum. In einem zweiten Schritt verhandeln Kunde und SAP auf Basis dieses Volumens ein Dokumentkontingent, das die prognostizierte Nutzung für die Vertragslaufzeit abdeckt. Der dritte Schritt ist der formale Abschluss als Amendment: Das DAAP-Amendment definiert Kontingente, Overage-Regelungen und den Preis pro Dokument-Item.

Kunden, die diesen Weg gehen, verlassen die Grauzone der historischen Indirect-Access-Logik und erhalten eine belastbare Vertragsgrundlage für ihren Integrationsbestand.

Was vor einem DAAP-Abschluss zu prüfen ist

Wer in das DAAP-Programm eintritt, sollte diese Vorbereitungen abgeschlossen haben. Erstens: ein vollständiges Inventar aller Integrationen mit SAP-Schnittstelle, aufgeschlüsselt nach Dokumenttyp und Volumen. Zweitens: ein historischer Messungszeitraum von mindestens zwölf Monaten, um saisonale Schwankungen abzubilden. Drittens: Wachstumsannahmen für geplante Erweiterungen im Bereich RPA, E-Commerce oder neue Systemanbindungen. Viertens: eine Vergleichsrechnung Named User vs. Document-Based Licensing für jede Integrationsgruppe.

Wer in die Verhandlung geht, ohne diese Grundlagen zu haben, riskiert, ein Kontingent zu akzeptieren, das entweder zu niedrig angesetzt ist und kurzfristig Overage erzeugt, oder zu hoch dimensioniert ist und Budgetvolumen bindet, das gezielter eingesetzt werden könnte.

Wann DAAP nicht die richtige Lösung ist

Document-Based Licensing ist nicht in jedem Szenario das wirtschaftlich überlegene Modell. Bei Integrationen mit wenigen, vorhersehbaren externen Nutzern und begrenztem Transaktionsvolumen kann Named User der einfachere und kostengünstigere Weg sein. Die Entscheidungslogik hängt vom Verhältnis zwischen der Anzahl identifizierbarer Personen und dem Dokumentvolumen ab. Je mehr externe und anonyme Nutzer oder automatisierte Prozesse involviert sind, desto stärker spricht die Ökonomie für Digital Access.

---

Die neun Dokumenttypen: Welche Zugriffe eine Lizenzpflicht auslösen {#neun-dokumenttypen}

Digital Access ist ein dokumentenbasiertes Lizenzmodell. Die Lizenzpflicht entsteht nicht durch die Existenz einer Schnittstelle, sondern durch das Erstellen eines bestimmten Dokumenttyps in SAP über diese Schnittstelle. SAP hat genau neun solcher Dokumenttypen definiert.

Überblick der neun Dokumenttypen

Die neun Dokumenttypen, die bei Erstellung durch ein Drittsystem eine Digital-Access-Lizenzpflicht auslösen:

1. Sales Order Items: Verkaufsaufträge, die ein Drittsystem in SAP anlegt
2. Purchase Order Items: Bestellungen, die über eine externe Schnittstelle erstellt werden
3. Service Order Items: Serviceaufträge aus externen CRM- oder Feldservice-Systemen
4. Manufacturing Order Items: Fertigungsaufträge, die MES-Systeme in SAP schreiben
5. Invoice Items (Billing/AR): Ausgangsrechnungen oder Buchungspositionen aus externen Systemen
6. Payment Items (Incoming Payments): Zahlungsbuchungen aus Finanzportalen oder Treasury-Systemen
7. Goods Movement Items: Warenbewegungen, die WMS-Lösungen automatisiert buchen
8. Journal Entries: Journaleinträge, die RPA-Bots oder externe Buchhaltungssysteme erstellen
9. Inbound Delivery Items: Wareneingangsbuchungen aus Lieferanten- oder Logistikplattformen

Diese Liste ist abschließend. Dokumenttypen, die nicht in dieser Liste aufgeführt sind, lösen keine Digital-Access-Lizenzpflicht aus, unabhängig davon, welche anderen Datenoperationen ein Drittsystem in SAP durchführt.

Was einen Dokumenttyp-Trigger erzeugt

Drei Bedingungen müssen gleichzeitig erfüllt sein, damit ein Dokument-Item als lizenzpflichtig gilt. Erstens: Das Dokument wird von einem Drittsystem über eine SAP-Schnittstelle erstellt, BAPI, RFC, API, Webservice oder vergleichbar. Zweitens: Der Nutzer des Drittsystems ist nicht als SAP Named User lizenziert. Drittens: Das Drittsystem handelt nicht im Rahmen der Export-Regel, die im weiteren Verlauf erläutert wird.

Liegt eine dieser Bedingungen nicht vor, entsteht keine Digital-Access-Pflicht.

Volumen als Steuerungsgröße

Digital-Access-Lizenzen werden nicht pro System oder pro Schnittstelle, sondern pro Dokument-Item berechnet. Ein Purchase Order mit zehn Positionen erzeugt zehn lizenzpflichtige Items. Diese Granularität macht das Dokumentvolumen zur zentralen Planungsgröße.

Der Steuerungsmoment liegt in der Volumenkontrolle: Welche Integrationen erzeugen wie viele Items pro Monat? Wo wächst das Volumen? Wann ist das vertraglich vereinbarte Kontingent ausgeschöpft? Diese Fragen lassen sich nur beantworten, wenn der Integrationsbestand systematisch dokumentiert und das Volumen laufend beobachtet wird.

Praxisbeispiele nach Integrationstyp

Ein CRM-System, das täglich Verkaufsaufträge über die SAP-API anlegt, erzeugt Sales Order Items. Ein Warehouse-Management-System, das bei jedem Wareneingang automatisch eine Goods-Movement-Buchung schreibt, erzeugt Goods Movement Items. Ein RPA-Bot, der Eingangsrechnungen verarbeitet und Journal Entries in SAP erstellt, erzeugt Journal Entries. Eine E-Commerce-Plattform, die tausende Kundenbestellungen täglich als Sales Orders überträgt, erzeugt ein hohes Dokumentvolumen. In diesem Szenario ist Document-Based Licensing fast immer wirtschaftlich überlegen, weil Named User für anonyme Endkunden keine praktikable Option ist.

---

Named User vs. Document-Based Licensing: Die zwei Wege zur Compliance {#named-user-vs-document-based}

Digital Access und Named User Licensing sind zwei gleichwertige Wege, die Lizenzpflicht aus Drittanbieter-Integrationen zu erfüllen. Welcher Weg der richtige ist, hängt vom spezifischen Integrationsszenario ab. Die Entscheidung ist kein einmaliges Ereignis, sondern ein laufender Steuerungsmoment.

Named User als klassischer Weg

Im Named-User-Modell werden die Nutzer des Drittsystems als SAP-Named-User lizenziert. Das ist der klassische Weg und ist dann wirtschaftlich sinnvoll, wenn die Nutzer bekannt, identifizierbar und in überschaubarer Zahl vorhanden sind.

Typisches Szenario: Ein Controlling-Tool, das fünf Mitarbeiter nutzen, die im Rahmen ihrer Arbeit Buchungen in SAP auslösen. Diese fünf Personen können einfach als SAP-Nutzer erfasst und entsprechend lizenziert werden. Der administrative Aufwand ist gering, die Kosten sind planbar.

Named User stößt an seine Grenzen, wenn die Nutzeranzahl groß ist, die Nutzer anonym sind (Kunden, Lieferanten) oder der Zugriff vollständig automatisiert erfolgt. In diesen Szenarien ist Document-Based Licensing die überlegene Option.

Document-Based Licensing (Digital Access)

Im Document-Based-Modell entsteht die Lizenzpflicht nicht durch die Personen, sondern durch das, was sie oder ihre Systeme in SAP erzeugen. Lizenziert wird das Dokumentvolumen, nicht die Nutzerzahl.

Das Modell ist skalierbar und ermöglicht es, auch anonyme externe Nutzer oder vollständig automatisierte Prozesse rechtskonform abzubilden. Ein E-Commerce-Betrieb mit zehntausend Kundenbestellungen pro Tag kann diese Bestellungen als Sales Order Items lizenzieren, ohne jeden einzelnen Endkunden als SAP-Nutzer erfassen zu müssen.

Der strukturelle Vorteil: Die Skalierbarkeit. Der strukturelle Aufwand: Dokumentvolumen muss gemessen, dokumentiert und im Steuerungsrhythmus beobachtet werden. Wer das Volumen nicht kennt, kann kein belastbares Kontingent verhandeln.

Entscheidungsmatrix

Die Entscheidung zwischen den beiden Wegen folgt einer klaren Logik.

Bei wenigen bekannten Nutzern und niedrigem Transaktionsvolumen ist Named User in der Regel einfacher und günstiger. Bei vielen oder anonymen Nutzern und hohem Volumen ist Document-Based Licensing wirtschaftlich überlegen. In Hybridszenarien sind beide Wege nebeneinander möglich: Einige Systeme werden über Named User abgebildet, andere über Document-Based Licensing. Diese Hybridlösung muss im Vertrag klar getrennt geregelt sein.

Entscheidend: Die Entscheidung ist nicht dauerhaft. Wenn eine Integration wächst oder neue Nutzergruppen hinzukommen, kann der ursprünglich sinnvolle Weg wirtschaftlich nachteilig werden. Die Überprüfung ist ein wiederkehrender Steuerungsmoment im Bereich Berechtigungen.

Der Steuerungsmoment "Berechtigungen" bei Digital Access

Berechtigungen sind im FinOptory-Modell einer der vier Steuerungsmomente-Bereiche. Digital Access macht deutlich, warum dieser Bereich mehr umfasst als interne Nutzerzuordnungen. Berechtigungen schließen die Frage ein, welche Schnittstellen welche Dokumenttypen in SAP erstellen dürfen und auf welcher Lizenzgrundlage.

Wer eine neue Integration einführt, ohne zu klären, ob sie Named User oder Digital Access erfordert, schafft eine Compliance-Lücke. Wer eine bestehende Integration erweitert, ohne das Lizenzmodell zu überprüfen, riskiert Overage. Die Governance dieser Schnittstellen ist Berechtigungs-Steuerung, kein rein technisches Thema.

---

Digital Access in RISE-Verträgen: Was inkludiert ist und was nicht {#digital-access-rise}

Eine der häufigsten Fehleinschätzungen in RISE-Portfolios: Digital Access sei im RISE-Vertrag vollständig abgedeckt. Für interne Integrationen trifft das in Enterprise-Agreement-Strukturen oft zu. Für externe Systeme, Partner-Portale und IoT-Plattformen gilt das in der Regel nicht. Die Abgrenzung liegt im Vertragstext, nicht im Marketing-Material.

Die Grundregel in RISE Enterprise Agreements

In RISE-Verträgen mit Enterprise Agreement ist Digital Access für interne Integrationen häufig unbegrenzt enthalten. "Intern" bedeutet in diesem Kontext: Systeme, die vom selben juristischen Vertragspartner betrieben werden und unter denselben Vertrag fallen.

Diese Inklusion schafft einen bedeutenden Steuerungsmoment für RISE-Kunden. Wenn interne Systeme unbegrenzte Dokumentvolumina erzeugen können, ohne gesonderte Digital-Access-Kosten, lässt sich die Integrationslandschaft für interne Prozesse freier gestalten.

Was "unbegrenzt inkludiert" in der Praxis bedeutet

Die Formulierung "unbegrenzt inkludiert" verdient eine sorgfältige Lektüre. Sie bezieht sich auf die Dokumentvolumina für interne Systeme im definierten Geltungsbereich. Sie schließt nicht automatisch die Infrastrukturkosten ein, die bei wachsendem Integrationsvolumen entstehen, insbesondere BTP-Credits für Middleware-Services.

Zudem ist die Definition von "intern" vs. "Affiliate" vs. "externe Partei" vertragsabhängig und muss im konkreten Digital Access Supplement nachgelesen werden. Was im Marketing-Gespräch als "unbegrenzt" klingt, kann im Vertragstext eng gefasst sein.

Was in RISE nicht automatisch inkludiert ist

Vier Kategorien fallen typischerweise aus der EA-Inklusion heraus.

Erstens: Integrationen mit Drittparteien außerhalb des EA-Geltungsbereichs. Wenn ein Lieferant oder Logistikpartner über eine Schnittstelle Buchungen in SAP erzeugt, gilt er in der Regel nicht als "intern" im Sinne des EA.

Zweitens: Integrationen über externe SaaS-Plattformen, die nicht selbst Vertragspartner sind. Eine extern betriebene E-Commerce-Plattform, die Bestellungen an SAP überträgt, ist typischerweise nicht von der EA-Inklusion abgedeckt.

Drittens: IoT-Plattformen und Connected-Manufacturing-Lösungen mit hohem Dokumentvolumen. Diese Systeme erzeugen oft sehr hohe Mengen an Goods Movement Items oder Manufacturing Order Items, und sind selten vertraglich als interne Systeme erfasst.

Viertens: Kunden-Portale und Partnerplattformen für B2B-Integration. Wenn Kunden oder Lieferanten über einen Portal-Zugang Bestellungen oder Warenbewegungen auslösen, ist das kein interner Systemzugriff im rechtlichen Sinne.

RISE mit älterem Vertragsstand

Kunden, die vor 2019 On-Premise-Verträge hatten und auf RISE migriert sind, haben möglicherweise nicht das aktuelle Digital-Access-Supplement oder das DAAP-Amendment. Die Migration auf RISE bedeutet nicht automatisch, dass alle älteren Vertragsbestandteile durch neue Standardbedingungen ersetzt wurden.

Ein Vertragsgenerationscheck ist in diesem Fall ein unverzichtbarer Steuerungsmoment: Welche GTC-Version gilt? Welcher Supplement-Stand? Ist das DAAP-Amendment abgeschlossen? Diese Fragen sollten vor dem nächsten Enhanced Audit und möglichst vor dem nächsten Renewal beantwortet sein.

Der Steuerungsmoment "Nutzung" in RISE

Nutzung ist im FinOptory-Modell einer der vier Steuerungsmomente-Bereiche. Bei Digital Access in RISE-Portfolios bedeutet das konkret: Das Dokumentvolumen pro Integration ist eine Nutzungsmetrik, die neben FUE-Verbräuchen systematisch beobachtet werden sollte.

Welche Integrations-Systeme haben im letzten Quartal wie viele Dokumente erstellt? Welche Systeme nähern sich dem Kontingent? Welche neuen Integrationen wurden eingeführt, ohne ihren Digital-Access-Status zu klären? Diese Fragen sind Teil des laufenden Steuerungsrhythmus.

---

Welche Drittanbieter-Systeme typischerweise Digital Access auslösen {#drittanbieter-systeme}

Die Frage, welche Systeme im eigenen Portfolio Digital Access auslösen, lässt sich nicht pauschal beantworten. Sie erfordert einen Blick auf die konkrete Integrationsarchitektur. Einige Systemkategorien sind jedoch so häufig vertreten, dass ihre Einordnung als Orientierungsrahmen dient.

CRM-Systeme (Sales Order Trigger)

CRM-Plattformen, die Vertriebsprozesse unterstützen, erstellen in der Regel Angebote und Aufträge, und übertragen diese in vielen Systemarchitekturen automatisiert als Sales Orders oder Service Orders in SAP. Der Trigger liegt beim Erstellen dieser Positionen in SAP über die CRM-Schnittstelle.

Das Volumen hängt von der Transaktionsdichte im Vertrieb ab. Bei Unternehmen mit hohem Auftragsvolumen kann dieses Szenario schnell in DAAP-relevante Größenordnungen wachsen.

Warehouse-Management-Systeme (WMS)

WMS-Lösungen, die Wareneingänge, Umlagerungen und Versandprozesse steuern, buchen Warenbewegungen und Lieferpositionen in SAP. Das löst Goods Movement Items und Inbound Delivery Items aus.

In Logistik-intensiven Unternehmen ist die Taktrate hoch. Ein Lager mit mehreren hundert Warenbewegungen täglich erzeugt ein Dokumentvolumen, das Named User als Lizenzweg wirtschaftlich ausschließt. Document-Based Licensing ist hier der Standardansatz.

Manufacturing Execution Systems (MES)

MES-Systeme schreiben Fertigungsaufträge, Rückmeldungen und Materialbewegungen in SAP. Die Trigger sind Manufacturing Order Items und Goods Movement Items.

In der Produktion ist die Dokumentfrequenz oft sehr hoch. Rückmeldungen von Fertigungslinien können in Echtzeit in SAP übertragen werden, mit entsprechendem Volumen.

E-Commerce und Portale

Online-Shop-Plattformen, die Kundenbestellungen direkt als Sales Orders in SAP anlegen, sind ein klassisches Digital-Access-Szenario. Die Endkunden sind anonym und nicht als Named User lizenzierbar. Das Volumen skaliert mit dem Geschäftswachstum.

Bei kundenseitigem Portal-Zugang, bei dem Geschäftskunden Bestellungen oder Serviceanfragen selbst erfassen, gilt dasselbe Prinzip: Named-User-Lizenzierung für externe Kunden ist in der Praxis nicht handhabbar. Document-Based Licensing ist der strukturell richtige Weg.

RPA und Prozessautomatisierung

Robotic Process Automation ist einer der am häufigsten übersehenen Digital-Access-Trigger. Bots haben keinen Named User und sind vollständig automatisiert. Sie erzeugen je nach Konfiguration Invoice Items, Journal Entries, Payment Items oder Purchase Order Items.

SAP hat für bestimmte RPA-Bots eigene kostenlose Lizenzkategorien definiert (SAP IRPA Typ 68 und Drittanbieter-RPA Typ 69). Bots, die unter diese Kategorien fallen und korrekt klassifiziert sind, lösen keine Digital-Access-Pflicht aus. Bots außerhalb dieser Kategorien oder mit anderen Authentifizierungsmodellen müssen gesondert bewertet werden.

Finanzportale und Treasury-Systeme

Treasury-Management-Systeme und Factoring-Plattformen, die Zahlungen und Journal Entries in SAP buchen, erzeugen Payment Items und Journal Entries. Das Volumen ist hier nicht unbedingt hoch, aber die finanziellen Beträge pro Buchung können erheblich sein. Die Lizenzpflicht richtet sich nach dem Dokumentvolumen, nicht nach dem Euro-Betrag.

Lieferanten- und Einkaufsplattformen

Einkaufsportale, über die Lieferanten Bestellbestätigungen oder Lieferavise zurückspielen, können Purchase Order Items oder Inbound Delivery Items erzeugen. Ein Sonderfall ist SAP Ariba: Ariba hat eigene Transaktionsgebühren, die unabhängig von Digital Access anfallen. Ob zusätzlich Digital Access entsteht, hängt von der konkreten Integrationsarchitektur ab und ist gesondert zu prüfen.

---

Static Read, Export-Regel und andere Ausnahmen {#ausnahmen}

Digital Access gilt nicht für alle Formen der SAP-Integration. Es gibt klar definierte Ausnahmen, deren korrekte Einordnung sowohl Compliance-Lücken als auch unnötige Lizenzkosten vermeidet.

Static Read: keine Lizenzpflicht

Wenn ein Drittsystem ausschließlich lesend auf SAP-Daten zugreift, also Daten abruft, ohne etwas in SAP zurückzuschreiben oder zu erstellen, entsteht keine Digital-Access-Lizenzpflicht.

Typisches Beispiel: Ein Reporting-Dashboard, das SAP-Daten über eine API ausliest und visualisiert. Solange dieses System keine Dokument-Items erstellt, bleibt der Zugriff lizenzrechtlich unproblematisch.

Die entscheidende Grenzlinie liegt beim "Erstellen". Ein System, das Daten liest und darstellt, aber nichts in SAP schreibt, löst keine Lizenzpflicht aus.

Die Export-Regel

Die Export-Regel ist eine wichtige Ausnahme für automatisierte Prozesse. Wenn ein lizenzierter SAP-Nutzer einen automatisierten Export-Prozess definiert und initiiert hat, und dieser Prozess danach automatisch ohne menschliche Intervention läuft, entsteht für den automatischen Teil keine zusätzliche Digital-Access-Pflicht.

Die Bedingung: Der lizenzierte Nutzer muss den Prozess eingerichtet haben. Die Berechtigung für den Export muss im Kontext dieses Nutzers liegen.

Typischer Anwendungsfall: Ein SAP-Nutzer legt einen Report oder einen Datenexport an, der täglich per Job automatisch ausgeführt wird. Dieser Job läuft im Kontext des initialen Nutzers und gilt als dessen lizenzierter Zugriff.

Die Grauzone: Bei komplexen Workflows, bei denen mehrere Schritte automatisiert ablaufen und der ursprüngliche Nutzer-Kontext über mehrere Systemgrenzen weitergereicht wird, ist die Zuordnung nicht immer eindeutig. Hier empfiehlt sich eine vertragliche Klärung, bevor der Workflow in Produktion geht.

Batch Processing und RFC

Batch-Prozesse, die über RFC im Kontext eines technischen System-Users laufen, sind lizenzrechtlich komplex einzuordnen. Entscheidend ist, wem der System-User zugeordnet ist und ob dieser User eine Named-User-Lizenz trägt.

Technische User ohne Named-User-Lizenz können Digital-Access-Pflichten auslösen, wenn sie Dokument-Items in SAP erstellen. Die Bezeichnung "technischer User" oder "System-User" ist kein automatischer Schutz vor Lizenzpflicht. Die Lizenzgrundlage muss geprüft werden.

Testumgebungen

SAP prüft im Enhanced Audit typischerweise das Produktivsystem. Testumgebungen und Sandboxes sind in vielen Verträgen explizit ausgenommen. Ob das im konkreten Vertrag so geregelt ist, muss jedoch im Vertragstext nachgelesen werden.

Bei Testumgebungen, die produktionsnahe Datenvolumina verarbeiten oder als Lasttestumgebung genutzt werden, kann die Lizenzfrage relevant werden. Auch hier gilt: Vertragstext vor Annahme.

---

RISE-Integrationslandschaft und BTP Integration Suite {#rise-btp}

In RISE-Portfolios wird die SAP Integration Suite auf BTP häufig als zentrale Middleware für Drittanbieter-Anbindungen eingesetzt. Das beeinflusst die Digital-Access-Betrachtung auf zwei Ebenen: auf der Ebene der Lizenzierung und auf der Ebene der Infrastrukturkosten.

BTP Integration Suite als Integrationsschicht

Die SAP Integration Suite ist ein BTP-Service und wird über CPEA-Credits lizenziert. Sie fungiert als Middleware zwischen SAP-Kernsystemen und Drittanbieter-Lösungen.

Wichtige Unterscheidung: BTP-Integration-Credits und Digital-Access-Lizenzierung sind zwei getrennte Themen. Der Betrieb einer Integration über die BTP Integration Suite ist ein BTP-Credit-Verbrauch. Die Lizenzpflicht für die dabei erzeugten Dokument-Items ist eine Digital-Access-Frage. Beide Dimensionen müssen in der Kostenplanung zusammengeführt werden. Sie beeinflussen einander, sind aber rechtlich und kommerziell voneinander unabhängig.

Integrationsvolumen und BTP-Credit-Verbrauch

Wenn eine Integration über BTP Integration Suite betrieben wird und hohe Dokumentvolumina erzeugt, steigen gleichzeitig der BTP-Credit-Verbrauch und das Digital-Access-Volumen. Wer hohe Integrationsvolumina plant, sollte beide Positionen in der Vertragsstrategie berücksichtigen.

In der Praxis werden diese beiden Themen in Vertragsverhandlungen häufig getrennt behandelt, obwohl sie operativ zusammenhängen. Ein vollständiger Steuerungsmoment im Bereich Infrastruktur schließt beide ein.

Externe Integrationsplattformen (iPaaS)

Nicht jedes Unternehmen nutzt BTP als Middleware. MuleSoft, Boomi, Informatica, Azure Integration Services und andere Plattformen sind ebenfalls verbreitet. Diese Entscheidung ändert die Digital-Access-Frage nicht. Das Trigger-Ereignis ist das Erstellen eines Dokument-Items in SAP, nicht die verwendete Middleware. Eine Integration über MuleSoft, die Sales Orders in SAP erstellt, löst dieselbe Lizenzpflicht aus wie eine identische Integration über BTP Integration Suite.

Ein praktischer Unterschied liegt in der Sichtbarkeit: Das Integrations-Inventar von externen iPaaS-Plattformen kann unvollständiger sein, weil externe Plattformen nicht automatisch in das SAP-Lizenzmonitoring eingebunden sind.

Der Steuerungsmoment "Infrastruktur" bei Digital Access

Infrastruktur ist im FinOptory-Modell einer der vier Steuerungsmomente-Bereiche. Bei Digital Access konkretisiert er sich in der Frage: Welche Schnittstellen sind aktiv? Welche Middleware verwaltet welche Integration-Flows? Welche Middleware-Wechsel haben den Lizenzstatus verändert?

Ein Middleware-Wechsel, beispielsweise von SAP PI/PO auf BTP Integration Suite im Rahmen einer RISE-Migration, kann den Lizenzstatus einer Integration verändern, wenn dabei neue Dokumenttypen geschrieben oder neue Systemkonstellationen entstehen. Die Integrationsarchitektur-Dokumentation ist die Voraussetzung für eine funktionierende Digital-Access-Governance.

---

Audit-Risiko: Wie SAP Indirect Access prüft und was auf dem Spiel steht {#audit-risiko}

Im Enhanced Audit analysiert SAP die Integrationslandschaft explizit. Wer seinen Integrationsbestand dokumentiert hat und den Digital-Access-Status jeder Schnittstelle kennt, geht mit einer deutlich stärkeren Position in das Gespräch.

Wie SAP Digital Access im Enhanced Audit prüft

Der Enhanced Audit findet typischerweise alle zwei bis drei Jahre statt oder wird anlassbezogen eingeleitet, vor Renewal-Verhandlungen, bei M&A-Transaktionen oder nach auffälligen Basic-Audit-Ergebnissen.

Im Rahmen des Enhanced Audits fordert SAP eine vollständige Liste aller Drittsysteme mit SAP-Schnittstellen an. Transaktionslogs und Dokumentvolumina werden ausgewertet. Systeme, die Dokument-Items in SAP erstellen, ohne Named-User-Lizenz oder DAAP-Supplement als Grundlage zu haben, werden als Compliance-Lücken markiert.

Das SAP-Audit-Team (Global License Auditing) hat die Methodik, Integrations-Topologien zu rekonstruieren, auch wenn die Dokumentation auf Kundenseite lückenhaft ist. Transaktionslogs in SAP enthalten ausreichend Informationen, um zu ermitteln, welche technischen User welche Dokumenttypen erstellt haben.

Finanzielles Exposure bei Indirect-Access-Findings

Die finanziellen Konsequenzen eines Indirect-Access-Findings setzen sich aus mehreren Positionen zusammen.

Erstens: Nachkauf der fehlenden Digital-Access-Lizenzen zum aktuellen Listenpreis, ohne Bestandsrabatte. Zweitens: Retroaktive Dokumentlizenzgebühren für den Prüfzeitraum, typischerweise zwei bis drei Jahre. Bei On-Premise-Verträgen ohne DAAP-Supplement: retroaktive Named-User-Lizenzierung aller identifizierten externen Nutzer.

In der öffentlichen Literatur sind Findings bei High-Volume-Integrationen mit substantiellen sechsstelligen oder siebenstelligen Beträgen dokumentiert (Redress Compliance, JNC UK). Das spezifische Exposure hängt vom Dokumentvolumen, der Laufzeit der nicht lizenzierten Nutzung und den vertraglich vereinbarten Listenpreisen ab.

Wann das Audit-Risiko erhöht ist

Vier Konstellationen verdienen besondere Aufmerksamkeit.

Erstens: E-Commerce-Plattformen mit hohem Bestellvolumen, für die keine Digital-Access-Dokumentation vorliegt. Zweitens: RPA-Rollouts, bei denen der Digital-Access-Status der eingesetzten Bots vor dem Go-Live nicht geprüft wurde. Drittens: RISE-Migrationen, bei denen der mitgebrachte On-Premise-Integrationsbestand keinen Lizenzreview durchlaufen hat. Viertens: M&A-Transaktionen, bei denen ein akquiriertes Unternehmen eigene SAP-Integrationen mitbringt, die nicht dem DAAP-Stand des übernehmenden Unternehmens entsprechen.

Audit-Einladung als Verhandlungssignal

Enhanced Audits werden in der Praxis häufig vor Renewal-Verhandlungen eingeleitet. SAP nutzt Audit-Ergebnisse als kommerziellen Ausgangspunkt für Lizenz-Nachkäufe und Upgrades.

Wer mit einem dokumentierten Integrationsbestand und einem abgeschlossenen DAAP-Supplement in das Audit geht, begrenzt das Exposure und gestaltet die Verhandlungsposition aktiv. Fehlende Compliance gibt SAP die Möglichkeit, Nachkäufe als Teil der Renewal-Verhandlung zu platzieren. Das verändert die Dynamik der Verhandlung erheblich.

---

Compliance-Dokumentation: Der Integrationsbestand als Steuerungsbasis {#compliance-dokumentation}

Die wichtigste Grundlage für Digital-Access-Governance ist ein vollständiges, gepflegtes Integrationsregister. Es ist kein Audit-Dokument, das einmalig erstellt und abgelegt wird. Es ist ein lebendes Werkzeug im Steuerungsrhythmus.

Schritt 1: Integrationslandschaft erfassen

Der erste Schritt ist die vollständige Inventarisierung. Welche Systeme haben eine Schnittstelle zu SAP? Für jede Schnittstelle: In welche Richtung fließen Daten? Werden Dokumenttypen in SAP erstellt, und wenn ja welche? Welches Volumen erzeugt die Integration pro Monat? Wer nutzt das Drittsystem: interne Mitarbeiter, externe Kunden, Lieferanten, Bots?

Quellen für diese Erhebung sind IT-Architektur-Dokumente, Middleware-Konfigurationen, Schnittstellen-Register und, oft unterschätzt, Rechnungen und Order Forms aus vergangenen SAP-Verhandlungen, in denen bestimmte Integrationsbestandteile bereits kommerziell berücksichtigt worden sein können.

Schritt 2: Lizenzstatus pro Integration prüfen

Für jede erfasste Integration ist die Frage zu beantworten: Welche Lizenzgrundlage existiert? Named-User-Lizenz, Digital-Access-Supplement (DAAP-Amendment) oder eine anerkannte Ausnahme wie Static Read oder die Export-Regel?

Integrationen ohne Lizenzgrundlage sind als Lücken zu dokumentieren und zu priorisieren. Nicht jede Lücke hat dasselbe Risikoprofil. Volumen und Dokumenttyp bestimmen das finanzielle Exposure.

Schritt 3: Entscheidung Named User vs. Digital Access

Für jede Lücke ist zu entscheiden, welcher Lizenzweg der richtige ist. Named User oder Document-Based Licensing? Die Entscheidungsgrundlage sind die Nutzerbasis, das Dokumentvolumen und die erwartete Wachstumskurve.

Diese Entscheidung sollte dokumentiert werden, nicht nur getroffen. Im Audit ist die Nachvollziehbarkeit der Entscheidungslogik mindestens genauso wichtig wie das Ergebnis.

Schritt 4: DAAP-Verhandlung oder Named-User-Nachlizenzierung

Das Ergebnis aus Schritt 3 wird in eine Vertragsänderung überführt: DAAP-Amendment für Document-Based-Lücken oder Named-User-Ergänzung für identifizierbare Nutzer-Szenarien.

Für DAAP: Der historische Zeitraum der Unterlizenzierung sollte im Rahmen der DAAP-Verhandlung explizit bereinigt werden. Das DAAP-Programm sieht dafür eine Amnestie-Option vor, die den Nachkauf von retroaktiven Lizenzgebühren ersetzen kann.

Schritt 5: Laufende Dokumentation im Steuerungsrhythmus

Das Integrationsregister ist kein statisches Dokument. Es wird im Steuerungsrhythmus geführt. Neue Integrationen durchlaufen eine Lizenzprüfung vor dem Go-Live. Bestehende Integrationen werden quartalsweise auf Volumenentwicklung und Statusveränderungen überprüft. Geplante Erweiterungen, neue RPA-Deployments, neue API-Anbindungen, RISE-Migrations-Scope-Erweiterungen, werden vor der Umsetzung auf Digital-Access-Relevanz bewertet.

Dieser Rhythmus ist kein Zusatzaufwand. Er ist Teil des systematischen Steuerungsansatzes, der Compliance-Lücken verhindert, bevor sie entstehen.

---

Digital Access im Vertragswerk: Supplement, DAAP-Amendment, Order Form {#vertragswerk}

Digital Access ist nicht nur eine Frage der Technologie, sondern eine Frage des Vertragswerks. Wer die relevanten Vertragsdokumente kennt, kann die eigene Compliance-Position einschätzen und weiß, wo Klärungsbedarf besteht.

Das Digital Access Supplement

Das Digital Access Supplement ist ein separates Supplement zum SAP-Hauptvertrag. Es definiert: den Geltungsbereich der neun Dokumenttypen, die vereinbarten Dokumentkontingente, die Overage-Regelungen bei Kontingentüberschreitung und die Preis-pro-Dokument-Item-Struktur.

Ohne Digital Access Supplement gibt es keine vertragliche Grundlage für Document-Based Licensing. Das bedeutet im Umkehrschluss: Wer kein Supplement hat und dennoch Dokument-Items über Drittanbieter erstellt, befindet sich in einem lizenzrechtlichen Graubereich, oder ist auf Named User angewiesen.

Alle aktuellen SAP-Vertragstemplates sind öffentlich einsehbar im SAP Trust Center unter sap.com/about/trust-center/agreements.html.

DAAP als Amendment

Der DAAP-Abschluss materialisiert sich als formales Amendment zum bestehenden Vertrag. Dieses Amendment enthält: Dokumentkontingente für die vereinbarte Laufzeit, den Overage-Preis für Kontingentüberschreitungen, die Retrospektiv-Regelung für den historischen Zeitraum und die Definition des Geltungsbereichs.

Die Hierarchie im Vertragswerk: Amendment hat Vorrang vor Supplement, Supplement hat Vorrang vor GTC. Wenn das DAAP-Amendment Aussagen trifft, die vom Digital Access Supplement abweichen, gilt das Amendment.

Was in der Order Form steht

Dokumentkontingente erscheinen als eigene Positionen in der Order Form. Je nach Verhandlungsergebnis werden sie nach Dokumenttypen getrennt aufgeführt oder als Gesamtkontingent zusammengefasst. Preis pro Dokument-Item und Overage-Rate müssen explizit im Order Form stehen, sie ergeben sich nicht automatisch aus Standardbedingungen.

Für den Steuerungsmoment im Bereich Kosten ist die Order Form die zentrale Referenz: Was ist vertraglich vereinbart, was wird tatsächlich verbraucht, und wo droht Overage?

Kritische Vertragsklausel: Geltungsbereich des Enterprise Agreements

Die wichtigste Klausel im Digital-Access-Supplement ist die Definition des Geltungsbereichs. Welche juristischen Einheiten fallen unter das Enterprise Agreement? Welche Systeme gelten als "interne Systeme" im Sinne der EA-Inklusion? Sind Outsourcing-Partner, Konzerngesellschaften und Joint Ventures eingeschlossen oder nicht?

Diese Definition bestimmt, welche Integrationen kostenlos unter die EA-Inklusion fallen und welche separat lizenziert werden müssen. Je weiter der Geltungsbereich im Vertrag definiert ist, desto mehr Integrationen sind von der Nachkauf-Pflicht ausgenommen.

Contract Manager und Procurement sollten den Geltungsbereich so weit wie möglich definieren, bevor die Integrationslandschaft weiter wächst. Nach Vertragsabschluss ist eine Nachverhandlung dieses Punktes deutlich aufwändiger.

---

Laufende Steuerung: Vier Steuerungsmomente bei Digital Access {#steuerungsmomente}

Digital Access ist kein einmaliges Compliance-Projekt. Es ist ein laufender Steuerungsgegenstand, der in jedem der vier Steuerungsmomente-Bereiche von FinOptory eine konkrete Ausprägung hat. Wer diese Steuerungsmomente systematisch wahrnimmt, behält die Kontrolle über Compliance und Kosten und geht in jede SAP-Interaktion vorbereitet.

Die vier Steuerungsmomente-Bereiche sind: Nutzung, Berechtigungen, Infrastruktur und Kosten. Bei Digital Access hat jeder dieser Bereiche einen spezifischen Anwendungsfall.

Steuerungsmoment "Nutzung": Dokumentvolumen beobachten

Der Steuerungsmoment im Bereich Nutzung fragt: Welche Integrationen produzieren wie viele Dokument-Items pro Monat, und wie entwickelt sich dieses Volumen?

Konkret bedeutet das: Volumentracking pro Integration im Steuerungsrhythmus. Welche Systeme nähern sich dem Kontingent? Wo gibt es Wachstumstrends, die auf eine Overage-Situation in den nächsten Quartalen hindeuten? Welche Integrationen haben unerwartete Volumensteigerungen gezeigt?

Die Overage-Prognose ist ein konkretes Ergebnis dieses Steuerungsmomentes. Sie ermöglicht ein proaktives Handeln: entweder eine Kontingenterhöhung zu verhandeln oder betriebliche Maßnahmen zu ergreifen, bevor Overage-Gebühren entstehen.

Steuerungsmoment "Berechtigungen": Integrationslandschaft steuern

Der Steuerungsmoment im Bereich Berechtigungen fragt: Welche Schnittstellen dürfen welche Dokumenttypen in SAP erstellen, und ist die Lizenzgrundlage für jede dieser Schnittstellen dokumentiert?

Neue Integrationen müssen vor dem Go-Live eine Lizenzprüfung durchlaufen. Das ist kein optionaler Schritt, sondern ein Pflichtschritt im Einführungsprozess. Wer eine neue Schnittstelle ohne vorherige Klärung in Betrieb nimmt, schafft eine Compliance-Lücke.

Gleichzeitig gibt es einen positiven Steuerungsmoment: Inaktive Integrationen. Welche Schnittstellen sind lizenziert, aber nicht aktiv? Eine systematische Bereinigung inaktiver Integrationen kann Kontingente freisetzen und die Kostenentwicklung verbessern.

Steuerungsmoment "Infrastruktur": Middleware und Schnittstellen-Inventar

Der Steuerungsmoment im Bereich Infrastruktur fragt: Welche Middleware verwaltet welche Integrationsflows, und hat eine Veränderung der Integrationsarchitektur den Digital-Access-Status einzelner Schnittstellen beeinflusst?

Middleware-Wechsel, neue Schnittstellentypen und RISE-Migrationen können den Lizenzstatus verändern. Wer die Infrastruktur verändert, ohne den Digital-Access-Status der betroffenen Integrationen zu prüfen, riskiert unbemerkte Compliance-Lücken.

Das Integrationsregister ist das operative Werkzeug dieses Steuerungsmomentes. Es muss Veränderungen in der Infrastruktur zeitnah widerspiegeln.

Steuerungsmoment "Kosten": Rechnungsabgleich und Overage-Kontrolle

Der Steuerungsmoment im Bereich Kosten fragt: Stimmen die berechneten Digital-Access-Gebühren in der SAP-Rechnung mit dem gemessenen Dokumentvolumen überein, und wie verhält sich der aktuelle Verbrauch zum Kontingent?

Digital-Access-Gebühren erscheinen in der SAP-Rechnung als eigene Position. Der Abgleich zwischen Rechnungsbetrag und eigenem Volumentracking ist ein routinemäßiger Prüfschritt. Abweichungen können auf Berechnungsunterschiede zwischen dem SAP-Messsystem und dem eigenen Tracking hinweisen.

Der konkrete Budget-Alert liegt bei 80 Prozent Kontingentauslastung: Wenn ein Integrations-Kontingent zu 80 Prozent ausgeschöpft ist, sollte der Forecast für das verbleibende Vertragsjahr angepasst werden.

Warum Governance nach Vertragsabschluss entscheidend ist

Der Vertrag legt Kontingente fest. Die betriebliche Realität entwickelt sich weiter. Neue Systeme werden eingeführt, RPA-Rollouts erhöhen das Dokumentvolumen, Unternehmenskäufe bringen neue Integrationslandschaften mit, E-Commerce-Wachstum steigert die Sales-Order-Volumina.

Wer diese Entwicklungen nicht systematisch beobachtet und in die Vertragssteuerung einbringt, verliert den Überblick über seine tatsächliche Compliance-Position. Die Steuerungsmomente bei Digital Access sind keine theoretischen Kategorien. Sie sind die konkreten Zeitpunkte, an denen aktives Handeln Compliance sichert und Kosten planbar hält. Wer steuert SAP-Verträge nach der Unterschrift? Bei Digital Access ist das eine Frage mit finanzieller Konsequenz.

---

FAQ {#faq}

Was ist der Unterschied zwischen Indirect Access und Digital Access bei SAP?

Indirect Access war der historische Begriff für jeden Zugriff auf SAP-Daten über Drittsysteme, ohne klare Definition, wann genau eine Lizenzpflicht entstand. Digital Access ist das seit 2018 geltende Nachfolgemodell. Es ersetzt den unpräzisen Zugriffsgedanken durch eine klare Dokumentenlogik: Lizenzpflicht entsteht durch das Erstellen eines der neun definierten Dokumenttypen in SAP, nicht durch den Zugriff als solchen.

Welche neun Dokumenttypen lösen bei SAP eine Digital-Access-Lizenzpflicht aus?

Die neun Dokumenttypen sind: Sales Order Items, Purchase Order Items, Service Order Items, Manufacturing Order Items, Invoice Items (Billing/AR), Payment Items (Incoming Payments), Goods Movement Items, Journal Entries und Inbound Delivery Items. Diese Liste ist abschließend.

Ist Digital Access bei RISE with SAP automatisch inkludiert?

Für interne Integrationen im Geltungsbereich des Enterprise Agreements ist Digital Access in RISE-Verträgen häufig unbegrenzt inkludiert. "Intern" ist dabei vertragsabhängig definiert. Externe Systeme, Kunden-Portale, Lieferanten-Plattformen und IoT-Integrationen fallen in der Regel nicht unter diese Inklusion. Der Vertragstext, konkret das Digital Access Supplement, ist die maßgebliche Referenz.

Wann ist Named User Licensing günstiger als Digital Access?

Named User ist in der Regel wirtschaftlich überlegen, wenn die Nutzer des Drittsystems bekannt, identifizierbar und in begrenzter Anzahl vorhanden sind. Bei wenigen internen Mitarbeitern, die über ein externes Tool SAP-Buchungen auslösen, ist Named User oft der einfachere Weg. Bei anonymen Nutzern, hohem Transaktionsvolumen oder automatisierten Prozessen ist Document-Based Licensing überlegen.

Was ist das DAAP und muss ich es als Bestandskunde abschließen?

Das Digital Access Adoption Program ist ein freiwilliges SAP-Programm, das den Wechsel von historischen Indirect-Access-Verpflichtungen auf Document-Based Licensing ermöglicht. Es ist formal ein Amendment zum bestehenden SAP-Vertrag. Bestandskunden mit Verträgen, die vor 2019 abgeschlossen wurden, haben das DAAP möglicherweise noch nicht abgeschlossen. Ein Abschluss ist nicht zwingend erforderlich, schafft aber Planbarkeit und Audit-Schutz.

Lösen RPA-Systeme und Bots Digital Access aus?

Es hängt von der Konfiguration ab. SAP hat für eigene IRPA-Bots (Typ 68) und zertifizierte Drittanbieter-RPA-Bots (Typ 69) kostenlose Lizenzkategorien definiert. Bots, die korrekt unter diese Kategorien klassifiziert sind, lösen keine Digital-Access-Pflicht aus. Bots außerhalb dieser Kategorien oder mit anderen Authentifizierungsmodellen können Dokument-Items in SAP erstellen und damit eine Lizenzpflicht auslösen. Jeder RPA-Einsatz sollte vor dem produktiven Rollout auf Digital-Access-Relevanz geprüft werden.

Was bedeutet "Static Read", und warum löst es keine Lizenzpflicht aus?

Static Read beschreibt den ausschließlich lesenden Zugriff eines Drittsystems auf SAP-Daten, ohne dass das System etwas in SAP zurückschreibt oder erstellt. Da Digital Access am Erstellen von Dokumenten ansetzt und nicht am Lesen, entsteht bei reinem Datenlesen keine Lizenzpflicht. Ein Dashboard, das SAP-Daten ausliest und visualisiert, ohne Buchungen zu erstellen, fällt daher unter Static Read und ist lizenzrechtlich unproblematisch.

Wie wird Digital Access in einem SAP Enhanced Audit geprüft?

Im Enhanced Audit fordert SAP eine vollständige Liste aller Drittsysteme mit SAP-Schnittstellen an. Transaktionslogs und Dokumentvolumina werden analysiert. Systeme, die Dokument-Items in SAP erstellen, ohne Named-User-Lizenz oder DAAP-Supplement als Grundlage zu haben, werden als Compliance-Lücken markiert und können retroaktive Nachforderungen auslösen.

Was ist die Export-Regel bei Digital Access und wann gilt sie?

Die Export-Regel besagt: Wenn ein lizenzierter SAP-Nutzer einen automatisierten Prozess definiert und initiiert hat, der anschließend automatisch läuft, entsteht für die automatische Ausführung keine zusätzliche Digital-Access-Pflicht. Die Bedingung ist, dass der lizenzierte Nutzer den Prozess eingerichtet hat und die Berechtigung im Kontext dieses Nutzers liegt. Bei komplexen Multi-Step-Workflows, die über mehrere Systemgrenzen laufen, ist die Anwendung der Export-Regel nicht immer eindeutig und sollte vertraglich geklärt werden.

Wie dokumentiere ich meine Integrationslandschaft für einen SAP-Audit?

Das Integrationsregister ist das zentrale Werkzeug. Es erfasst für jede Schnittstelle: das externe System, die Kommunikationsrichtung, die erzeugten Dokumenttypen, das monatliche Volumen, die Nutzerbasis und die Lizenzgrundlage (Named User, Digital Access Supplement oder Ausnahme). Dieses Register sollte als lebendes Dokument geführt werden, das bei neuen Integrationen aktualisiert und quartalsweise auf Vollständigkeit geprüft wird.

Entstehen bei Digital Access Übernutzungskosten und wie sind sie gedeckelt?

Ja. Wenn das im DAAP-Amendment vereinbarte Dokumentkontingent überschritten wird, greift die Overage-Regelung des Order Forms. Die konkrete Overage-Rate ist vertragsabhängig. Eine Deckelung der Overage ist verhandelbar, aber kein Bestandteil der SAP-Standardbedingungen. Ein konkretes Overage-Cap sollte in jeder Digital-Access-Verhandlung adressiert werden.

Ich habe noch einen alten SAP-Vertrag ohne DAAP: was sollte ich prüfen?

Drei Fragen sind relevant. Erstens: Welche Integrationen existieren in Ihrem Bestand, und welche Dokumenttypen erzeugen sie? Zweitens: Sind diese Integrationen über Named User oder über eine andere Lizenzgrundlage abgedeckt? Drittens: Ist das DAAP-Programm für Ihren Bestand eine wirtschaftlich sinnvolle Option? Ein Vertragscheck klärt diese Fragen systematisch und liefert eine belastbare Ausgangssituation für die nächste Renewal-Verhandlung.

---

Nächste Schritte {#naechste-schritte}

Digital Access ist ein Steuerungsmoment, der in vielen SAP-Portfolios noch nicht systematisch erfasst ist. Der Integrationsbestand wächst, das Dokumentvolumen steigt, und der nächste Enhanced Audit kommt.

Vertragscheck buchen: In vier Wochen klären wir gemeinsam, welche Integrationen in Ihrem Portfolio Digital-Access-relevant sind, welcher Lizenzstatus vorliegt und wo Handlungsbedarf besteht. Festpreis, 7.900 EUR.

FinOptory AI nutzen: Für eine erste Einschätzung Ihres Integrations-Exposures steht der FinOptory AI Chat zur Verfügung.

Weiterführende Lektüre: Pillar 1 gibt den Überblick über alle Steuerungsmomente im SAP-Vertragsportfolio. Das Reifegradmodell (Pillar 6, in Vorbereitung) zeigt, wie die Integrationslandschaft als Governance-Dimension bewertet werden kann.

Wer Digital Access heute steuert, verhandelt beim nächsten Renewal mit offenen Karten.