SAP Indirect Access via APIs: How Third-Party API Calls to SAP Create Licence Exposure

Named User vs. Indirect Access: The Licensing Fault Line

SAP's licensing model has always rested on a deceptively simple premise: you pay for users who access the system. For decades, this meant named users—human beings logging into SAP, executing transactions, consuming reports. Straightforward. Auditable. Predictable.

Then the API economy exploded.

When your e-commerce platform queries SAP via REST API, is that a "use"? When your third-party reporting tool polls the SAP database, does it need a user? When your ERP-to-CRM integration middleware reads order data through OData, who pays for it?

SAP's answer: you do. Often significantly.

This is where indirect access becomes lethal to unlicensed organizations. The licensing model split cleanly into two lanes:

• Named User Access: A human logs in with credentials, performs work. Simple CAL (Client Access License) cost per user per month.
• Indirect Access: Any non-human entity—system, service, bot, integration—that reads or modifies SAP data without a named user. Previously undefined, now weaponized.

The problem isn't that indirect access exists. It's that SAP left the definition intentionally vague for years, then used audits to retrofit retroactive licensing bills based on API calls that enterprises made years earlier under good faith belief they were licensed.

What SAP Calls "Indirect Use"—And Why the Definition Matters

Here's SAP's official language from their licensing guidelines:

"Indirect access means any non-human access to SAP software, including access via third-party systems, interfaces, middleware, APIs, or automated processes, where data or functionality is accessed without a named user identity."

That definition is deliberately sweeping. Let's unpack it forensically:

• "Non-human access": Not a person. Covers everything from middleware daemons to microservices to scheduled batch jobs.
• "Third-party systems": BI tools, e-commerce platforms, CRM systems, data warehouses—anything outside the SAP footprint.
• "Interfaces, middleware, APIs": REST, SOAP, RFC, OData, custom connectors, iPaaS platforms. All of it.
• "Automated processes": ETL jobs, scheduled reports, background tasks, queued transactions.
• "Without a named user identity": The killshot. System users, service accounts, technical IDs—none count as "named users."

In practice, SAP auditors interpret this to mean: if a third-party system touches SAP data via any interface that isn't explicitly covered by a named user sitting at a terminal, your company owes SAP licensing fees.

This is where the Diageo case becomes prophetic.

API Scenarios That Trigger Indirect Access Claims

Let's map the specific API and integration patterns that SAP auditors flag as indirect access exposures. These are real, documented scenarios from recent audits.

REST APIs

REST APIs are SAP's modern face for third-party integrations. Your e-commerce site calls GET /sap/api/sales/orders to fetch pending orders. Every call is technically an "access" to SAP data.

SAP's position: each REST API call from a non-named-user system triggers indirect access licensing. If your e-commerce platform makes 500 API calls per day to SAP, that's 500 "uses" per day of SAP functionality—and SAP will argue you need either:

• A named user license for the e-commerce system (impossible), or
• Digital Access licenses covering the data volumes processed.

The SAP REST API ecosystem is vast: Sales Cloud APIs, SuccessFactors APIs, Analytics Cloud APIs, C4C APIs. Each one can be weaponized in a licensing audit if not explicitly scoped in your contract.

RFC/BAPI Calls

Remote Function Calls (RFC) are the older, more direct pipeline into SAP's transactional logic. They're still ubiquitous in legacy SAP estates.

When your third-party system (warehouse management, procurement, payroll) calls an RFC function—say, BAPI_PO_CREATE1 to create a purchase order—SAP treats that as system-to-system indirect access.

RFC calls are easier to audit than REST APIs because they leave clearer logs. SAP auditors look for:

• System users with RFC destinations active
• Transaction codes (SM59 for RFC, SM37 for batch job logs) showing systematic inbound RFC traffic
• Registered RFC destinations pointing to external systems

If an auditor finds an RFC user making 1000+ calls per month, they'll claim you need licensing for that indirect access. Most contracts don't explicitly carve out RFC traffic.

OData Services

OData is SAP's modern, RESTful API layer—the bridge between legacy ABAP and cloud-native architectures. It's also a landmine.

Every SAP module (S/4HANA, SuccessFactors, Analytics Cloud) exposes OData endpoints. When external systems consume them—pulling customer masters, reading GL balances, querying HR data—SAP now argues those are chargeable indirect accesses.

OData is particularly dangerous because:

• It's often enabled by default without explicit licensing negotiation
• It's consumed by SAP Fiori front-ends, which muddy the water on licensing liability
• OData call volumes can be massive at scale, making it a high-severity audit finding

Example: An S/4HANA deployment exposes the /sap/opu/odata/sap/C_SALESORDER_TP endpoint. Your e-commerce system hits it 100,000 times per month. SAP audit claims: digital access exposure for 100,000 document reads. Boom. New licensing requirement.

SAP Integration Suite & PI/PO

SAP's Process Integration (PI) and Process Orchestration (PO) platforms are system integration workhorses. They broker thousands of interface instances moving data between SAP and third-party systems.

Here's the licensing knife-edge: when PI/PO reads or writes SAP data—via RFC, SOAP, REST, EDI, or file transfers—is that licensed indirect access?

SAP's position is nuanced and dangerous:

• If PI/PO is an SAP-licensed product, it's considered part of your SAP ecosystem—but that doesn't exempt the data flows it orchestrates
• Each outbound call from PI/PO to a third-party system that reads SAP data is indirect access
• Batch data exchanges (daily GL dumps to data warehouse) are chargeable indirect access if not explicitly carved out
• EDI transmissions (orders, invoices) are treated as digital documents under the Digital Access model

Recent audits have flagged unarchitected PI/PO landscapes as major exposure vectors—systems that were deployed 5+ years ago before indirect access became a pricing lever. SAP retroactively applies indirect access charges to historical data flows.

SAP BTP Integration

SAP Business Technology Platform (BTP) is SAP's cloud integration hub. It connects SAP systems to third-party clouds, legacy apps, SaaS platforms, and internal services.

When a BTP integration flow reads from SAP (via OData, SOAP, RFC, or direct database access), SAP now argues it's indirect access to SAP data—even though you're running the integration on BTP, which is a licensed product.

The problem: BTP's RISE with SAP and standalone subscriptions often don't explicitly clarify licensing for data volume passing through integration flows. Auditors have started claiming that integration throughput (documents processed, records moved, API calls made) triggers digital access fees on top of BTP subscription costs.

This is particularly aggressive because enterprises licensed BTP believing the subscription covered all integration scenarios. SAP is now retroactively arguing otherwise.

The 2017 Diageo Precedent: $600M and a Watershed Moment

In 2017, SAP auditors descended on Diageo (the spirits conglomerate) and emerged with a staggering finding: approximately $600 million in unlicensed SAP usage over the preceding years.

The audit wasn't about named users. It was about indirect access.

Specifically, SAP found that Diageo's complex supply chain, logistics, and third-party systems were calling SAP repeatedly—via APIs, integrations, and automated processes—without explicit licensing. Diageo had assumed these system-to-system communications were either covered under existing licenses or required no licensing at all. It was a common assumption at the time.

SAP disagreed spectacularly. The audit retroactively applied licensing charges for years of indirect access that Diageo had never explicitly licensed.

Why Diageo mattered:

• It was the first public, heavily-publicized enforcement of indirect access licensing
• It broke the ice on SAP's willingness to audit and claim massive retroactive fees for API/integration traffic that was never explicitly licensed
• It signaled to SAP's audit teams that indirect access was a high-value enforcement vector—and gave them cover to pursue similar claims at other enterprises
• It forced the market to confront a question enterprises had avoided: Who licenses third-party API calls to SAP?

The Diageo case also precipitated SAP's pivot toward the Digital Access model. Instead of leaving indirect access undefined and subject to audit disputes, SAP decided to commodify it. If you want third-party systems to call SAP, you buy Digital Access licenses. Explicit. Quantified. Priced.

From SAP's perspective, it's brilliant: retroactive enforcement pressure (Diageo-style audits) drives customers to voluntarily buy Digital Access to mitigate risk. Win-win for SAP.

From the buyer's perspective, it's extortion with better public relations.

Digital Access: What It Covers—And What It Doesn't

The Digital Access model launched after Diageo, and it's the licensing framework SAP now pushes for indirect access scenarios.

Digital Access is a document-based licensing model. Instead of paying per named user, you pay per document type accessed via third-party systems. SAP defines 9 core document categories:

When your third-party system accesses SAP data via REST, RFC, OData, or integration middleware, you categorize what documents are being touched, and you buy Digital Access licenses accordingly.

The catch: Digital Access licensing is volumetric. You're billed per thousand documents (or million, depending on negotiation). If your e-commerce system reads 10 million customer records per year from SAP, you need Digital Access licenses covering 10,000 document units—at SAP's pricing, often thousands or tens of thousands per unit.

What Digital Access doesn't cover:

• Batch processing exclusions: Most Digital Access agreements exclude explicit carve-outs for batch jobs, scheduled extracts, and read-only reporting if you negotiate hard. But SAP defaults to inclusion.
• Automated system user activity: System users with RFC destinations making hundreds of calls per month often fall outside Digital Access scope—but SAP auditors argue they trigger indirect access licensing anyway.
• Integration throughput on BTP: As discussed, SAP is now claiming that data flowing through BTP integration scenarios requires separate digital access licensing on top of BTP subscriptions.
• Real-time sync volumes: Modern integration patterns (Kafka streams, event-driven architectures, real-time CDC replication) create massive document read/write volumes. SAP often doesn't have clear pricing models for these scenarios, giving auditors license to be aggressive in claims.

The critical point: Digital Access is a pricing mechanism SAP uses to formalize and monetize indirect access. It doesn't eliminate the underlying licensing exposure—it just commodifies it.

Contractual Language: "Indirect Use" vs "Digital Access"

This is where contract forensics matter.

Many enterprises still have SAP contracts from the pre-Diageo, pre-Digital Access era. These contracts likely mention "indirect use" in their scope limitations or exclusions—but they often pre-date SAP's formal Digital Access pricing framework.

Here's the dangerous distinction:

Old Language (pre-2017): "Indirect use shall be limited to non-human access to SAP functionality through third-party systems for read-only reporting purposes." This carves out reporting APIs but leaves room for SAP to argue that write operations (creating orders, posting GL entries) require separate licensing.

New Language (post-Digital Access): "Digital Access is a separately licensed product model covering document-based access to SAP via third-party systems. Customer may purchase Digital Access licenses in increments of [X] documents per document type." This explicitly converts indirect access from a gray area into a separate revenue stream.

If your contract uses old language, SAP's position in an audit is: Your contract doesn't explicitly cover our Digital Access model. Therefore, you're in violation, and we can either retrofit Digital Access licensing, or claim you owe damages for unlicensed use.

Key contract language to examine:

• Definition of "Named User": Does it explicitly exclude system users, service accounts, and integration middleware? (Likely yes, which is bad for you.)
• "Indirect Use" clause: Does it explicitly carve out REST APIs, RFC calls, OData, and integration platforms? (Likely only partially, or not at all.)
• Digital Access scope: If your contract predates 2017, it likely doesn't mention Digital Access at all. That's a negotiating gap SAP will exploit.
• Batch processing & read-only access: Does the contract exclude these from licensing? (Most don't, despite batch being integral to SAP estates.)
• Third-party integration services: Does it carve out Data integration platforms, iPaaS, or middleware? (Almost never.)

The forensic approach: Pull your SAP contract, search for "indirect," "third-party," "API," "integration," and "system user." Score the gaps. Those gaps are your audit exposure.

How to Audit Your Integration Landscape

You can't defend what you don't see. The first step in indirect access risk mitigation is mapping your integration landscape with forensic precision.

Step 1: Identify All RFC Destinations & System Users

In SAP transaction SM59 (RFC Destinations), list every registered RFC connection. For each:

• Destination name (e.g., PROD_WAREHOUSE, CLOUD_BI)
• Target system (external system connecting to SAP, or SAP-to-SAP)
• Logon user (the system account making the calls)
• Connection frequency (daily, real-time, batch scheduled)

Next, cross-reference each system user (transaction SU01, filter for accounts with "SYS," "INT," "API" in the name) and check their activity logs in SUIM (User Information System). Look for:

• Login frequency and time patterns (batch jobs will have regular, scheduled patterns)
• Transaction codes accessed (if the system user runs BAPI_PO_CREATE1, it's writing purchase orders—high exposure)
• RFC calls made (visible in transaction SM37 for batch jobs, STAD for real-time traffic)

Step 2: Enumerate All REST & OData APIs

In S/4HANA, pull a list of all exposed OData services (transaction /IWFND/MAINT_SERVICE). Cross-reference with your third-party system integrations:

• Which external systems consume which OData endpoints? (E-commerce reads C_SALESORDER_TP, BI reads analytics cubes)
• Call volume: Instrument your REST/OData gateway with logging (most enterprises don't). If you can't measure it, SAP auditors will estimate aggressively.
• Authentication mechanism: If third-party systems authenticate via API keys or OAuth tied to service accounts (not named users), that's red-flag indirect access.

Step 3: Map Integration Middleware (PI/PO, BTP, iPaaS)

For each integration platform, document:

• Inbound integrations: Third-party systems sending data to SAP (orders, shipments, payments). Count documents processed per period.
• Outbound integrations: SAP sending data to third parties (GL extracts, customer masters, inventory balances). Count documents extracted per period.
• Bidirectional flows: Master data syncs, real-time event streaming. These are high-exposure because they involve repeated reads and writes.

In SAP BTP, pull integration flow execution logs to quantify throughput. If your data warehouse receives 100 million GL transactions per year from an SAP-to-cloud integration flow, that's 100M documents moved—potentially all chargeable as indirect access.

Step 4: Quantify Document Types & Volumes

Categorize your integration traffic by the 9 Digital Access document types (see previous section). For each document type, estimate annual volume:

• Sales orders: X per year (via API from e-commerce)
• Invoices: Y per year (extracted to AR system)
• GL entries: Z per year (synced to data warehouse)
• Master data reads: W per year (customer/vendor masters pulled by CRM)

This quantification becomes your negotiating baseline if you face an audit. You're prepared with data; SAP can't fabricate exposure.

Step 5: Identify Uncontracted Integrations

This is the killer finding. Go through your integration inventory and cross-reference against your SAP contract:

• Which integrations are explicitly mentioned or covered in the contract? (Probably none, unless you negotiated very carefully.)
• Which are implied but not explicitly scoped? (Most of them.)
• Which have no contractual basis at all? (The real exposure.)

Any integration not explicitly covered in your contract is potential indirect access exposure. Auditors will flag it, claim it's unlicensed, and demand licensing fees.

Negotiation Tactics: Seeking Exclusions & Carve-Outs

Once you've mapped your integration landscape, you're ready to negotiate explicit contractual carve-outs for indirect access risk.

Tactic 1: Batch Processing Exclusion

Seek explicit language exempting scheduled batch jobs from digital access licensing:

"Scheduled batch jobs, background tasks, and nightly extracts of SAP data for reporting, archival, or backup purposes shall not be considered indirect access and shall not require Digital Access licensing."

Why this works: Batch processing is non-interactive, deterministic, and doesn't constitute "use" in the traditional sense. SAP has conceded this point in many enterprise negotiations.

Tactic 2: Read-Only API Carve-Out

Push for an exclusion on read-only access via REST, OData, and RFC:

"Third-party systems may invoke read-only APIs, OData services, and RFC calls (SELECT queries only) to SAP without incurring Digital Access charges, provided such access does not modify master data or transactional documents."

Why this works: Read-only access is lower-risk to SAP (no audit exposure, no data integrity issues). SAP is often willing to concede it if you're willing to license write operations explicitly.

Tactic 3: Integration Platform Exemption

If you're licensed for PI/PO or BTP, negotiate that integration flows passing through these platforms are covered under the platform license, not charged as separate indirect access:

"SAP Integration Suite / Business Technology Platform subscriptions explicitly include licensing for all inbound and outbound data flows orchestrated through these platforms, including REST API calls, OData access, and document transformations, up to [X] million documents per month."

Why this works: It's reasonable to argue that integration platforms are licensed products, and their integration capability should be inclusive. SAP sometimes agrees, sometimes doesn't—depends on your leverage.

Tactic 4: Quantify & Cap Digital Access

If you can't get carve-outs, negotiate a fixed-price digital access tier based on your quantified integration volumes:

"Customer shall purchase Digital Access licensing covering up to 50 million documents annually across all document types, at a fixed annual cost of $[X]. Any volumes exceeding this cap shall be charged at $[Y] per million documents, with advance notice and approval from Customer required."

Why this works: It removes the audit ambiguity. You know your maximum exposure upfront. No surprises.

Tactic 5: Automated System User Clause

Some contracts still contain language that system users (as opposed to named users) are licensed under a separate tier. Enforce this rigorously:

"System users, service accounts, and technical user IDs that perform automated integration or batch processing shall be licensed under the System User licensing model, not the Named User or Digital Access models. System user licensing shall not exceed [Y] accounts, at a fixed annual cost per account."

Why this works: It preempts SAP's claim that RFC-using system accounts trigger indirect access. You've already licensed them, just under a different model.

Negotiation Leverage:

You have leverage if:

• Your contract is up for renewal and you have competitive options (move to Oracle, Infor, Microsoft Dynamics)
• You're a large customer (100+ named users, multi-year commitment)
• You can demonstrate that your integrations are mission-critical and a departure would be expensive for SAP to replace
• You have evidence of indirect access language in competitors' contracts (SAP concedes to some customers; make them concede to you)

Conversely, you have no leverage if you're a captive customer with no alternatives and a legacy SAP estate you can't exit. In that case, budget for digital access licensing as a cost of doing business.

DAAP and Its Limitations

SAP launched the Digital Access Adoption Program (DAAP) in recent years as a "voluntary" pathway to indirect access licensing. The idea: you self-report your indirect access usage, buy Digital Access licenses proactively, and SAP doesn't audit you.

It sounds reasonable. It's not.

How DAAP works:

• You assess your integration landscape and quantify document volumes (see Auditing section above)
• You self-report these volumes to SAP (or your SAP account team initiates the discussion)
• SAP quotes you Digital Access licenses to cover the volumes
• You buy the licenses, and theoretically, no audit exposure

Why DAAP looks attractive: It's certainty. Instead of facing a Diageo-style audit with $600M in surprise charges, you know your licensing exposure and can budget accordingly.

Why DAAP is a trap:

• Price anchoring: Once you self-report volumes, SAP's DAAP price becomes your baseline. If you negotiate with SAP's sales team later (during contract renewal), they'll use DAAP pricing as the floor. You've anchored yourself to the worst price.
• No carve-outs: DAAP doesn't include the contractual exclusions (batch processing, read-only APIs, etc.) you might negotiate in a contract amendment. You're buying full Digital Access licensing with zero flexibility.
• Perpetual commitment: Once you enter DAAP, SAP's expectation is that you'll maintain Digital Access licensing in perpetuity. Trying to exit later (by arguing that your contract doesn't require it) will trigger pushback and potential audit scrutiny.
• No audit immunity: SAP's official language on DAAP says it's a "voluntary compliance program," not a legal safe harbor. If SAP audits you later and finds indirect access not covered by DAAP, you could still face exposure.
• Volume growth:**** DAAP is priced based on your current integration volumes. If you add new integrations or increase throughput, SAP will re-price DAAP upward, creating a ratchet effect.