SAP Digital Access: The Nine Document Types and How Licensing Works
Digital Access is a document-based licensing model. That is the defining difference from the older Indirect Access concept: it is not access to SAP that creates a licensing obligation, but the creation of specific document types in SAP via a third-party interface. SAP has defined exactly nine such document types. Knowing these nine types tells you which of your integrations are license-relevant, and knowing the volume of those documents gives you a central governance moment in your hands.
The Core Principle: Creation, Not Access
The older Indirect Access model tied the licensing obligation to a third-party system accessing SAP data or SAP functions. The ambiguity of that model generated years of legal uncertainty and publicly documented disputes with major customers (source: Gartner Research). SAP responded in 2018 with a fundamental redesign.
Under the Digital Access model, a licensing obligation arises from creating a document item in SAP, not from access as such. A third-party system that reads SAP data without writing anything back does not create a licensing obligation. SAP calls this Static Read. Only when a third-party system creates one of the nine defined document types in SAP does the licensing obligation apply.
This shift has practical consequences. The trigger event is clearly defined and measurable. The question is no longer: "Did a third-party system access SAP?" It is: "Which document items were created by this third-party system?"
Three conditions must be met simultaneously for a Digital Access trigger to occur. First: the document is created by a third-party system via an SAP interface (BAPI, RFC, API, web service, or equivalent). Second: the user of the third-party system is not licensed as an SAP Named User. Third: the third-party system is not operating under a recognized exception. If any one of these conditions is absent, no licensing obligation arises.
The Nine Document Types in Detail
SAP has defined exactly nine document types that trigger a Digital Access licensing obligation when created by a third-party system. This list is exhaustive. Document types outside these nine do not trigger any Digital Access obligation, regardless of other data operations a third-party system performs in SAP.
1. Sales Order Items Sales orders created by a third-party system via an SAP interface. Typical triggers: CRM platforms that transfer sales quotes and customer orders directly into SAP, or e-commerce platforms that write incoming customer orders as Sales Orders. At high order volumes, this scenario is frequently DAAP-relevant.
2. Purchase Order Items Purchase orders created via an external interface. Common triggers include procurement portals, supplier collaboration platforms, or supply chain systems that transfer purchasing transactions into SAP in an automated fashion.
3. Service Order Items Service orders from external CRM or field service systems. When a service management tool creates orders and assignments in SAP, it generates Service Order Items.
4. Manufacturing Order Items Production orders written into SAP by Manufacturing Execution Systems (MES). In high-throughput production environments, this scenario can generate very high document volumes, as feedback from production lines is transmitted in real time.
5. Invoice Items (Billing/AR) Outgoing invoices or posting lines from external systems. Relevant for billing platforms that write invoice runs into SAP, or for RPA-assisted invoice processing workflows.
6. Payment Items (Incoming Payments) Payment postings from financial portals, treasury management systems, or factoring platforms that record incoming payments in SAP. Volume is often limited here, but the licensing obligation arises regardless of the euro amount per posting.
7. Goods Movement Items Goods movements posted automatically into SAP by Warehouse Management Systems (WMS): goods receipts, transfers, shipping transactions. In logistics-intensive organizations, the transaction rate is high. Named User licensing is generally not economically viable at these volumes.
8. Journal Entries Journal entries created in SAP by RPA bots, external accounting systems, or automated processes. Journal Entries are one of the most common Digital Access triggers in RPA rollouts, because bots are by definition not Named Users.
9. Inbound Delivery Items Goods receipt postings from supplier or logistics platforms. When a supplier portal writes delivery notifications directly as Inbound Deliveries into SAP, the licensing obligation arises here.
How Document Volume Works as a Licensing Metric
Digital Access is licensed per document item, not per interface and not per system. That makes volume the central governance variable.
The billing granularity follows line-item logic: a Purchase Order with ten line items generates ten licensable items. A Sales Order with one line item generates one item. This logic applies to all nine document types.
The result is a direct link between operational growth and licensing costs. Higher order volume means more Purchase Order Items. An RPA rollout that triples processing capacity also triples document volume and thus Digital Access consumption.
The contractual structure follows a quota logic: the DAAP amendment defines document quotas that cover projected demand for the contract term. When a quota is exceeded, the overage provisions of the Order Form apply at the contractually agreed overage rate.
This is exactly where the governance moment around usage becomes concrete: which integrations generate how many items per month? Which systems are approaching their quota? Where are growth trends pointing toward an overage situation in the coming quarters? These questions can only be answered if the integration landscape is systematically documented and volume is monitored continuously.
Named User vs. Document-Based: Which Option Makes Sense When?
For every integration with Digital Access relevance, there are two fundamental paths to compliance: Named User or Document-Based Licensing.
Named User is the straightforward solution when the users of the third-party system are known, identifiable, and limited in number. Five controlling staff members who trigger postings in SAP via an external analytics tool can be licensed as SAP Named Users. The administrative overhead is low and costs are predictable.
Document-Based Licensing is the economically superior option when the user count is large, users are anonymous (customers, suppliers), or access is fully automated. An e-commerce platform whose end customers can never be captured as SAP Named Users requires Document-Based Licensing. A WMS processing tens of thousands of goods movements per day does as well.
The decision logic can be summarized in a matrix:
| Scenario | Recommended path |
|---|---|
| Few known internal users, low volume | Named User |
| Many or anonymous external users | Document-Based Licensing |
| Fully automated process (RPA, bot) | Document-Based Licensing |
| High transaction volume | Document-Based Licensing |
| Hybrid scenarios (mix of systems) | Both paths in parallel, contractually separate |
This decision is not a one-time event. When an integration grows or new user groups are added, the originally appropriate path may become economically disadvantageous. The review belongs in the ongoing governance rhythm.
Static Read and the Export Rule as Exceptions
Not every integration with an SAP connection is Digital Access-relevant. Two exceptions are particularly significant in practice.
Static Read refers to a third-party system accessing SAP data in a read-only capacity. A reporting dashboard that reads and visualizes SAP data without writing anything back does not create a licensing obligation. The dividing line is the creation of document items. Systems that only read are outside the Digital Access framework.
The Export Rule applies to automated processes that a licensed SAP user has set up. When a licensed user has defined an export process and it subsequently runs automatically, the automated execution does not create an additional Digital Access obligation. The condition: the licensed user initiated the process, and the authorization exists within that user's context.
The gray area with the Export Rule: in complex multi-step workflows that span multiple system boundaries, the application is not always clear-cut. Contractual clarification before the workflow goes live is advisable.
Batch Processing and RFC Edge Cases
Batch processes running via RFC in the context of a technical system user are legally complex from a licensing standpoint. The decisive question: does the system user have a Named User license?
The label "technical user" or "system user" is not an automatic shield against licensing obligations. Technical users without a Named User license can trigger Digital Access obligations when they create document items in SAP. An inventory of technical user accounts and their licensing basis is part of a complete Digital Access analysis.
RPA bots are subject to special rules: SAP has defined free license categories for its own IRPA bots (Type 68) and certified third-party RPA bots (Type 69). Bots correctly classified under these categories do not trigger a Digital Access obligation. Bots outside these categories must be assessed separately. Before any RPA rollout, the Digital Access relevance of the bots in use should be verified.
What This Means for Ongoing Governance
The nine document types are not just a compliance checklist. They are the foundation for a systematic governance moment in day-to-day operations.
Every new integration that goes live should be assessed for Digital Access relevance before go-live: which of the nine document types does it create? What is the projected volume? Which licensing basis applies?
Existing integrations should be reviewed quarterly for volume trends. Growing volumes, new system connections, and RPA rollouts continuously change the overall picture.
Knowing your integration landscape and keeping document volume in view means actively holding one of the central governance moments in SAP contracts. The nine document types are the starting point for that.
Frequently Asked Questions
Which nine document types trigger a licensing obligation under SAP Digital Access?
The nine document types are: 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, and Inbound Delivery Items. This list is exhaustive. Documents outside these nine do not create a Digital Access obligation.
When exactly does a Digital Access licensing obligation arise?
Three conditions must be met simultaneously: the third-party system creates one of the nine defined document types in SAP via an SAP interface. The user of the third-party system does not have a Named User license for SAP. The third-party system is not operating under a recognized exception (Static Read, Export Rule).
Is the licensing obligation per interface or per document?
Per document item. The metric is the volume of line items created, not the number of interfaces or systems. A Purchase Order with ten line items generates ten licensable items.
Does a read-only dashboard tool trigger Digital Access?
No. If a third-party system exclusively reads SAP data without creating document items, no Digital Access licensing obligation arises. SAP calls this Static Read.
Do RPA bots always need to be licensed as Digital Access usage?
Not necessarily. SAP has defined free license categories for its own IRPA bots (Type 68) and certified third-party RPA bots (Type 69). Bots correctly classified under these types do not create a Digital Access obligation. Bots outside these categories must be assessed separately.
What is the difference between Named User and Document-Based Licensing for Digital Access?
With Named User, the users of the third-party system are licensed as SAP users. With Document-Based Licensing, the document volume is licensed. Named User is suited for a small number of identifiable individuals. Document-Based Licensing is economically superior when access involves many users, anonymous users, or fully automated processes.
Next Steps
If you want to know which integrations in your portfolio fall under the nine document types and what licensing status applies, a Contract Check can provide that clarity systematically. In four weeks, at a fixed price of 7,900 EUR, you receive a complete overview of your Digital Access status, including a Named User vs. Document-Based Licensing recommendation for each integration.
Further reading: the hub article on SAP Digital Access and Indirect Access provides a complete overview of all aspects of Digital Access governance. Cluster 1 explains the historical background and the distinction between Indirect Access and Digital Access. Cluster 3 goes deeper on what RISE contracts specify regarding the integration landscape.
Next Steps
If you would like your current contract reviewed for risks and available commercial levers: the FinOptory Contract Check is a fixed-price engagement that delivers a structured basis within four weeks.
This article is part of our topic hub on digital access and indirect access in SAP. To have one specific contract assessed, the FinOptory Contract Check delivers a structured basis within four weeks.
Last updated: July 2026