Digital Access and Indirect Access in SAP: Managing Third-Party Integrations from a Licensing Perspective

Every system that creates documents in SAP through an interface can trigger a licensing obligation. SAP calls this Digital Access. In practice, these rules affect most portfolios with third-party integrations without anyone tracking it systematically. Organizations that know the nine document types, understand the distinction between Named User and Document-Based Licensing, and have documented their integration inventory stay in control: they recognize the governance moment before SAP sets it for them in an audit.

Table of Contents

1. What Is Indirect Access and What Is Digital Access?
2. The Digital Access Adoption Program (DAAP)
3. The Nine Document Types: Which Integrations Trigger a Licensing Obligation
4. Named User vs. Document-Based Licensing: Two Paths to Compliance
5. Digital Access in RISE Contracts: What Is Included and What Is Not
6. Which Third-Party Systems Typically Trigger Digital Access
7. Static Read, the Export Rule, and Other Exceptions
8. RISE Integration Landscape and BTP Integration Suite
9. Audit Risk: How SAP Audits Indirect Access and What Is at Stake
10. Compliance Documentation: The Integration Inventory as a Governance Foundation
11. Digital Access in the Contract Framework: Supplement, DAAP Amendment, Order Form
12. Ongoing Governance: Four Governance Moments for Digital Access
13. FAQ
14. Next Steps

---

What Is Indirect Access and What Is Digital Access? {#what-is-indirect-access-and-digital-access}

Anyone dealing with SAP licensing questions today will encounter both terms: Indirect Access and Digital Access. They are frequently used interchangeably in practice. They describe, however, two distinct phases of SAP licensing policy, and understanding the difference is the starting point for any credible governance moment.

Indirect Access as a Historical Term (Before 2018)

Until 2018, Indirect Access was the umbrella term for all access to SAP data or SAP functionality that did not occur through a direct SAP login session. Any third-party system communicating with SAP via an interface could be classified as indirect access, with a potential licensing obligation as the consequence.

The problem was that the term was never precisely defined. Neither SAP nor its customers had a consistent answer to the question of exactly when a third-party system became subject to licensing. This tension produced years of legal uncertainty that materialized in publicly documented disputes with major customers such as Diageo and AB InBev (Source: Gartner Research). Those cases made clear that the Indirect Access model in its undefined form was not sustainable.

Digital Access as the Successor Model (Since 2018/2019)

SAP responded in 2018 with a structurally new model: Digital Access. Instead of focusing on the access itself, the licensing obligation now attaches to the outcome of that access. What matters is no longer whether a third-party system communicates with SAP, but whether it creates one of nine defined document types in SAP in the process.

This creates a significantly clearer governance logic. The licensing obligation arises from creating specific document items, not from access as such. The unit of measurement is document volume, not user count.

The Digital Access Adoption Program (DAAP) allows customers to migrate historical Indirect Access obligations into Document-Based Licensing. Many customers have not yet completed that transition.

What Changes in Practice

With the shift to Digital Access, Named User was not abolished as a licensing path for third-party integrations; it remains an equally valid option. For scenarios with a small number of identifiable external users, Named User is often the simpler route. For high-volume, automated, or anonymous access, Document-Based Licensing offers an economically attractive and operationally scalable alternative.

Choosing between the two paths requires a complete integration inventory. That inventory, in turn, is a governance moment that in many portfolios gets addressed systematically for the first time during a RISE migration or an Enhanced Audit.

Why This Topic Is Gaining Relevance in 2025 and 2026

Integration landscapes are growing more complex. CRM platforms write orders into SAP, warehouse management systems post goods movements automatically, RPA bots process incoming invoices, and e-commerce platforms generate thousands of sales orders daily. Every one of those integrations is a potential Digital Access trigger.

RISE migrations add further momentum: on-premise integration landscapes are moved to the cloud without the license status of each individual interface being reviewed systematically. At the same time, PCE Metering (Private Cloud Edition Metering) significantly increases the depth of SAP's compliance review for cloud customers. The technical infrastructure for automated compliance checks exists on SAP's side. On the customer side, it has not yet been embedded in the governance rhythm in many portfolios.

---

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

The DAAP is the formal contractual basis for migrating from the historical Indirect Access logic to the new document-based licensing model. Many customers have not yet completed the program, in some cases because the need was not recognized, in others because the RISE migration set different priorities.

What DAAP Is

DAAP is a voluntary program that SAP has offered since 2018. It allows customers to settle historical Indirect Access obligations on a one-time, retrospective basis and transition to Document-Based Licensing. The result is a formal amendment to the existing SAP contract: the Digital Access Supplement.

The core of the program is that SAP provides an amnesty for historical underlicensing during the transition period when the customer switches to Document-Based Licensing. Customers gain planning certainty and audit protection for the covered document types.

How DAAP Works in Practice

The DAAP process follows a structured sequence. In the first step, an SAP measurement tool captures current document volumes over a representative measurement period. In the second step, the customer and SAP negotiate a document quota on the basis of that volume, covering projected usage over the contract term. The third step is the formal conclusion as an amendment: the DAAP Amendment defines quotas, overage rules, and the price per document item.

Customers who take this path exit the gray zone of historical Indirect Access logic and receive a solid contractual basis for their integration inventory.

What to Review Before Entering DAAP

Organizations entering the DAAP program should have completed these preparations. First: a complete inventory of all integrations with an SAP interface, broken down by document type and volume. Second: a historical measurement period of at least twelve months to capture seasonal fluctuations. Third: growth assumptions for planned expansions in RPA, e-commerce, or new system connections. Fourth: a comparative calculation of Named User vs. Document-Based Licensing for each integration group.

Going into the negotiation without this foundation creates the risk of accepting a quota that is either set too low, generating overage in the short term, or oversized, tying up budget capacity that could be deployed more effectively elsewhere.

When DAAP Is Not the Right Solution

Document-Based Licensing is not the economically superior model in every scenario. For integrations with a small number of predictable external users and limited transaction volume, Named User can be the simpler and less expensive path. The decision logic depends on the ratio between the number of identifiable individuals and the document volume. The more external and anonymous users or automated processes are involved, the more the economics favor Digital Access.

---

The Nine Document Types: Which Integrations Trigger a Licensing Obligation {#nine-document-types}

Digital Access is a document-based licensing model. The licensing obligation does not arise from the existence of an interface but from the creation of a specific document type in SAP through that interface. SAP has defined exactly nine such document types.

Overview of the Nine Document Types

The nine document types that trigger a Digital Access licensing obligation when created by a third-party system:

1. Sales Order Items: Sales orders created in SAP by a third-party system
2. Purchase Order Items: Purchase orders created via an external interface
3. Service Order Items: Service orders from external CRM or field service systems
4. Manufacturing Order Items: Production orders written into SAP by MES systems
5. Invoice Items (Billing/AR): Outgoing invoices or posting line items from external systems
6. Payment Items (Incoming Payments): Payment postings from financial portals or treasury systems
7. Goods Movement Items: Goods movements posted automatically by WMS solutions
8. Journal Entries: Journal entries created by RPA bots or external accounting systems
9. Inbound Delivery Items: Goods receipt postings from supplier or logistics platforms

This list is exhaustive. Document types not included in this list do not trigger a Digital Access licensing obligation, regardless of what other data operations a third-party system performs in SAP.

What Creates a Document Type Trigger

Three conditions must be met simultaneously for a document item to be considered subject to licensing. First: the document is created by a third-party system via an SAP interface, whether 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 acting within the scope of the Export Rule, which is explained later in this article.

If any one of these conditions is absent, no Digital Access obligation arises.

Volume as the Governance Variable

Digital Access licenses are calculated not per system or per interface but per document item. A purchase order with ten line items generates ten licensable items. This granularity makes document volume the central planning variable.

The governance moment lies in volume control: which integrations generate how many items per month? Where is volume growing? When will the contractually agreed quota be exhausted? These questions can only be answered when the integration inventory is documented systematically and volume is monitored on an ongoing basis.

Practical Examples by Integration Type

A CRM system that creates sales orders daily via the SAP API generates Sales Order Items. A warehouse management system that automatically posts a goods movement with every goods receipt generates Goods Movement Items. An RPA bot that processes incoming invoices and creates Journal Entries in SAP generates Journal Entries. An e-commerce platform that transfers thousands of customer orders daily as Sales Orders generates high document volume. In this scenario, Document-Based Licensing is almost always economically superior, because Named User licensing for anonymous end customers is not a practical option.

---

Named User vs. Document-Based Licensing: Two Paths to Compliance {#named-user-vs-document-based}

Digital Access and Named User Licensing are two equally valid paths for fulfilling the licensing obligation arising from third-party integrations. Which path is right depends on the specific integration scenario. The decision is not a one-time event; it is a recurring governance moment.

Named User as the Classic Path

In the Named User model, the users of the third-party system are licensed as SAP Named Users. This is the classic approach and makes economic sense when users are known, identifiable, and limited in number.

A typical scenario: a controlling tool used by five employees who, as part of their work, trigger postings in SAP. Those five individuals can simply be registered as SAP users and licensed accordingly. The administrative overhead is low and the costs are predictable.

Named User reaches its limits when the user count is large, when users are anonymous (customers, suppliers), or when access is fully automated. In those scenarios, Document-Based Licensing is the superior option.

Document-Based Licensing (Digital Access)

In the Document-Based model, the licensing obligation arises not from the people involved but from what they or their systems create in SAP. What is licensed is the document volume, not the number of users.

The model is scalable and allows anonymous external users or fully automated processes to be handled in a legally compliant way. An e-commerce operation with ten thousand customer orders per day can license those orders as Sales Order Items without having to register every individual end customer as an SAP user.

The structural advantage is scalability. The structural overhead is this: document volume must be measured, documented, and monitored in the governance rhythm. Without knowing the volume, there is no credible basis for negotiating a quota.

Decision Matrix

The decision between the two paths follows a clear logic.

With few known users and low transaction volume, Named User is typically simpler and less expensive. With many or anonymous users and high volume, Document-Based Licensing is economically superior. In hybrid scenarios, both paths can coexist: some systems are covered through Named User, others through Document-Based Licensing. This hybrid approach must be clearly separated and governed in the contract.

One key point: the decision is not permanent. When an integration grows or new user groups are added, the originally sensible path can become economically disadvantageous. The review is a recurring governance moment in the permissions domain.

The Permissions Governance Moment for Digital Access

Permissions are one of the four governance moment domains in the FinOptory model. Digital Access illustrates why this domain encompasses more than internal user assignments. Permissions include the question of which interfaces are authorized to create which document types in SAP and on what licensing basis.

Introducing a new integration without clarifying whether it requires Named User or Digital Access creates a compliance gap. Expanding an existing integration without reviewing the licensing model creates the risk of overage. Governing these interfaces is permissions governance, not a purely technical matter.

---

Digital Access in RISE Contracts: What Is Included and What Is Not {#digital-access-rise}

One of the most common misconceptions in RISE portfolios is that Digital Access is fully covered by the RISE contract. For internal integrations in Enterprise Agreement structures, that is often true. For external systems, partner portals, and IoT platforms, it generally is not. The boundary lies in the contract text, not in the marketing materials.

The Base Rule in RISE Enterprise Agreements

In RISE contracts with an Enterprise Agreement, Digital Access for internal integrations is frequently included without limit. "Internal" in this context means systems operated by the same legal contracting party that falls under the same agreement.

This inclusion creates a significant governance moment for RISE customers. When internal systems can generate unlimited document volumes without incurring separate Digital Access costs, the integration landscape for internal processes can be designed more freely.

What "Unlimited Included" Means in Practice

The phrase "unlimited included" deserves careful reading. It refers to document volumes for internal systems within the defined scope. It does not automatically include the infrastructure costs that arise as integration volume grows, particularly BTP credits for middleware services.

In addition, the definition of "internal" vs. "affiliate" vs. "external party" is contract-specific and must be confirmed in the actual Digital Access Supplement. What sounds like "unlimited" in a sales conversation may be narrowly defined in the contract text.

What Is Not Automatically Included in RISE

Four categories typically fall outside the EA inclusion.

First: integrations with third parties outside the EA scope. When a supplier or logistics partner generates postings in SAP through an interface, that party is generally not considered "internal" within the meaning of the EA.

Second: integrations via external SaaS platforms that are not themselves contracting parties. An externally operated e-commerce platform that transfers orders to SAP is typically not covered by the EA inclusion.

Third: IoT platforms and connected manufacturing solutions with high document volume. These systems often generate very high quantities of Goods Movement Items or Manufacturing Order Items and are rarely captured contractually as internal systems.

Fourth: customer portals and partner platforms for B2B integration. When customers or suppliers trigger orders or goods movements through portal access, that is not an internal system access in the legal sense.

RISE with an Older Contract Status

Customers who had on-premise contracts before 2019 and migrated to RISE may not have the current Digital Access Supplement or the DAAP Amendment. Migrating to RISE does not automatically mean that all older contract components have been replaced by new standard terms.

A contract generation check is an indispensable governance moment in this case: which GTC version applies? Which supplement version? Has the DAAP Amendment been concluded? These questions should be answered before the next Enhanced Audit and, ideally, before the next renewal.

The "Usage" Governance Moment in RISE

Usage is one of the four governance moment domains in the FinOptory model. For Digital Access in RISE portfolios, this means concretely: document volume per integration is a usage metric that should be monitored systematically alongside FUE consumption.

Which integration systems created how many documents in the last quarter? Which systems are approaching their quota? Which new integrations have been introduced without clarifying their Digital Access status? These questions belong in the ongoing governance rhythm.

---

Which Third-Party Systems Typically Trigger Digital Access {#third-party-systems}

The question of which systems in your portfolio trigger Digital Access cannot be answered in general terms. It requires a look at the specific integration architecture. Some system categories, however, are prevalent enough that their classification serves as a useful reference framework.

CRM Systems (Sales Order Trigger)

CRM platforms supporting sales processes typically create quotes and orders and, in many system architectures, automatically transfer these to SAP as Sales Orders or Service Orders. The trigger occurs when those items are created in SAP via the CRM interface.

Volume depends on transaction density in the sales organization. For companies with high order volume, this scenario can quickly grow to DAAP-relevant scale.

Warehouse Management Systems (WMS)

WMS solutions governing goods receipts, transfers, and shipping processes post goods movements and delivery line items to SAP. This triggers Goods Movement Items and Inbound Delivery Items.

In logistics-intensive businesses, the rate is high. A warehouse with several hundred goods movements daily generates a document volume that rules out Named User licensing on economic grounds. Document-Based Licensing is the standard approach here.

Manufacturing Execution Systems (MES)

MES systems write production orders, confirmations, and material movements to SAP. The triggers are Manufacturing Order Items and Goods Movement Items.

In manufacturing environments, document frequency is often very high. Confirmations from production lines can be transferred to SAP in real time, with corresponding volume.

E-Commerce and Portals

Online shop platforms that create customer orders directly as Sales Orders in SAP are a classic Digital Access scenario. End customers are anonymous and cannot be licensed as Named Users. Volume scales with business growth.

For customer-facing portal access where business customers enter orders or service requests themselves, the same principle applies: Named User licensing for external customers is not manageable in practice. Document-Based Licensing is the structurally correct path.

RPA and Process Automation

Robotic Process Automation is one of the most frequently overlooked Digital Access triggers. Bots have no Named User and are fully automated. Depending on configuration, they generate Invoice Items, Journal Entries, Payment Items, or Purchase Order Items.

SAP has defined dedicated, no-cost license categories for certain RPA bots: SAP IRPA Type 68 and third-party RPA Type 69. Bots correctly classified under these categories do not trigger a Digital Access obligation. Bots outside these categories or using different authentication models must be evaluated separately.

Financial Portals and Treasury Systems

Treasury management systems and factoring platforms that post payments and Journal Entries to SAP generate Payment Items and Journal Entries. Volume here is not necessarily high, but the financial amounts per posting can be substantial. The licensing obligation is based on document volume, not on the euro amount.

Supplier and Procurement Platforms

Procurement portals through which suppliers submit order confirmations or delivery notifications can generate Purchase Order Items or Inbound Delivery Items. A special case is SAP Ariba: Ariba carries its own transaction fees, independent of Digital Access. Whether Digital Access additionally arises depends on the specific integration architecture and must be assessed separately.

---

Static Read, the Export Rule, and Other Exceptions {#exceptions}

Digital Access does not apply to all forms of SAP integration. There are clearly defined exceptions whose correct classification avoids both compliance gaps and unnecessary licensing costs.

Static Read: No Licensing Obligation

When a third-party system accesses SAP data exclusively in read mode, meaning it retrieves data without writing or creating anything in SAP, no Digital Access licensing obligation arises.

A typical example: a reporting dashboard that reads SAP data via an API and visualizes it. As long as that system does not create any document items, the access is unproblematic from a licensing perspective.

The critical boundary is the act of "creating." A system that reads and displays data but writes nothing back to SAP does not trigger a licensing obligation.

The Export Rule

The Export Rule is an important exception for automated processes. When a licensed SAP user has defined and initiated an automated export process, and that process subsequently runs automatically without human intervention, no additional Digital Access obligation arises for the automated portion.

The condition is that the licensed user must have set up the process. The authorization for the export must exist in the context of that user.

A typical use case: an SAP user creates a report or data export that runs automatically via a scheduled job every day. That job runs in the context of the initial user and counts as that user's licensed access.

The gray zone: in complex workflows where multiple steps run automatically and the original user context is passed across several system boundaries, the attribution is not always clear-cut. Contractual clarification is advisable before such a workflow goes into production.

Batch Processing and RFC

Batch processes running via RFC in the context of a technical system user are complex to classify from a licensing perspective. What matters is who the system user is assigned to and whether that user carries a Named User license.

Technical users without a Named User license can trigger Digital Access obligations if they create document items in SAP. The designation "technical user" or "system user" is not automatic protection against a licensing obligation. The licensing basis must be reviewed.

Test Environments

SAP typically examines the production system in an Enhanced Audit. Test environments and sandboxes are explicitly excluded in many contracts. Whether that is the case in a specific contract must, however, be confirmed in the contract text.

For test environments that handle production-level data volumes or are used as load-testing environments, the licensing question can become relevant. Here, too: contract text before assumption.

---

RISE Integration Landscape and BTP Integration Suite {#rise-btp}

In RISE portfolios, SAP Integration Suite on BTP is frequently used as the central middleware for third-party connections. This influences the Digital Access picture on two levels: at the level of licensing and at the level of infrastructure costs.

BTP Integration Suite as the Integration Layer

SAP Integration Suite is a BTP service and is licensed via CPEA credits. It functions as middleware between SAP core systems and third-party solutions.

An important distinction: BTP integration credits and Digital Access licensing are two separate topics. Operating an integration via BTP Integration Suite is a BTP credit consumption question. The licensing obligation for the document items generated in the process is a Digital Access question. Both dimensions must be combined in cost planning. They influence each other but are legally and commercially independent.

Integration Volume and BTP Credit Consumption

When an integration runs via BTP Integration Suite and generates high document volumes, both BTP credit consumption and Digital Access volume rise simultaneously. Organizations planning high integration volumes should account for both line items in their contract strategy.

In practice, these two topics are frequently handled separately in contract negotiations, even though they are operationally connected. A complete governance moment in the infrastructure domain covers both.

External Integration Platforms (iPaaS)

Not every organization uses BTP as middleware. MuleSoft, Boomi, Informatica, Azure Integration Services, and other platforms are also widely used. This choice does not change the Digital Access question. The trigger event is the creation of a document item in SAP, not the middleware used. An integration via MuleSoft that creates Sales Orders in SAP triggers the same licensing obligation as an identical integration via BTP Integration Suite.

One practical difference is visibility: the integration inventory of external iPaaS platforms can be less complete, because external platforms are not automatically included in SAP license monitoring.

The "Infrastructure" Governance Moment for Digital Access

Infrastructure is one of the four governance moment domains in the FinOptory model. For Digital Access, it comes down to these questions: which interfaces are active? Which middleware manages which integration flows? Which middleware changes have altered the license status of an integration?

A middleware change, for example migrating from SAP PI/PO to BTP Integration Suite as part of a RISE migration, can change the license status of an integration when new document types are written or new system constellations emerge. Integration architecture documentation is the prerequisite for a functioning Digital Access governance program.

---

Audit Risk: How SAP Audits Indirect Access and What Is at Stake {#audit-risk}

In an Enhanced Audit, SAP explicitly analyzes the integration landscape. Organizations that have documented their integration inventory and know the Digital Access status of each interface enter that conversation from a significantly stronger position.

How SAP Reviews Digital Access in an Enhanced Audit

The Enhanced Audit typically takes place every two to three years or is initiated by a specific trigger: ahead of renewal negotiations, during M&A transactions, or following notable findings in a Basic Audit.

As part of the Enhanced Audit, SAP requests a complete list of all third-party systems with SAP interfaces. Transaction logs and document volumes are evaluated. Systems that create document items in SAP without a Named User license or a DAAP Supplement as the basis are flagged as compliance gaps.

SAP's audit team (Global License Auditing) has the methodology to reconstruct integration topologies even when the customer's documentation is incomplete. Transaction logs in SAP contain sufficient information to determine which technical users created which document types.

Financial Exposure from Indirect Access Findings

The financial consequences of an Indirect Access finding consist of several components.

First: retroactive purchase of missing Digital Access licenses at current list prices, without existing customer discounts. Second: retroactive document license fees for the audit period, typically two to three years. For on-premise contracts without a DAAP Supplement: retroactive Named User licensing for all identified external users.

In the published literature, findings at high-volume integrations are documented with substantial six- or seven-figure amounts (Redress Compliance, JNC UK). The specific exposure depends on document volume, the duration of the unlicensed usage, and the contractually agreed list prices.

When Audit Risk Is Elevated

Four situations deserve particular attention.

First: e-commerce platforms with high order volume for which no Digital Access documentation exists. Second: RPA rollouts where the Digital Access status of the bots deployed was not reviewed before go-live. Third: RISE migrations where the on-premise integration inventory that came along was not put through a license review. Fourth: M&A transactions where an acquired company brings its own SAP integrations that do not correspond to the DAAP status of the acquiring organization.

The Audit Invitation as a Negotiating Signal

Enhanced Audits in practice are frequently initiated ahead of renewal negotiations. SAP uses audit findings as a commercial starting point for license repurchases and upgrades.

Going into an audit with a documented integration inventory and a completed DAAP Supplement limits the exposure and actively shapes the negotiating position. Absent compliance gives SAP the opportunity to position repurchases as part of the renewal negotiation. That changes the dynamics of the negotiation substantially.

---

Compliance Documentation: The Integration Inventory as a Governance Foundation {#compliance-documentation}

The most important foundation for Digital Access governance is a complete, actively maintained integration register. It is not an audit document that is created once and filed away. It is a living tool in the governance rhythm.

Step 1: Capture the Integration Landscape

The first step is a complete inventory. Which systems have an interface to SAP? For each interface: in which direction does data flow? Are document types created in SAP, and if so which ones? What volume does the integration generate per month? Who uses the third-party system, including internal employees, external customers, suppliers, and bots?

Sources for this exercise include IT architecture documents, middleware configurations, interface registers, and, often underestimated, invoices and order forms from past SAP negotiations where specific integration components may already have been addressed commercially.

Step 2: Review the License Status per Integration

For each integration captured, the following question must be answered: what licensing basis exists? A Named User license, a Digital Access Supplement (DAAP Amendment), or a recognized exception such as Static Read or the Export Rule?

Integrations without a licensing basis should be documented as gaps and prioritized. Not every gap carries the same risk profile. Volume and document type determine the financial exposure.

Step 3: Decide Named User vs. Digital Access

For each gap, the correct licensing path must be determined: Named User or Document-Based Licensing? The basis for this decision is the user base, document volume, and expected growth trajectory.

This decision should be documented, not just made. In an audit, the traceability of the decision logic is at least as important as the outcome.

Step 4: DAAP Negotiation or Named User True-Up

The outcome of Step 3 is translated into a contract change: a DAAP Amendment for Document-Based gaps, or a Named User addition for identifiable user scenarios.

For DAAP: the historical period of underlicensing should be explicitly settled within the DAAP negotiation. The DAAP program provides an amnesty option that can replace the retroactive purchase of license fees.

Step 5: Ongoing Documentation in the Governance Rhythm

The integration register is not a static document. It is maintained in the governance rhythm. New integrations go through a license review before go-live. Existing integrations are reviewed quarterly for volume development and status changes. Planned expansions, new RPA deployments, new API connections, and RISE migration scope extensions are assessed for Digital Access relevance before implementation.

This rhythm is not additional overhead. It is part of the systematic governance approach that prevents compliance gaps from forming in the first place.

---

Digital Access in the Contract Framework: Supplement, DAAP Amendment, Order Form {#contract-framework}

Digital Access is not solely a technology question; it is a contract question. Organizations that know the relevant contract documents can assess their own compliance position and know where clarification is needed.

The Digital Access Supplement

The Digital Access Supplement is a separate supplement to the main SAP contract. It defines the scope of the nine document types, the agreed document quotas, the overage rules when quotas are exceeded, and the price-per-document-item structure.

Without a Digital Access Supplement, there is no contractual basis for Document-Based Licensing. The implication is straightforward: an organization without a Supplement that nonetheless creates document items via third parties is either in a licensing gray zone or depends entirely on Named User licensing.

All current SAP contract templates are publicly available in the SAP Trust Center at sap.com/about/trust-center/agreements.html.

DAAP as an Amendment

The conclusion of DAAP materializes as a formal amendment to the existing contract. This amendment contains: document quotas for the agreed term, the overage price for quota overruns, the retrospective settlement for the historical period, and the definition of scope.

The hierarchy within the contract framework: the Amendment takes precedence over the Supplement, the Supplement takes precedence over the GTC. When the DAAP Amendment makes statements that differ from the Digital Access Supplement, the Amendment governs.

What the Order Form Contains

Document quotas appear as separate line items in the Order Form. Depending on the negotiation outcome, they are listed separately by document type or consolidated into an aggregate quota. The price per document item and the overage rate must be stated explicitly in the Order Form; they do not flow automatically from standard terms.

For the governance moment in the cost domain, the Order Form is the central reference: what is contractually agreed, what is actually being consumed, and where does overage risk exist?

Critical Contract Clause: Scope of the Enterprise Agreement

The most important clause in the Digital Access Supplement is the definition of scope. Which legal entities are covered by the Enterprise Agreement? Which systems qualify as "internal systems" within the meaning of the EA inclusion? Are outsourcing partners, group companies, and joint ventures included or excluded?

This definition determines which integrations fall under the EA inclusion at no additional cost and which must be licensed separately. The broader the scope is defined in the contract, the more integrations are exempt from the repurchase obligation.

Contract managers and procurement teams should define the scope as broadly as possible before the integration landscape continues to grow. After the contract is signed, renegotiating this point is significantly more complex.

---

Ongoing Governance: Four Governance Moments for Digital Access {#governance-moments}

Digital Access is not a one-time compliance project. It is an ongoing governance subject that has a concrete manifestation in each of the four governance moment domains of the FinOptory model. Organizations that address these governance moments systematically maintain control over compliance and costs and enter every SAP interaction prepared.

The four governance moment domains are: Usage, Permissions, Infrastructure, and Cost. For Digital Access, each domain has a specific application.

Governance Moment "Usage": Monitor Document Volume

The governance moment in the Usage domain asks: which integrations produce how many document items per month, and how is that volume trending?

In concrete terms, this means volume tracking per integration in the governance rhythm. Which systems are approaching their quota? Where are growth trends pointing to an overage situation in the coming quarters? Which integrations have shown unexpected volume increases?

The overage forecast is a concrete output of this governance moment. It enables proactive action: either negotiating a quota increase or taking operational measures before overage charges arise.

Governance Moment "Permissions": Govern the Integration Landscape

The governance moment in the Permissions domain asks: which interfaces are authorized to create which document types in SAP, and is the licensing basis for each of those interfaces documented?

New integrations must go through a license review before go-live. This is not an optional step; it is a mandatory step in the implementation process. Putting a new interface into operation without prior clarification creates a compliance gap.

At the same time, there is a positive governance moment here: inactive integrations. Which interfaces are licensed but no longer active? A systematic cleanup of inactive integrations can release quota capacity and improve cost development.

Governance Moment "Infrastructure": Middleware and Interface Inventory

The governance moment in the Infrastructure domain asks: which middleware manages which integration flows, and has a change in the integration architecture affected the Digital Access status of individual interfaces?

Middleware changes, new interface types, and RISE migrations can change license status. Making infrastructure changes without reviewing the Digital Access status of the affected integrations creates unnoticed compliance gaps.

The integration register is the operational tool for this governance moment. It must reflect infrastructure changes promptly.

Governance Moment "Cost": Invoice Reconciliation and Overage Control

The governance moment in the Cost domain asks: do the Digital Access charges on the SAP invoice match the measured document volume, and how does current consumption compare to the quota?

Digital Access charges appear as a separate line item on the SAP invoice. Reconciling the invoice amount with your own volume tracking is a routine review step. Discrepancies can point to calculation differences between SAP's measurement system and your own tracking.

The concrete budget alert threshold is 80 percent quota utilization: when an integration quota is 80 percent consumed, the forecast for the remaining contract year should be updated.

Why Post-Signature Governance Is Decisive

The contract sets the quotas. Operational reality keeps evolving. New systems are introduced, RPA rollouts increase document volume, acquisitions bring new integration landscapes, and e-commerce growth drives up sales order volumes.

Organizations that do not monitor these developments systematically and feed them into contract governance lose sight of their actual compliance position. The governance moments for Digital Access are not theoretical categories. They are the concrete points in time at which active action secures compliance and keeps costs predictable. Who governs SAP contracts after signature? For Digital Access, that is a question with a financial consequence.

---

FAQ {#faq}

What is the difference between Indirect Access and Digital Access in SAP?

Indirect Access was the historical term for any access to SAP data through third-party systems, without a clear definition of exactly when a licensing obligation arose. Digital Access is the successor model in effect since 2018. It replaces the imprecise access concept with a clear document logic: a licensing obligation arises from creating one of the nine defined document types in SAP, not from access as such.

What are the nine document types that trigger a Digital Access licensing obligation in SAP?

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.

Is Digital Access automatically included in RISE with SAP?

For internal integrations within the scope of the Enterprise Agreement, Digital Access is frequently included without limit in RISE contracts. "Internal" is defined in a contract-specific way. External systems, customer portals, supplier platforms, and IoT integrations generally do not fall under this inclusion. The contract text, specifically the Digital Access Supplement, is the authoritative reference.

When is Named User Licensing less expensive than Digital Access?

Named User is typically economically superior when the users of the third-party system are known, identifiable, and limited in number. When a small group of internal employees triggers SAP postings through an external tool, Named User is often the simpler path. With anonymous users, high transaction volume, or automated processes, Document-Based Licensing is superior.

What is the DAAP and do I need to complete it as an existing customer?

The Digital Access Adoption Program is a voluntary SAP program that allows the transition from historical Indirect Access obligations to Document-Based Licensing. It is formally an amendment to the existing SAP contract. Existing customers with contracts concluded before 2019 may not yet have completed the DAAP. Completion is not mandatory but provides planning certainty and audit protection.

Do RPA systems and bots trigger Digital Access?

It depends on the configuration. SAP has defined free-of-charge 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 or using different authentication models can create document items in SAP and thereby trigger a licensing obligation. Every RPA deployment should be reviewed for Digital Access relevance before the productive rollout.

What does "Static Read" mean, and why does it not trigger a licensing obligation?

Static Read describes the exclusively read-only access of a third-party system to SAP data, where the system writes or creates nothing in SAP. Since Digital Access attaches to the creation of documents rather than the reading of data, pure data retrieval does not create a licensing obligation. A dashboard that reads and visualizes SAP data without creating any postings therefore falls under Static Read and is unproblematic from a licensing perspective.

How is Digital Access reviewed in an SAP Enhanced Audit?

In an Enhanced Audit, SAP requests a complete list of all third-party systems with SAP interfaces. Transaction logs and document volumes are analyzed. Systems that create document items in SAP without a Named User license or a DAAP Supplement as the basis are flagged as compliance gaps and can trigger retroactive additional charges.

What is the Export Rule for Digital Access and when does it apply?

The Export Rule states that when a licensed SAP user has defined and initiated an automated process that subsequently runs automatically, no additional Digital Access obligation arises for the automatic execution. The condition is that the licensed user has set up the process and the authorization exists in the context of that user. For complex multi-step workflows running across multiple system boundaries, the applicability of the Export Rule is not always clear-cut and should be confirmed contractually.

How do I document my integration landscape for an SAP audit?

The integration register is the central tool. For each interface it captures: the external system, the direction of data flow, the document types generated, the monthly volume, the user base, and the licensing basis (Named User, Digital Access Supplement, or exception). This register should be maintained as a living document, updated when new integrations are added and reviewed quarterly for completeness.

Do Digital Access overages incur additional costs, and how are they capped?

Yes. When the document quota agreed in the DAAP Amendment is exceeded, the overage rules of the Order Form apply. The specific overage rate is contract-dependent. An overage cap is negotiable but is not part of SAP's standard terms. A concrete overage cap should be addressed in every Digital Access negotiation.

I still have an old SAP contract without DAAP. What should I review?

Three questions are relevant. First: which integrations exist in your inventory, and which document types do they generate? Second: are these integrations covered by Named User licensing or another licensing basis? Third: is the DAAP program an economically sensible option for your inventory? A contract check addresses these questions systematically and provides a solid starting point for the next renewal negotiation.

---

Next Steps {#next-steps}

Digital Access is a governance moment that has not yet been systematically captured in many SAP portfolios. The integration inventory keeps growing, document volume keeps rising, and the next Enhanced Audit is coming.

Book a Contract Check: In four weeks, we work through together which integrations in your portfolio are Digital Access-relevant, what license status exists, and where action is needed. Fixed price, EUR 7,900.

Use FinOptory AI: For an initial assessment of your integration exposure, the FinOptory AI Chat is available.

Further Reading: Pillar 1 provides the overview of all governance moments across the SAP contract portfolio. The maturity model (Pillar 6, in preparation) shows how the integration landscape can be evaluated as a governance dimension.

Organizations that govern Digital Access today negotiate from a position of strength at the next renewal.