Third-Party Vendor Checklist for Digital Access: Which Systems to Review for License Relevance Today
Before a RISE migration, before an SAP Enhanced Audit, or when introducing a new system: your integration inventory is the starting point for any reliable Digital Access governance. Yet in many portfolios, the integration landscape grows faster than the license status is kept current. New systems come online, interfaces get extended, and RPA bots take over processes that used to run manually.
This checklist helps you review your integration inventory systematically: which system categories are license-relevant, which are not, and where clarification is needed.
What triggers Digital Access: the core logic
Digital Access arises when a third-party system creates one of the nine defined document types in SAP via an SAP interface. It is not the reading of data that requires a license, but the creation. Understanding this lets you categorize your integration inventory with precision: which system writes something into SAP? And if so, which document type?
The nine document types are: Sales Order Items, Purchase Order Items, Service Order Items, Manufacturing Order Items, Invoice Items, Payment Items, Goods Movement Items, Journal Entries, and Inbound Delivery Items.
Every third-party system that generates one of these types is a potential Digital Access trigger. The first step, therefore, is not cost assessment but inventory.
10-point checklist: reviewing system categories for Digital Access relevance
1. CRM System
Ask yourself: does your CRM system create orders or service requests directly in SAP?
CRM platforms that transfer quotes and orders as Sales Orders or Service Orders into SAP are a frequent trigger. This applies to both direct API connections and middleware-based integrations.
License-relevant when: the CRM writes Sales Order Items or Service Order Items into SAP without the CRM users being licensed as SAP Named Users.
Clarification needed: capture monthly volume, evaluate Named User vs. Document-Based Licensing.
2. Warehouse Management System (WMS)
Ask yourself: does your WMS automatically post goods movements, goods receipts, or delivery items in SAP?
WMS solutions are a classic high-volume trigger. Goods receipts, stock transfers, and shipping processes generate Goods Movement Items and Inbound Delivery Items at a high rate. Named User licensing is almost never the economically sensible path in logistics-intensive environments.
License-relevant when: goods movement postings occur without a licensed SAP user context.
Governance moment: document volume, not user count, is the planning variable.
3. Manufacturing Execution System (MES)
Ask yourself: does your MES write manufacturing orders or production confirmations into SAP?
MES systems that control manufacturing processes frequently transfer confirmations to SAP in real time. Manufacturing Order Items and Goods Movement Items are generated at high frequency. In production-intensive environments, volumes can reach DAAP-relevant scale very quickly.
License-relevant when: manufacturing orders or confirmations are posted automatically without a Named User context.
4. E-Commerce Platform and Customer Portals
Ask yourself: does your e-commerce solution create customer orders directly as Sales Orders in SAP?
E-commerce is one of the clearest Digital Access scenarios: end customers are anonymous, Named User licensing is unworkable, and volume scales with business growth. The same applies to B2B portals through which business customers place orders, service requests, or returns.
License-relevant when: external customers or anonymous users generate order items in SAP.
Mandatory check: Named User is not an option for anonymous end customers. Document-Based Licensing is the structurally correct approach.
5. RPA Bots and Process Automation
Ask yourself: which RPA bots in your environment create documents in SAP?
RPA is one of the most frequently overlooked Digital Access triggers, because bots have no Named User and are treated as "technical users." SAP has defined free categories for its own IRPA bots (license type 68) and certified third-party RPA bots (license type 69). Bots outside these categories, or with deviating authentication models, can trigger document items.
License-relevant when: RPA bots create Invoice Items, Journal Entries, Payment Items, or Purchase Order Items and are not classified under type 68 or 69.
Mandatory check: review every production RPA bot for license type and authentication model before go-live.
6. Treasury System and Finance Portals
Ask yourself: does your treasury system or factoring portal post payments and journal entries in SAP?
Treasury management systems and external finance portals generate Payment Items and Journal Entries. Document volume here is typically lower than in logistics or e-commerce, but the monetary amounts per posting can be substantial. License requirements are based on document volume, not on the euro amount.
License-relevant when: payment postings or Journal Entries arise without a Named User context.
7. Procurement Portals and Supplier Collaboration Platforms
Ask yourself: do suppliers send back order confirmations or advance shipping notices via external portals that appear in SAP as Purchase Orders or Inbound Deliveries?
Procurement and supplier portals are legally complex from a licensing standpoint, because the users are external parties who are typically not registered as SAP Named Users. A separate special case is SAP Ariba: Ariba has its own transaction fees that arise independently of Digital Access. Whether Digital Access is additionally triggered depends on the specific integration architecture.
License-relevant when: external suppliers generate items in SAP without a Named User license.
8. Reporting and Analytics Tools
Ask yourself: does your reporting tool only read SAP data, or does it also write data back?
Pure read-only access falls under the Static Read exception: no document creation means no Digital Access obligation. The dividing line lies at creation. As soon as an analytics or BI tool writes postings, adjustments, or documents into SAP, the exception no longer applies.
Not license-relevant when: the tool accesses SAP data exclusively in read mode and writes nothing back.
Clarification needed when: write-back functions exist, even if they are rarely used.
9. Existing On-Premise Integrations After a RISE Migration
Ask yourself: which of your on-premise integrations were transferred unchanged into the RISE environment?
RISE migrations are a typical governance moment when Digital Access gaps emerge: the integration landscape from the on-premise environment is carried over, but the license status of each individual interface is not reviewed systematically. Whether the DAAP amendment from the old contract was also transferred into the new RISE contract is not a given either.
Governance moment: a contract generation check confirms which GTC version applies and whether the Digital Access supplement is current.
Mandatory check: review every carried-over on-premise integration for license status, not just the newly introduced ones.
10. Planned Extensions and New Integration Projects
Ask yourself: which new systems will be connected to SAP in the next twelve months?
License review is not a remediation step; it is a mandatory step before go-live. Putting a new integration into production without clarifying its Digital Access status creates a compliance gap that only becomes visible in the next Enhanced Audit.
Governance moment: for every planned integration, clarify before go-live: which document types will be created in SAP? Named User or Document-Based Licensing? Is the scope of the EA covered?
What to watch for after completing the checklist
The checklist identifies license-relevant systems. The next step is assessment: which of these systems have a sound license basis, whether a Named User license, a DAAP supplement, or a recognized exception? And which do not?
Gaps in license status are not the exception. In most SAP portfolios with multiple third-party integrations, there are interfaces whose license status is not conclusively documented. That is not a failure on the part of those responsible; it is a consequence of system complexity and the speed at which integration landscapes grow.
An integration register that captures the results of this checklist systematically and keeps it current within the governance cadence is the foundation for every subsequent step: DAAP negotiation, audit preparation, or renewal strategy.
Next steps
Book a contract check: if this checklist has surfaced clarification needs, a contract check resolves them within four weeks, identifying which integrations are license-relevant, what status currently applies, and which options are available. Fixed price, EUR 7,900.
Further reading: Digital Access and Indirect Access at SAP: Managing Third-Party Integration Licensing provides a complete overview of all aspects of Digital Access governance.
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