SAP Digital Access: Die neun Dokumenttypen und die Mechanik der Lizenzierung

Digital Access ist ein dokumentenbasiertes Lizenzmodell. Das ist der entscheidende Unterschied zum historischen Indirect-Access-Begriff: Nicht der Zugriff auf SAP erzeugt die Lizenzpflicht, sondern das Erstellen bestimmter Dokumente in SAP über eine Drittanbieter-Schnittstelle. SAP hat genau neun solcher Dokumenttypen definiert. Wer diese neun Typen kennt, weiß, welche seiner Integrationen lizenzrelevant sind, und wer das Volumen dieser Dokumente kennt, hält einen zentralen Steuerungsmoment in der Hand.

Das Grundprinzip: Erstellen statt Zugriff

Das ältere Indirect-Access-Modell knüpfte die Lizenzpflicht an den Zugriff auf SAP-Daten oder SAP-Funktionen durch ein Drittsystem. Die Unschärfe dieses Modells erzeugte jahrelange Rechtsunsicherheit und öffentlich dokumentierte Rechtsstreitigkeiten mit Großkunden (Quelle: Gartner Research). SAP hat 2018 darauf reagiert und das Modell grundlegend geändert.

Im Digital-Access-Modell gilt: Lizenzpflicht entsteht durch das Erstellen eines Dokument-Items in SAP, nicht durch den Zugriff als solchen. Ein Drittsystem, das SAP-Daten liest, ohne etwas zurückzuschreiben, erzeugt keine Lizenzpflicht. Das nennt SAP Static Read. Erst wenn ein Drittsystem einen der neun definierten Dokumenttypen in SAP erstellt, greift die Lizenzpflicht.

Diese Verschiebung hat praktische Konsequenzen. Das Trigger-Ereignis ist klar definiert und messbar. Die Frage lautet nicht mehr: "Hat ein Drittsystem auf SAP zugegriffen?" Sie lautet: "Welche Dokument-Items wurden durch dieses Drittsystem erstellt?"

Drei Bedingungen müssen gleichzeitig erfüllt sein, damit ein Digital-Access-Trigger entsteht. Erstens: Das Dokument wird von einem Drittsystem über eine SAP-Schnittstelle (BAPI, RFC, API, Webservice oder vergleichbar) erstellt. Zweitens: Der Nutzer des Drittsystems ist nicht als SAP Named User lizenziert. Drittens: Das Drittsystem handelt nicht im Rahmen einer anerkannten Ausnahme. Fehlt eine dieser Bedingungen, entsteht keine Lizenzpflicht.

Die neun Dokumenttypen im Einzelnen

SAP hat genau neun Dokumenttypen definiert, die beim Erstellen durch ein Drittsystem eine Digital-Access-Lizenzpflicht auslösen. Diese Liste ist abschließend. Dokumenttypen außerhalb dieser neun lösen keine Digital-Access-Pflicht aus, unabhängig von anderen Datenoperationen, die ein Drittsystem in SAP durchführt.

1. Sales Order Items Verkaufsaufträge, die ein Drittsystem über eine SAP-Schnittstelle anlegt. Typischer Auslöser: CRM-Plattformen, die Vertriebsangebote und Kundenaufträge direkt in SAP übertragen, oder E-Commerce-Plattformen, die eingehende Kundenbestellungen als Sales Orders schreiben. Bei hohem Auftragsvolumen ist dieses Szenario häufig DAAP-relevant.

2. Purchase Order Items Bestellungen, die über eine externe Schnittstelle erstellt werden. Auslöser sind typischerweise Einkaufsportale, Lieferanten-Kollaborationsplattformen oder Supply-Chain-Systeme, die Bestellvorgänge automatisiert in SAP übertragen.

3. Service Order Items Serviceaufträge aus externen CRM- oder Feldservice-Systemen. Wenn ein Servicemanagement-Tool Aufträge und Einsätze in SAP anlegt, erzeugt es Service Order Items.

4. Manufacturing Order Items Fertigungsaufträge, die Manufacturing Execution Systems (MES) in SAP schreiben. In Produktionsumgebungen mit hoher Taktrate kann dieses Szenario sehr hohe Dokumentvolumina erzeugen, da Rückmeldungen von Fertigungslinien in Echtzeit übertragen werden.

5. Invoice Items (Billing/AR) Ausgangsrechnungen oder Buchungspositionen aus externen Systemen. Relevant bei Billing-Plattformen, die Rechnungsläufe in SAP schreiben, oder bei RPA-gestützten Rechnungsverarbeitungsprozessen.

6. Payment Items (Incoming Payments) Zahlungsbuchungen aus Finanzportalen, Treasury-Management-Systemen oder Factoring-Plattformen, die Zahlungseingänge in SAP erfassen. Das Volumen ist hier oft begrenzt, aber die Lizenzpflicht entsteht unabhängig vom Euro-Betrag pro Buchung.

7. Goods Movement Items Warenbewegungen, die Warehouse-Management-Systeme (WMS) automatisiert in SAP buchen: Wareneingänge, Umlagerungen, Versandvorgänge. In Logistik-intensiven Unternehmen ist die Taktrate hoch. Named User als Lizenzweg ist bei diesen Volumina wirtschaftlich in der Regel nicht darstellbar.

8. Journal Entries Journaleinträge, die RPA-Bots, externe Buchhaltungssysteme oder automatisierte Prozesse in SAP erstellen. Journal Entries sind einer der häufigsten Digital-Access-Trigger bei RPA-Rollouts, weil Bots per Definition keine Named User sind.

9. Inbound Delivery Items Wareneingangsbuchungen aus Lieferanten- oder Logistikplattformen. Wenn ein Lieferanten-Portal Lieferavise direkt als Inbound Deliveries in SAP schreibt, entsteht hier die Lizenzpflicht.

Wie Dokumentvolumen als Lizenzmetrik funktioniert

Digital Access wird nicht pro Schnittstelle und nicht pro System lizenziert, sondern pro Dokument-Item. Das macht das Volumen zur zentralen Steuerungsgröße.

Die Granularität der Abrechnung folgt der Positionsebene: Ein Purchase Order mit zehn Positionen erzeugt zehn lizenzpflichtige Items. Eine Sales Order mit einer Position erzeugt ein Item. Diese Logik gilt für alle neun Dokumenttypen.

Daraus ergibt sich eine direkte Verbindung zwischen betrieblichem Wachstum und Lizenzkosten. Mehr Bestellvolumen bedeutet mehr Purchase Order Items. Ein RPA-Rollout, der die Verarbeitungskapazität verdreifacht, verdreifacht auch das Dokumentvolumen und damit den Digital-Access-Bedarf.

Die vertragliche Struktur folgt der Logik von Kontingenten: Im DAAP-Amendment werden Dokumentkontingente vereinbart, die den prognostizierten Bedarf für die Vertragslaufzeit abdecken. Wird das Kontingent überschritten, greift die Overage-Regelung des Order Forms mit vertraglich vereinbarter Overage-Rate.

Der Steuerungsmoment im Bereich Nutzung konkretisiert sich genau hier: Welche Integrationen erzeugen wie viele Items pro Monat? Welche Systeme nähern sich dem Kontingent? Wo zeigen sich Wachstumstrends, die auf eine Overage-Situation in den nächsten Quartalen hindeuten? Diese Fragen lassen sich nur beantworten, wenn der Integrationsbestand systematisch dokumentiert und das Volumen laufend beobachtet wird.

Named User vs. Document-Based: Wann ist welche Option sinnvoller?

Für jede Integration mit Digital-Access-Relevanz gibt es zwei grundsätzliche Wege zur Compliance: Named User oder Document-Based Licensing.

Named User ist dann die naheliegende Lösung, wenn die Nutzer des Drittsystems bekannt, identifizierbar und in begrenzter Anzahl vorhanden sind. Fünf Controlling-Mitarbeiter, die über ein externes Analyse-Tool Buchungen in SAP auslösen, können als SAP Named User lizenziert werden. Der administrative Aufwand ist gering, die Kosten sind planbar.

Document-Based Licensing ist dann die wirtschaftlich überlegene Option, wenn die Nutzeranzahl groß ist, die Nutzer anonym sind (Kunden, Lieferanten) oder der Zugriff vollständig automatisiert erfolgt. Eine E-Commerce-Plattform, deren Endkunden niemals als SAP Named User erfasst werden können, braucht Document-Based Licensing. Ein WMS mit zehntausend Warenbewegungen pro Tag ebenso.

Die Entscheidungslogik lässt sich in einer Matrix zusammenfassen:

Szenario	Empfohlener Weg
Wenige bekannte interne Nutzer, niedriges Volumen	Named User
Viele oder anonyme externe Nutzer	Document-Based Licensing
Vollautomatisierter Prozess (RPA, Bot)	Document-Based Licensing
Hohes Transaktionsvolumen	Document-Based Licensing
Hybridszenarien (Mix aus Systemen)	Beide Wege nebeneinander, vertraglich getrennt

Die Entscheidung ist kein einmaliges Ereignis. Wenn eine Integration wächst oder neue Nutzergruppen hinzukommen, kann der ursprünglich sinnvolle Weg wirtschaftlich nachteilig werden. Die Überprüfung gehört in den laufenden Steuerungsrhythmus.

Static Read und die Export-Regel als Ausnahmen

Nicht jede Integration mit SAP-Bezug ist Digital-Access-relevant. Zwei Ausnahmen sind in der Praxis besonders bedeutsam.

Static Read bezeichnet den ausschließlich lesenden Zugriff eines Drittsystems auf SAP-Daten. Ein Reporting-Dashboard, das SAP-Daten ausliest und visualisiert, ohne etwas zurückzuschreiben, erzeugt keine Lizenzpflicht. Die Grenzlinie liegt beim Erstellen von Dokument-Items. Systeme, die nur lesen, sind außerhalb des Digital-Access-Rahmens.

Die Export-Regel gilt für automatisierte Prozesse, die ein lizenzierter SAP-Nutzer eingerichtet hat. Wenn ein lizenzierter Nutzer einen Export-Prozess definiert hat und dieser danach automatisch läuft, entsteht für die automatische Ausführung keine zusätzliche Digital-Access-Pflicht. Bedingung: Der lizenzierte Nutzer hat den Prozess initiiert, und die Berechtigung liegt in seinem Kontext.

Die Grauzone bei der Export-Regel: Bei komplexen Multi-Step-Workflows, die über mehrere Systemgrenzen laufen, ist die Anwendung nicht immer eindeutig. Hier empfiehlt sich eine vertragliche Klärung, bevor der Workflow produktiv geht.

Batch Processing und RFC-Grenzfälle

Batch-Prozesse, die über RFC im Kontext eines technischen System-Users laufen, sind lizenzrechtlich komplex. Die entscheidende Frage: Hat der System-User eine Named-User-Lizenz?

Die Bezeichnung "technischer User" oder "System-User" ist kein automatischer Schutz vor Lizenzpflicht. Technische User ohne Named-User-Lizenz können Digital-Access-Pflichten auslösen, wenn sie Dokument-Items in SAP erstellen. Eine Inventur der technischen User-Accounts und ihrer Lizenzgrundlagen ist Teil einer vollständigen Digital-Access-Analyse.

Für RPA-Bots gelten besondere Regeln: 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 müssen gesondert bewertet werden. Vor jedem RPA-Rollout sollte die Digital-Access-Relevanz der eingesetzten Bots geprüft sein.

Was das für die laufende Steuerung bedeutet

Die neun Dokumenttypen sind nicht nur eine Compliance-Checkliste. Sie sind die Grundlage für einen systematischen Steuerungsmoment im laufenden Betrieb.

Jede neue Integration, die in Betrieb genommen wird, sollte vor dem Go-Live auf Digital-Access-Relevanz geprüft werden: Welche der neun Dokumenttypen erstellt sie? Wie hoch ist das prognostizierte Volumen? Welche Lizenzgrundlage gilt?

Bestehende Integrationen sollten quartalsweise auf Volumenentwicklung überprüft werden. Wachsende Volumina, neue Systemanbindungen und RPA-Rollouts verändern das Gesamtbild kontinuierlich.

Wer seinen Integrationsbestand kennt und das Dokumentvolumen im Blick behält, hält einen der zentralen Steuerungsmomente bei SAP-Verträgen aktiv in der Hand. Die neun Dokumenttypen sind der Ausgangspunkt dafür.

Häufig gestellte Fragen

Welche neun Dokumenttypen lösen bei SAP Digital Access eine 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. Dokumente außerhalb dieser neun erzeugen keine Digital-Access-Pflicht.

Wann entsteht eine Digital-Access-Lizenzpflicht genau?

Drei Bedingungen müssen gleichzeitig erfüllt sein: Das Drittsystem erstellt über eine SAP-Schnittstelle eines der neun definierten Dokumenttypen in SAP. Der Nutzer des Drittsystems hat keine Named-User-Lizenz für SAP. Das Drittsystem handelt nicht im Rahmen einer anerkannten Ausnahme (Static Read, Export-Regel).

Gilt die Lizenzpflicht pro Schnittstelle oder pro Dokument?

Pro Dokument-Item. Die Metrik ist das Volumen der erstellten Positionen, nicht die Anzahl der Schnittstellen oder Systeme. Ein Purchase Order mit zehn Positionen erzeugt zehn lizenzpflichtige Items.

Löst ein rein lesendes Dashboard-Tool Digital Access aus?

Nein. Wenn ein Drittsystem ausschließlich SAP-Daten liest, ohne Dokument-Items zu erstellen, entsteht keine Digital-Access-Lizenzpflicht. Das nennt SAP Static Read.

Müssen RPA-Bots immer als Digital-Access-Nutzung lizenziert werden?

Nicht zwingend. SAP hat für eigene IRPA-Bots (Typ 68) und zertifizierte Drittanbieter-RPA-Bots (Typ 69) kostenlose Lizenzkategorien definiert. Korrekt klassifizierte Bots dieser Typen erzeugen keine Digital-Access-Pflicht. Bots außerhalb dieser Kategorien müssen gesondert bewertet werden.

Was ist der Unterschied zwischen Named User und Document-Based Licensing bei Digital Access?

Bei Named User werden die Nutzer des Drittsystems als SAP-Nutzer lizenziert. Bei Document-Based Licensing wird das Dokumentvolumen lizenziert. Named User eignet sich für wenige, identifizierbare Personen. Document-Based Licensing ist bei vielen, anonymen oder automatisierten Zugriffen wirtschaftlich überlegen.

Nächste Schritte

Wer wissen möchte, welche Integrationen im eigenen Portfolio zu den neun Dokumenttypen gehören und welcher Lizenzstatus vorliegt, kann das im Rahmen eines Vertragschecks systematisch klären. In vier Wochen und zu einem Festpreis von 7.900 EUR entsteht eine vollständige Übersicht des Digital-Access-Status, einschließlich einer Empfehlung für Named User vs. Document-Based Licensing pro Integration.

Weiterführende Lektüre: Der Hub-Artikel zu SAP Digital Access und Indirect Access gibt den vollständigen Überblick über alle Aspekte der Digital-Access-Governance. Cluster 1 erklärt den historischen Hintergrund und die Abgrenzung zwischen Indirect Access und Digital Access. Cluster 3 vertieft die Frage, was in RISE-Verträgen zur Integrationslandschaft gilt.