SAP STAR Tool: How It Measures Indirect Access

The technical forensics of SAP's measurement engine

SAP STAR is not a single tool—it's a forensic measurement framework designed to detect and quantify every possible route through which your enterprise accesses SAP systems indirectly. Understanding exactly how STAR detects, classifies, and measures indirect access is the foundation of any credible audit defense.

This deep-dive breaks down the technical mechanics: how STAR traces data flows, what counts as "access" in SAP's model, where the measurement assumptions create systematic bias, and most importantly, how to challenge STAR's findings with credible technical counter-evidence.

How STAR Detects Indirect Access: The Trace-Back Architecture

STAR's core function is flow tracing. When SAP's auditors deploy STAR, it instruments your SAP systems to record every database query, API call, RFC (Remote Function Call), and external system integration. STAR then works backward from each access point to determine its origin.

Example: A user in your enterprise data warehouse queries a sales order summary table in SAP. STAR records that query and traces it backward through the system logs:

• Layer 1 (Database) — Records the SELECT query hitting the sales order table
• Layer 2 (Application Logic) — Maps that query to the module that serviced it (Sales & Distribution)
• Layer 3 (Origin System) — Identifies the requesting system (Data Warehouse) as non-SAP
• Classification — Marks this as "indirect access" because the query originated outside the SAP system

The critical problem: STAR's trace-back doesn't distinguish between:

• A real-time operational integration your business depends on hourly
• A batch export that runs nightly at 2 AM for reporting purposes
• A read-only query that accesses a single archived record
• A duplicate query that pulls the same data twice due to system redundancy

All of these show up identically in STAR reports: as "access events." This is where SAP's measurement biases begin.

📬 SAP Licensing Intelligence

Get Independent SAP Licensing Insights

Expert analysis on SAP audits, contracts, and cost reduction — direct to your inbox. Corporate email required.

Please use a corporate email address (no Gmail, Yahoo, Hotmail, etc.)

Subscribe — Free Intelligence →

STAR Classification: The Binary Problem

STAR classifies access into a handful of categories:

The problem: SAP treats all Type 2 (indirect system) access the same way in licensing calculations. A batch job that pulls reference data once per week gets the same licensing treatment as a real-time operational system that hits SAP 10,000 times per day.

This is where you gain audit leverage. SAP STAR reports will show the volume of access events, but they won't distinguish business-critical integrations from optional reporting feeds. You rebuild the narrative by categorizing each integration by actual business necessity.

How STAR Measures API and RFC Access

Most indirect access in modern enterprises routes through APIs (OData, REST) or RFCs (Remote Function Calls). STAR specifically instruments these integration points.

API Access Measurement

When your middleware, data warehouse, or custom application makes an API call to SAP (e.g., fetching a sales order via the OData API), STAR records:

• The API endpoint called (e.g., /sap/opu/odata/sap/C_SALESORDER_SRV)
• The timestamp of the call
• The source system making the call
• The data entity accessed (orders, inventory, GL balances, etc.)
• Whether the operation was a read or write

STAR then aggregates: "Over 30 days, your enterprise made 847,000 API calls to SAP systems. By default, this is classified as indirect access requiring licenses."

Your counter-argument: How many of those calls are duplicate reads? How many are batch operations that could run once daily instead? How many are optional reporting that doesn't affect actual operations? The raw call count is not the same as licensing exposure.

RFC Access Measurement

RFCs are older SAP integration mechanisms. STAR instruments RFC gateways to detect inbound and outbound RFC calls. An external system invoking BAPI_SALESORDER_GET_LIST to fetch orders = RFC access = potential indirect licensing exposure in SAP's model.

The same issue applies: STAR counts RFC invocations without distinguishing between mission-critical operational integrations and batch reporting jobs.

The Database-Level Measurement Blind Spot

STAR also monitors direct database access. If your enterprise has granted read access to SAP's database tables (a common scenario in data warehouse setups), STAR tracks every SELECT query against those tables.

This creates a major exposure problem in STAR's model:

• Your data warehouse mirrors SAP data by running nightly batch jobs: 1 database read = 1 "access event" in STAR
• Your BI tool queries that mirrored data 1,000 times daily: 1,000 "access events" in STAR
• But these are two different layers of the same data. You shouldn't be charged twice

SAP STAR often double-counts access through this layer problem. Your defense: demand that SAP consolidate multi-layer access paths and report on actual licensed access points, not aggregate query counts.

Frequency vs. Volume: The Measurement Problem

A critical STAR limitation: it doesn't properly account for the difference between:

• Frequency — How often an integration accesses SAP (hourly, daily, yearly)
• Volume — How much data moves through the access (1 record vs. 1 million)
• User Equivalency — What proportion of a Named User's license consumption does this represent

STAR's measurement is essentially volumetric: it counts access events (API calls, queries, RFC invocations) without normalizing for frequency or business necessity. A system that polls SAP once per hour gets the same licensing treatment as a system that makes an ad-hoc query once per month, even though the first represents vastly higher actual usage.

This is where you challenge STAR findings quantitatively. Convert STAR's access event counts into actual user equivalency metrics. Then compare that to your contract's definition of indirect access. Most contracts define indirect access in ways that don't match STAR's raw event counting.

The Multiple Integration Path Problem

Many enterprises have complex, redundant system architectures. Your ERP data might be accessed through:

• API Layer 1 — Primary integration middleware
• API Layer 2 — Backup/failover integration (mirrors Layer 1)
• Direct Database Access — For analytics/reporting
• Third-Party Data Hub — Consolidates data from multiple systems

STAR will detect all four of these paths as separate indirect access routes. But you're accessing the same underlying data. SAP's measurement counts each path independently, creating systematic over-statement of licensing exposure.

How to Respond to STAR Measurement Findings

When SAP presents STAR audit findings, follow this forensic framework:

Step 1: Request Raw STAR Output

Don't accept summary statistics. Demand the raw STAR logs showing each detected access point, classified by type (API, RFC, database query), with timestamps and originating systems. This level of detail will reveal STAR's assumptions and measurement errors.

Step 2: Map Your Actual Integrations

Create your own integration map before the audit. Document every system that touches SAP, the purpose of each integration, frequency, data volume, and business necessity. Then cross-check against STAR's findings. Look for:

• False positives (integrations STAR detected that don't actually exist)
• Double-counting (same data accessed through multiple layers)
• Outdated integrations (STAR found integrations you've already decommissioned)

Step 3: Challenge the Classification

For each indirect access finding, challenge SAP on classification:

• Is this read-only or read-write? (Read-only has lower licensing exposure)
• What is the actual frequency of access? (Once daily vs. 1,000 times daily = very different exposure)
• What is the business necessity? (Critical operations vs. optional reporting)
• Is this data access mirrored elsewhere? (Can be deduplicated)

Step 4: Propose Alternative Measurement

SAP STAR measures based on technical access events. Propose measuring based on your actual contractual indirect access definition, which typically focuses on unique external systems that access SAP, not the aggregate volume of all queries those systems make.

This shift from event-based to system-based measurement typically reduces claimed indirect access exposure significantly.

STAR in the Broader Audit Context

STAR measurement doesn't happen in isolation. SAP uses STAR findings in coordination with:

• SAP Solution Manager — Reporting and compliance flagging
• SAP for Me portal telemetry — System configuration baseline
• USMM and LAW — Additional usage measurement frameworks

Each of these systems provides SAP with different data about your licensing exposure. STAR is the access measurement tool. The others provide usage quantification and historical trending. Together, they form SAP's comprehensive licensing audit arsenal.

For comprehensive audit defense strategy covering all three measurement systems, see our full SAP STAR Measurement Deep Dive.