SAP Indirect Access in 2026: Why Integration Risk Is Growing as ECC Estates Age

Why ECC Integration Risk Is Higher in 2026 Than in 2018

When SAP introduced the Digital Access model in 2018, the intent was to provide a more predictable and auditable metric for indirect access — replacing the notoriously vague indirect user licence concept with a document-count-based model. The Document-Driven Licence Count (DDLC) defines indirect access in terms of the number of documents created in SAP by non-SAP systems: purchase orders, sales orders, goods movements, financial postings, and production orders among others.

The model was administratively cleaner than what preceded it. But it did not reduce indirect access risk for ECC customers — it changed the metric against which risk is measured. And in the eight years since 2018, the integration landscape connecting to ECC systems at most large enterprises has continued to expand. More CRM systems, more eCommerce platforms, more RPA automation layers, more iPaaS integration tools, more API gateways — all creating documents in SAP without a corresponding named licence, all adding to the DDLC count that SAP will measure in any audit engagement.

The SAP landscape of 2026 for most ECC customers looks dramatically different from 2018. What has not changed: the licence agreement typically still reflects the indirect access terms agreed in or before 2018, calibrated to the integration landscape of that time. The gap between what was licensed and what is actually running has been growing continuously and silently for eight years. That is the core of the 2026 indirect access problem.

How DDLC Works and Where It Creates Exposure

The Document-Driven Licence Count Explained

Under the DDLC model, every qualifying document created in SAP from an external source counts toward the customer's licensed document allocation. SAP codified the ECC measurement approach in SAP Note 2992090. Document types that count include: purchase orders and purchase order amendments, sales orders, delivery documents, goods issue/receipt documents, financial accounting postings (FI documents), production orders, and quality inspection documents. Each of these document types consumes from the relevant DDLC bucket in the licence entitlement.

The practical challenge for customers is that DDLC measurement is not intuitive from the perspective of business process. A single customer order received through an eCommerce platform may create a sales order (DDLC-counted), a delivery note (DDLC-counted), and a goods issue (DDLC-counted) — three document events from a single customer transaction. An EDI-based purchase order from a supplier generates a purchase order in SAP (DDLC-counted). An RPA automation that posts a financial document to SAP generates an FI posting (DDLC-counted). For a high-volume order processor, DDLC consumption can reach tens of millions of documents per year across all document types.

The Measurement Accuracy Problem

SAP's measurement tools for DDLC have a documented accuracy problem that most customers are not aware of until they are already in an audit situation. The tools count document creation events — but they cannot reliably distinguish between original document creation and system-generated document amendments, re-posts, or reversals. A purchase order that is amended three times may count as four document events rather than one unique purchase order. An automated system that reprocesses documents for error correction may generate DDLC counts far above the number of actual business transactions it processes.

This measurement overcounting is structural, not a bug that SAP is actively correcting. The overcounting systematically inflates SAP's initial DDLC claim relative to the true business transaction volume. In our experience defending indirect access disputes, SAP's initial DDLC measurement overstates the true liability by 30 to 50 percent in a majority of cases. The inflated number becomes SAP's opening position in the commercial discussion, and customers who do not challenge it with independent measurement pay accordingly.

Why Ageing ECC Estates Create Compounding Risk

Integration Documentation Decay

Enterprise SAP ECC systems that have been running for fifteen or more years have integration landscapes built by teams that no longer exist, documented in systems that are no longer maintained, and understood by individuals who have long since left the organisation. The average large ECC customer has 40 to 100 active integrations connecting external systems to SAP. A meaningful proportion of those integrations — from our experience, typically 25 to 40 percent — are poorly documented, have no current owner, and are running on middleware or integration platforms that the current IT team manages operationally without detailed knowledge of what the integrations actually do in SAP.

This documentation decay creates a discovery problem that becomes an audit problem. When SAP initiates an indirect access assessment and requests that the customer describe all external systems creating documents in SAP, the customer's first response is often to list the integrations they know about. SAP's measurement tools identify all integrations — including the ones the customer did not list. The gap between the customer's self-reported integration inventory and SAP's measurement-based inventory is a direct indicator of the undiscovered indirect access liability.

RPA Automation Is the Fastest-Growing Risk Category

Robotic process automation deployments in enterprise SAP environments have accelerated significantly since 2020. RPA tools — UiPath, Automation Anywhere, SAP Intelligent RPA, and others — are frequently used to automate SAP transactions, create documents, and process workflows that previously required human users. Each automated transaction that creates a DDLC-counted document generates indirect access liability at scale.

A single RPA bot running an AP invoice automation workflow may create hundreds of FI documents per day. At enterprise scale, RPA automation can generate millions of DDLC events per year from a single implementation. The RPA team and the SAP licensing team are typically in different organisational silos, with no shared visibility of the indirect access implications of new RPA deployments. RPA projects are planned, approved, and deployed without an SAP licensing impact assessment, because that assessment does not have a natural home in the project governance structure.

What SAP would prefer buyers not know: SAP Intelligent RPA — SAP's own automation product — generates indirect access DDLC liability just like any third-party RPA tool when it creates documents in SAP. The fact that the automation tool is SAP-branded does not exempt its document creation activity from DDLC counting, unless the licence terms for the specific Intelligent RPA deployment explicitly include DDLC coverage. Many customers assume that SAP-sold automation tools are inherently licensed for indirect use. They are not, by default.

The Interaction with S/4HANA Migration Planning

The approaching ECC EHP 6–8 mainstream maintenance deadline in December 2027 creates a specific indirect access risk dynamic that did not exist before 2025. Organisations actively planning S/4HANA migration are engaging SAP account teams in commercial discussions — RISE pricing, migration credits, transition options. SAP uses these migration discussions to request licence position reviews that naturally include indirect access assessment.

The migration discussion creates a false safety assumption: customers assume that because they are migrating, indirect access issues from the ECC period will be resolved in the S/4HANA transition. SAP's position is the opposite. Indirect access liability from the ECC period is not extinguished by migration to S/4HANA; it may be used as a basis for back-billing covering the historic period of unlicensed use, and as leverage in the RISE contract negotiation to increase the migration value. Customers who enter migration discussions without resolving their indirect access position first frequently find that the migration commercial discussion is structured around the indirect access liability — with SAP offering to waive or reduce historic claims in exchange for a larger RISE commitment or longer RISE term.

How to Manage Indirect Access Risk in 2026

Step 1: Conduct an Independent Integration Discovery

The starting point for any indirect access risk management programme is a complete, independently verified inventory of all external systems that create, read, update, or delete SAP data through any channel — direct API calls, middleware, EDI, RPA, file-based interfaces, and portal connections. This discovery exercise should be conducted by a team with access to SAP technical artefacts — integration tables, RFC connection logs, API gateway logs, and middleware routing configurations — not by interviewing business process owners who may not know what technical integrations exist beneath their applications.

For each identified integration, the discovery should document: the source system, the SAP document types created, the approximate annual volume, the applicable DDLC metric, and any existing licence coverage (e.g., through Digital Access Adoption Programme agreements or named user licences covering the external system's users). Integrations that create DDLC-counted documents without coverage are the indirect access liability; integrations that create only read-only access or that operate under existing licence coverage are not.

Step 2: Run Independent DDLC Measurement Before SAP Does

Once the integration inventory is complete, run an independent DDLC measurement using SAP's published measurement tools and methodology, but with oversight from a team that understands the overcounting risks. Apply corrections for known overcounting scenarios: document amendments counted as new documents, reversal pairs, and system-generated re-posts. The corrected measurement is your defensible position — the number that reflects your actual indirect access liability rather than SAP's inflated initial measurement.

If your licence agreement was signed before 2018 or has not been reviewed for indirect access terms since the Digital Access model was introduced, the contract language may not reference DDLC at all. Older agreements using indirect user or external system terminology are subject to different (and often broader) liability definitions than DDLC-based agreements. Understanding which contractual regime applies to your indirect access exposure is essential before engaging with SAP on measurement or settlement.

Step 3: Develop Your Remediation Options

Once the independent measurement is complete and the contract terms are understood, three remediation options are typically available. The first is a Digital Access Adoption Programme (DAAP) agreement — a structured commercial arrangement where SAP provides discounted DDLC coverage for a defined set of document types, in exchange for a multi-year commitment. DAAP agreements are commercially complex and often include lock-in provisions; they should be evaluated carefully against alternative options. The second option is negotiating DDLC coverage within a broader SAP renewal or RISE transition agreement, where indirect access liability is resolved as part of a comprehensive commercial discussion. This approach is often the most commercially efficient but requires strong leverage and independent commercial preparation. The third option is technical remediation — restructuring specific high-volume integrations to reduce DDLC-counted document creation, for example by converting document creation from an external system to a named-user-licensed process. This is viable for specific integration scenarios and can reduce DDLC liability without a commercial payment to SAP.

Client Pattern: Retail Conglomerate Discovers Hidden RPA Liability

A large European retail group with approximately 4,000 ECC users engaged us to support an indirect access risk assessment ahead of a planned RISE migration discussion. The organisation believed its indirect access position was straightforward — three known integrations connecting an eCommerce platform, a logistics system, and a financial consolidation tool, all running for several years without any SAP challenge.

The independent integration discovery identified 23 active integrations, not three. The additional integrations included two RPA automation programmes deployed in the last three years by the shared services centre (creating FI and purchase order documents), a new customer portal integration (generating sales order documents), and multiple legacy EDI connections that the IT team had been aware of but had not considered in the indirect access context. The corrected DDLC measurement — after adjusting for overcounting — indicated an annual indirect access gap of approximately EUR 1.4 million against current licence coverage. This figure was used as the basis for a structured DAAP negotiation, which settled the historic liability and provided future coverage at a total cost of EUR 880,000 over three years — materially below what an uncontested SAP measurement would have generated.