Digital Access in Cloud ERP Contracts: What the Enterprise Agreement Inclusion Covers and What It Doesn't
RISE contracts with an Enterprise Agreement frequently include unlimited Digital Access rights for internal integrations. But "internal" is defined by the contract, not by common usage, and external systems, partner portals, and IoT platforms typically fall outside that definition. What your RISE contract says is what counts, not what was communicated during the sales process.
The EA Inclusion Logic in RISE
RISE with SAP is typically structured as an Enterprise Agreement. This contract model differs structurally from earlier on-premise contracts: instead of licensing individual product instances or user types separately, the customer purchases an overall capacity that consolidates different usage types under one umbrella.
For Digital Access, this has one important consequence. In Enterprise Agreements, Digital Access for internal integrations is frequently included as an unlimited entitlement. No separate document quota, no overage rules for internal systems, no discrete line item in the Order Form. That sounds like full predictability, and it is, as long as your integration footprint actually stays within the defined scope.
The critical term is "internal." It is defined in the contract, not in ordinary language. What counts as internal for a business unit may not qualify as internal under the EA inclusion as defined in the Digital Access Supplement of your specific RISE contract.
A governance moment arises precisely here: the EA inclusion logic creates real room to shape your internal integration landscape. You can only take advantage of that room if you know your contract text and understand where the boundaries of the inclusion lie.
What "Internal Systems" Means and Where the Line Falls
In the context of the SAP Digital Access Supplement, "internal systems" refers to systems operated by the same legal contracting party and covered under the same RISE contract. In practice: systems belonging to the company itself, on the same legal entities explicitly named in the contract.
Three boundary levels matter:
Your own entity vs. group subsidiaries: If the RISE contract is held by the parent company and a subsidiary generates documents through an SAP interface, that does not automatically fall under the EA inclusion. Whether group companies qualify as "internal" depends on whether they are explicitly listed as authorized entities in the Enterprise Agreement. So-called "affiliate" clauses govern this, and their scope varies considerably across contract versions.
Outsourcing partners and service providers: If an external service provider generates SAP postings on behalf of your company, for example a logistics outsourcing partner booking goods receipts, that is not internal system access under the Enterprise Agreement. The service provider is not a contracting party, and their systems are outside the defined scope.
Technical operating models: In some infrastructure models, systems are technically operated by a third party but on behalf of and for the account of the RISE contracting party. Whether that qualifies as internal is an interpretation question that should be clarified with SAP in cases of doubt. The wording in the Supplement governs.
The practical consequence: without knowing the scope of the EA inclusion, you cannot reliably assess which of your integrations are covered and which are not. That is a governance moment in the entitlements domain: which interfaces have a solid licensing basis, and which are in a gray area?
What RISE Typically Does Not Cover
Four integration categories frequently fall outside the EA inclusion. The word "frequently" is deliberate: the contract text is the benchmark, and there is no single uniform RISE contract. But the following categories reflect the reality in the large majority of RISE portfolios.
External third parties with interface access: When a supplier pushes order confirmations or advance shipping notices into SAP through a procurement portal, that supplier is acting as an external party. The portal they use is not part of the EA scope. The same applies to customers who enter orders directly into SAP through a B2B portal.
External SaaS platforms: When an externally operated e-commerce platform transfers customer orders as Sales Orders to SAP, that SaaS platform is not an internal system of the RISE contracting party. It is an external service provider running an interface. Digital Access for the resulting Sales Order items does not automatically fall under the EA inclusion.
IoT platforms and connected manufacturing: Production-adjacent IoT environments often generate very high volumes of Manufacturing Order items and Goods Movement items. If these platforms are operated by a specialist vendor or are standalone systems outside the defined EA scope, the inclusion does not apply. The volume makes this case especially significant: thousands of production confirmations per day can, without a solid licensing basis, trigger substantial back-billing.
Customer-facing portals for B2B business: Dealer portals, service request platforms, or ordering applications through which business customers directly trigger transactions in SAP are typically not internal systems. Named User licensing is not workable here, and the EA inclusion does not cover these scenarios. Digital Access through a DAAP amendment is the structurally correct solution in such cases.
RISE Contract Generation Check: Which Supplement Version Applies?
The RISE rollout has left many companies with a contract history stretching back to the on-premise era. Customers who had SAP contracts before 2019 and migrated to RISE did not automatically replace all legacy contract components with new standard terms.
Three scenarios are common in practice:
Scenario A: Migration without a full contract review. The existing on-premise contract was superseded by a RISE contract, but the Supplement structure was not fully harmonized. This can mean: no Digital Access Supplement exists because the DAAP program was never completed. Integrations that previously ran under Indirect Access rules now operate without a solid successor basis.
Scenario B: DAAP amendment still outstanding. The company signed a RISE contract, but the DAAP amendment has not yet been negotiated. The EA inclusion for internal systems applies, but the area outside that inclusion is not covered by a Document-Based Licensing Supplement. For external integrations, the contractual basis is missing.
Scenario C: Older GTC version. Not all RISE contracts have been migrated to the current SAP General Terms and Conditions. Older GTC versions may not include the Digital Access model in its current form. A contract generation check clarifies which GTC applies, which Supplements are in place, and what the resulting implications are.
The recommended action is the same in all three scenarios: which Supplement version governs your RISE contract? That question can be answered by reviewing your Digital Access Supplement and the DAAP amendment, provided both exist. If the Supplement cannot be located, that itself is already relevant information.
Current SAP contract templates are publicly available in the SAP Trust Center at sap.com/about/trust-center/agreements.html. The version published there provides a reference point, but your specific contract position may differ.
RISE Migration: Legacy On-Premise Integrations as a License Check
RISE migrations do not just affect the core system. They affect the entire integration landscape. Every interface that connected an on-premise system with third-party solutions gets reconfigured, migrated, or replaced in the RISE architecture.
This creates a specific governance moment: the licensing basis of an on-premise integration does not automatically transfer to the RISE environment. An interface that was covered by Named Users in the on-premise world needs to be reassessed in the RISE contract context. The question is not just whether the interface works technically, it is whether it is correctly classified from a licensing standpoint.
Three areas deserve particular scrutiny in a RISE migration:
Existing Named User coverage: If an integration was previously licensed through Named Users, you need to clarify whether that licensing still holds under the new RISE contract. Named User types from on-premise price lists do not have a direct equivalent in the RISE EA model.
Integrations that ran under Indirect Access: Contracts signed before 2019 do not include the Digital Access model. When an integration from that era is carried into the RISE environment, its licensing basis needs to be redefined.
New document types resulting from an architecture change: A middleware change, for example from SAP PI to BTP Integration Suite, can cause an integration to generate different document types than before, or to appear for the first time as a distinct interface. That changes the Digital Access profile of that integration.
The integration register that results from this review is not a one-time project. It is the foundation for the ongoing governance moment in the infrastructure domain: which interfaces are active? Which middleware manages which flows? Has an architecture change altered the licensing status?
BTP Integration Suite and Digital Access: Two Separate Topics
In RISE portfolios, SAP Integration Suite on BTP is frequently used as the central middleware. It connects SAP systems with third-party solutions and is licensed through CPEA credits.
A common source of confusion arises here: BTP credits for running the Integration Suite and Digital Access licensing for the document items it creates are two separate topics.
Operating an integration through BTP Integration Suite consumes BTP credits. That is an infrastructure charge for using the cloud service. The licensing obligation for the document items that integration creates in SAP is a Digital Access question. Both positions arise from the same operation, but they are governed by different contract components and billed separately.
This has a concrete planning implication: anyone planning a new integration through BTP Integration Suite needs to account for both cost dimensions in their calculations. BTP credits for the infrastructure operation, and Digital Access entitlements for the documents generated. At high integration volumes, both positions can be significant.
The governance moment in the cost domain encompasses both: what does the SAP invoice show for Digital Access? Does it match the measured document volume? And how does BTP credit consumption compare to planned capacity?
FAQ
Is Digital Access automatically and fully included with RISE with SAP?
For internal integrations within the scope of the Enterprise Agreement, Digital Access is frequently included without limits in RISE contracts. "Fully included" is not accurate, however: external systems, customer portals, supplier platforms, and IoT integrations typically fall outside this inclusion. The contract text is the authoritative reference.
What is the difference between "internal" and "affiliate" in the RISE context?
"Internal" in the Digital Access Supplement typically refers to the direct contracting party and its own systems. "Affiliate" is a separate category for associated entities that must be explicitly included in the contract. Whether group companies qualify as affiliates, and whether affiliates are covered by the EA inclusion, depends on the specific contract.
Do I need to re-evaluate my integrations for Digital Access after a RISE migration?
Yes. The RISE migration does not automatically carry over the licensing bases from the on-premise contract. Integrations that relied on Named Users or historical Indirect Access rules require a fresh assessment in the RISE contract context. A middleware change, for example from SAP PI to BTP Integration Suite, can alter the Digital Access profile of an integration.
What happens if no DAAP negotiation took place after the RISE migration?
For external integrations outside the EA inclusion, the contractual basis for Document-Based Licensing is then missing. Those integrations are in a licensing gray area. In an enhanced audit, SAP can identify that gap and assert retroactive claims. A DAAP amendment can be signed after the fact and typically includes a retrospective true-up.
Next Steps
Digital Access in RISE contracts is not a topic you address once and put to rest. The scope of the EA inclusion, the Supplement version in force, and the licensing status of individual integrations are governance moments that require ongoing attention.
Book a contract check: In four weeks, we clarify which integrations in your RISE portfolio fall under the EA inclusion, where DAAP coverage is needed, and what options you have at your next renewal. Fixed price, EUR 7,900.
Further reading: Digital Access and Indirect Access: Terms, History, Licensing Options and Which Third-Party Systems Trigger SAP Digital Access.
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