SAP Indirect Access Licensing: What CIOs Need to Know

SAP Indirect Access refers to situations where users or devices interact with an SAP system indirectly, through third-party platforms, interfaces, or custom applications, rather than logging in directly to SAP.

In these scenarios, SAP’s data or business processes are being utilized behind the scenes. For example, an employee might use a non-SAP application, such as a web portal, mobile app, or external software, which then queries or updates data in SAP on their behalf.

From a business process perspective, the work is still being done in SAP (e.g., creating a sales order or updating inventory), but the user never explicitly opens the SAP GUI.

Technically, this often happens via APIs, middleware, or background integrations that connect external systems to SAP. Simply put, if SAP software is being used by any person or system, that is considered indirect access.

Understanding and managing indirect access is crucial because it has significant licensing implications. SAP traditionally requires that all usage of its software be licensed, whether the access is direct (by a human user in SAP) or indirect (via another system).

Indirect access has historically been ambiguous in contracts and a source of confusion, resulting in unexpected compliance issues during audits.

This advisory article, written from the perspective of an independent SAP licensing expert, will explain what indirect access is, why it has become a compliance hotspot, how SAP’s new Digital Access model works, and strategies for CIOs to govern and optimize their SAP licensing in the face of indirect use.

What Is SAP Indirect Access?

SAP Indirect Access (also now termed “Digital Access” by SAP) is any use of SAP’s functionality by a user or process that does not log in through the standard SAP interface.

Instead of a person directly entering data into SAP, a third-party application or automated process does it.

Common characteristics of indirect access include:

• Mediated Access: A non-SAP system, such as a customer portal, e-commerce website, CRM, middleware, or IoT device, serves as the front end. It collects input from users or devices and then transmits that data to an SAP system in the back-end. The end user might not even know SAP is involved.
• Triggered SAP Transactions: The third-party system might create or update records in SAP (for example, posting an order, retrieving inventory levels, or generating an invoice) by calling SAP APIs, sending IDocs, or using other integration methods. SAP performs its normal processing, but the trigger came indirectly.
• No Direct SAP Login: The people or devices initiating the actions do not have an SAP user session. They might be customers on a website, employees using a non-SAP mobile app, or sensors sending data – none of whom log into SAP, yet SAP ends up doing work on their behalf.

It’s important to note that not all data access counts as licensable usage. SAP draws a line between active use (which requires a license) and passive use.

A key concept is the Indirect Static Read. Suppose data is exported out of SAP to an external system and merely viewed there (with no further action back into SAP).

In that case, SAP generally does not require an additional license for that read-only scenario.

For instance, if a nightly job extracts SAP data to a third-party reporting tool and users only view it there without triggering any SAP processing, that would typically be considered a static read and not incur indirect usage fees.

The moment the external system tries to write back to SAP or execute transactions in SAP. However, it moves into licensable indirect access territory.

In summary, SAP indirect access covers any scenario where SAP’s capabilities are being invoked by something other than a direct SAP user, except purely read-only exports under the static read policy.

Why Indirect Access Became a Compliance Risk

Indirect access has been a major compliance risk for SAP customers because it was historically poorly defined yet aggressively enforced. Many CIOs were caught off guard by the breadth of SAP’s licensing claims in this area.

Here’s why it became such a hot issue:

• Vague Contract Language: Older SAP contracts often state that all use of the software, “directly or indirectly,” must be licensed without detailing what that means. This ambiguity left room for SAP to interpret almost any third-party integration as a licensable event. Companies that extended their SAP with new digital channels thought they were innovating, only to later discover they had tripped an invisible wire in the contract.
• High-Profile Audit Cases: The issue leapt into prominence due to several high-profile audit disputes. In one notable case, Diageo (2017) – a global beverage company – had connected its Salesforce CRM cloud to SAP ERP to input sales orders. A UK court ruled that Salesforce users were indirectly using SAP and were unlicensed, resulting in Diageo owing around £54 million in license fees and penalties. Around the same time, SAP pursued other large customers, such as Anheuser-Busch InBev, for tens of millions of dollars over similar indirect use of SAP through e-commerce and supply chain systems. These cases shocked many SAP customers and made headlines in the ERP community. CIOs suddenly realized a simple integration could trigger massive financial exposure.
• Aggressive Audits: Following such cases, SAP auditors increasingly scrutinized integrations. Indirect access went from a niche technical nuance to a mainstream audit focal point. Companies that had happily integrated third-party apps with SAP for years found auditors questioning whether every person who touched those third-party apps had an SAP license. Indirect usage became a favourite compliance “gotcha” – often uncovered during true-up or contract renewal discussions – sometimes perceived as a tactic to drive additional license sales. This dynamic created a climate of fear around innovations that involve SAP’s backend.
• Business Impact: The risk wasn’t just theoretical. Organizations faced budgetary shocks when an audit reclassified their usage. For example, an online sales portal might connect to SAP to create orders. If SAP deemed that every customer or agent using that portal required a full SAP user license, the licensing liability could be enormous, wiping out the ROI for the project. Thus, indirect access concerns began to hinder digital initiatives, as IT leaders worried that a new integration could later lead to an audit penalty.

In summary, indirect access became a compliance minefield because SAP’s stance was that any SAP functionality used must be paid for. Without clarity on how to count that usage, many customers inadvertently fell out of compliance. This combination of unclear rules and strict enforcement turned indirect access into a major audit trigger and a source of unplanned costs.

Real-World Examples of Indirect Access

To illustrate, here are several common scenarios where indirect access comes into play in everyday business processes:

• E-Commerce Web Store Integration: A company runs a non-SAP online storefront where customers place orders. When an order is submitted, the website calls an SAP API to create a sales order in SAP ECC/S4HANA. Neither the customer nor the web admin logs into SAP, but SAP is processing sales transactions initiated externally. This external ordering system is effectively using SAP indirectly. Many companies have discovered that an online shop (or a SAP Hybris/SAP Commerce competitor solution) connecting to SAP can trigger indirect licensing fees for each order or customer using it.
• CRM to SAP Order Entry: The sales team uses a cloud CRM, such as Salesforce, or another CRM, to manage leads and quotes. When a deal closes, the CRM system automatically sends the order data to SAP, which generates a Sales Order or Invoice. The sales reps never use SAP directly, yet SAP’s sales module is executing those orders behind the scenes. In the Diageo case, this was exactly the scenario – Salesforce users input orders that SAP fulfilled, leading SAP to claim those users needed SAP licenses.
• Warehouse Management System (WMS): A third-party WMS or logistics system on the warehouse floor scans barcodes and updates inventory. It might send goods movement transactions to SAP in real-time to decrease stock or record a shipment. Here, warehouse workers operate on a non-SAP interface, but SAP’s inventory is updated via an integration. SAP would consider each warehouse user (or each inventory transaction) as indirect access to SAP’s materials management functionality.
• Supplier/Vendor Portal or EDI: Suppliers may use a B2B portal to send order confirmations or invoices, which then flow into your SAP system, possibly via EDI messages. For example, a distributor submits a purchase order through a portal, which creates a Purchase Order in the manufacturer’s SAP system. Even though the distributor is external, their actions are creating SAP documents. Similarly, suppose SAP sends an order or forecast to a vendor’s system, which triggers a process on the vendor’s side that loops back into SAP (such as an ASN or confirmation). In that case, those interactions can count as indirect access events.
• Human Capital Management Integration: An organization may have a cloud HR system (such as Workday or SuccessFactors) or a payroll system that manages employee data. Periodically, it updates SAP’s HR or finance modules with relevant info (e.g., posting payroll results into SAP Finance or updating employee master data in SAP). Those automated updates in SAP constitute indirect access – the HR system’s users or processes drive changes in SAP without a direct login.
• IoT and Automation: Modern IoT sensors, robotic process automation (RPA) bots, and custom mobile apps often interact with SAP. For instance, an IoT device on a manufacturing line might trigger a maintenance order or quality inspection in SAP when it detects an anomaly. Or a custom mobile app for field technicians might record service data and create a service order in SAP Plant Maintenance. Even chatbots or RPA scripts that fetch or input data into SAP – all of these represent non-human or external agents invoking SAP functionality. SAP can see each of these as an indirect user that needs licensing consideration.

In each example above, the thread is the same: SAP is doing work on behalf of external actors. SAP and auditors have explicitly identified these scenarios as situations where you must have sufficient licenses, either for the users or the transactions they generate.

Even if the external user is a customer or partner (not an internal employee), from SAP’s perspective, they are consuming SAP resources.

Historically, the only way to cover these scenarios was to either find a matching named-user license type for each user, which is often impractical for hundreds or thousands of external users, or to purchase special SAP engine licenses or packages for those interfaces.

This is why CIOs saw indirect access as a compliance trap – it could extend SAP’s licensing reach to every customer, partner, or device interacting with your systems.

SAP’s Licensing Models: User-Based vs. Digital Access

To address the confusion and backlash surrounding indirect usage, SAP introduced a new licensing approach in 2018 called Digital Access. Today, organizations have two distinct models to license SAP usage (and many run a hybrid of both):

• Traditional Named User Licensing: Under this classic model, every individual or system that uses SAP, directly or indirectly, is assigned a named user license. These licenses come in types (e.g., Professional User, Limited Professional, Employee Self-Service, etc.) depending on the level of use. In an indirect scenario, this model technically requires that each end-user of a third-party system be licensed as an SAP-named user if their actions result in SAP transactions. For example, if 1,000 customers place orders via a non-SAP web portal that feeds into SAP, SAP’s strict interpretation was that 1,000 named user licenses might be needed (one per customer) or an equivalent special license. In practice, most customers are never licensed that way; it’s not feasible to license every external party. Companies either ignored the issue, hoping not to be audited, or purchased a smaller number of licenses for “technical users” (such as the one-interface account) as a stopgap. This model offers simplicity, as a licensed user can perform unlimited transactions, and it aligns with how internal employees are typically licensed. However, it breaks down for high-volume digital scenarios – it can become astronomically expensive or operationally impossible to assign a license to every external user or device. It also made audits cumbersome: counting indirect users was not straightforward, leading to disputes.
• SAP Digital Access (Document-Based Licensing): The digital access model is SAP’s answer to modern use cases. Instead of tying licenses to people, it ties them to business documents processed by SAP. SAP identifies nine core document types that cover the most common transactions, such as Sales Orders, Purchase Orders, Invoices, Deliveries, and Production Orders. Under this model, if an external system triggers the creation of any of those documents in SAP, you need to license that document event. The cost is based on volume; typically, SAP sells digital access in packs, such as blocks of 1,000 documents. Each document type is counted, often at the line-item level, and some types are weighted differently (for example, Financial documents and Material documents have a lower weight in the license count, recognizing that these can be of very high volume). Reading or querying data is free under this model – only the initial creation of a document counts, and any subsequent downstream documents automatically generated by SAP from that event (say a delivery or invoice that results from a sales order) do not count again. In essence, SAP shifted the conversation to “How many documents are created via third-party access?” rather than “How many users are there?”. This approach aims to provide a more measurable and business-outcome-oriented metric. For example, if your e-commerce platform created 10,000 sales order line items in SAP last quarter, you would need to have purchased at least 10,000 digital access documents (assuming each line = one document count). The benefit is you don’t have to worry about how many users or devices initiated those orders – you just count the documents.

Both models have merits and drawbacks, and SAP allows customers to choose or mix models based on what is most cost-effective.

The table below compares key aspects of User-Based licensing vs. Digital Access licensing:

In practice, many SAP customers are in a hybrid state: they retain Named User licensing for their direct users (employees, core SAP users) and have adopted Digital Access to cover certain indirect scenarios (especially customer-facing channels).

SAP’s current policy allows mixing models, but you must be careful to delineate which usage is counted in which way to avoid double licensing. For example, suppose an internal employee already has a named user license and triggers a document via an external system.

In that case, you should not have to pay twice (one user license plus one document count for the same activity). Ensuring your contract spells out such situations is important so that you’re not double-charged.

Indirect Access Triggers: Documents and Integrations that Incur Fees

Under the Digital Access model, SAP has specified nine document types that are taken into account when evaluating indirect usage fees. These document types correspond to high-level business objects in SAP that external systems commonly create or influence.

Whenever a third-party application causes one of these documents to be created in SAP, it is a licensable event.

The nine covered document categories (with examples) are:

• Sales Documents: e.g., Sales Orders, Sales Contracts, or Quotes created in SAP SD. (Any customer order coming from an external source would fall here.)
• Purchase documents, Such as Purchase Orders or Purchase Requisitions, in SAP MM. (For instance, a purchasing portal or EDI creating POs in SAP.)
• Invoice Documents: e.g., Billing Documents or Supplier Invoices in SAP SD/MM. (External billing systems feeding invoices into SAP, or vice versa.)
• Manufacturing Documents: e.g., Production Orders, Process Orders, or shop floor confirmations in SAP PP. (An MES system triggering production orders in SAP.)
• Material Documents: e.g,. Track inventory goods movements, receipts, and issues in SAP MM. (A warehouse scanner system posting stock changes to SAP creates material document line items.)
• Quality Management Documents: e.g., Quality Inspection results, defect records in SAP QM. (If an external quality system records inspection outcomes into SAP, those are counted.)
• Service & Maintenance Documents: e.g., Maintenance orders, service orders, notifications, warranty claims in SAP PM/CS. (IoT devices or field service apps creating maintenance notifications in SAP.)
• Financial Documents: e.g,. Journal entries or accounting documents in SAP FI. (External financial interfaces posting ledger entries into SAP’s finance module. These have a lower weight in SAP’s model, since even indirect processes can generate many financial entries.
• Time Management Documents: e.g., Time sheets or attendance records in SAP HR/Time Management. (Kronos or other time-clock systems interfacing employee hours into SAP HR would trigger these.)

Each document is typically counted at the line item level (since one high-level document can contain multiple line items). SAP assigns a “multiplier” to each category (most have a multiplier of 1.0, whereas Financial and Material documents have a multiplier of 0.2 in the licensing calculation – effectively they count less towards the total, recognizing their high frequency).

The licensing mechanism checks the initial creation of documents of that type by external input. For example, suppose an external CRM triggers a Sales Order, which later results in a Delivery and an Invoice within SAP.

In that case, SAP will count only the Sales Order for licensing purposes because the Delivery and Invoice were subsequent documents created by SAP’s internal process, not directly by the third-party system.

It’s also worth noting that the integration method doesn’t affect the license requirement – whether the external system connects via SAP’s API, through an SAP integration middleware like Process Orchestration (PO/PI), via IDoc file exchanges, or any other interface, the effect is the same.

SAP looks at the outcome (was a document created? was data updated?) rather than the technical method. Even use of SAP’s middleware (SAP PI/PO or Cloud Integration) does not exempt you; it might be required to license the middleware itself, but the documents created in SAP still count as indirect usage.

The only exemption, as mentioned earlier, is if the external activity does not create or change any SAP records (pure read-only data access).

Indirect static read situations (data extracted out to third-party with no follow-up transactions) are explicitly free of additional charges under SAP policy. However, customers must ensure that these scenarios truly meet SAP’s criteria (e.g., the data export is performed by a properly licensed user or an automated job, it is done on a scheduled or controlled basis, and it does not result in any updates being sent back into SAP).

If those conditions hold, you can, for instance, feed a data warehouse or reporting system from SAP without paying indirect usage licenses for the people viewing reports. But the moment that external system starts sending data or triggers back into SAP, you’ve crossed into indirect use.

For CIOs, the key takeaway is to identify which integrations in your environment create these document types in SAP. Those are the ones that potentially drive indirect licensing costs.

By mapping each interface to the document types it generates, you can quantify your exposure (e.g., “Our e-commerce integration creates ~5,000 Sales Documents per month; our third-party logistics system creates ~500 Material Documents per month,” and so on).

Assessing Indirect Access Exposure in Your SAP Landscape

Before you can manage or mitigate indirect access risk, you need to measure and assess the actual amount of indirect usage. This assessment is a critical step for CIOs to gain visibility.

There are a few methods and tools available:

• SAP License Audit Tools (USMM and LAW): SAP provides built-in tools for license administration. The USMM (User Measurement) transaction in each SAP system collects data on named users and certain activity metrics. The LAW (License Administration Workbench) aggregates data from multiple systems to produce a combined audit report. Historically, USMM/LAW were oriented toward counting users and some engine metrics, and they did not automatically flag indirect usage. It was up to auditors or the customers to notice that hundreds of people were using a single “interface” user in SAP via an external system. In recent years, SAP has updated these tools (via OSS Notes and support packages) to capture metrics related to Digital Access. There are Digital Access estimation notes that, when implemented, enable USMM to count documents generated by certain technical users. It’s essential to ensure your SAP systems have these updates if you want to track indirect document counts internally.
• Digital Access Evaluation Service: SAP offers a free one-time evaluation service to customers, sometimes referred to as the Digital Access Assessment or Evaluation Tool. As part of this service, SAP provides scripts or activates tools in your system to scan for all documents (of the nine types) created by external means over a period of time. Typically, this involves identifying technical users (RFC users, background users, and integration accounts) that external systems use to log in to SAP, and then analyzing SAP logs and tables to see how many documents of each type those accounts generated. The output might be something like: “In the last 12 months, user X created 8,000 Sales Documents and 2,000 Invoice Documents,” etc. Summing across all integration users gives a sense of the total number of indirect documents. This service helps customers gauge “If we were on digital access, how many documents would we be charged for?” It’s a valuable baseline to decide whether to stick with user licenses or switch to document licensing. CIOs should engage with SAP on this – there is no cost to measure, and it demonstrates due diligence.
• Manual and Log Analysis: Even outside of formal SAP tools, your technical team can manually investigate indirect usage. SAP systems have audit logs and tables (e.g., STAD records for user activity, change logs for documents) that can be filtered by user ID or source. An SAP administrator can identify all external interface accounts (for example, users with the “Communications Data” type or any RFC users used by middleware) and then check the transactions or documents they create. Also, SAP’s Audit Information System (AIS) contains predefined queries and reports that can highlight unusual usage patterns, such as a single user ID creating thousands of transactions, which is typical for an interface account. By analyzing RFC connections, queued IDoc senders/receivers, or web service call logs, you can uncover which external systems are talking to SAP and what they do.
• Third-Party License Management Tools: In addition to SAP’s tools, there are third-party software asset management solutions from vendors like VOQUZ, Snow Software, and Flexera that offer specialized SAP license analysis capabilities. These tools can often scan SAP systems to identify indirect usage patterns and even simulate the cost under different license models. If your organization has a large SAP footprint with many integrations, investing in such a tool or service can pay off by finding compliance issues before SAP does. They can continuously monitor usage so you can correct course mid-year rather than after an official audit.

Performing an internal indirect usage audit is highly recommended before SAP auditors arrive. It puts you in control of the narrative. When you know, for instance, that “System A is creating 25,000 documents/year, which we haven’t been licensing under our old model,” you can proactively address it (either by purchasing the needed licenses or re-architecting that integration). The goal is to eliminate surprises.

A practical tip: maintain an integration catalog – a simple inventory of all third-party systems that interface with SAP, including the purpose of each integration and the technical user or method used.

Keep this list updated as new projects go live. Many organizations are surprised to discover “rogue” interfaces that were set up years ago and forgotten, or new cloud services that were connected without proper license oversight.

By combining this catalog with usage data from the tools above, you can pinpoint where indirect access is happening and quantify it.

Strategies for Mitigating Indirect Access Compliance Risks

CIOs and IT leaders shouldn’t view indirect access as purely a threat; it can be managed with a strategic approach.

Here are several strategies to mitigate compliance risks and optimize your licensing:

1. Proactive Governance and Monitoring:

Don’t wait for an SAP audit to reveal indirect use – implement governance processes internally. Make it a policy that any new integration with SAP is reviewed by your architecture and licensing team. Include license impact as a checkpoint in project planning. Regularly review logs and run the measurement tools (USMM/LAW or third-party tools) to track indirect activity.

Essentially, treat indirect usage like you would treat security or performance: something to monitor continuously. By catching growth in external usage early, you can adjust licensing or technical approaches before it becomes a compliance issue.

Many leading CIOs conduct quarterly or biannual internal license compliance reviews, specifically focusing on interfaces and indirect use.

2. Architectural Design Changes:

In some cases, you can re-architect how systems interact with SAP to reduce licensable events or take advantage of more favorable licensing terms. For example:

• If an external system makes very frequent calls to create SAP documents (high-volume transactions), consider using a batch or aggregator approach. Instead of creating hundreds of individual documents, accumulate the data and post a single, summarized document periodically, if the business allows. Fewer documents mean lower digital access counts.
• Utilize indirect static read where possible. If external users only need to view SAP data, push that data out on a schedule to avoid making real-time calls for each query. This way, reads don’t incur license costs. A cached data repository or data warehouse can service many queries without needing to ping SAP each time.
• Evaluate if some processes currently done through third-party systems could be accomplished via SAP’s tools, for which you’re already licensed. For instance, if you have an external reporting portal just to display SAP data, you might leverage SAP’s web UI or Fiori apps for those users, which would then be a direct use under existing user licenses. This isn’t always feasible, but sometimes using SAP’s provided interfaces for self-service, such as SAP’s ESS/MSS for employees or the SAP supplier portal, may be covered under specific license categories you already have.
• Streamline integrations through a middleware. If you have multiple external systems that all create similar documents in SAP, see if they can be integrated through a single, controlled point, such as an enterprise service bus or SAP Cloud Platform Integration. This doesn’t eliminate the licensing need, but it makes it easier to monitor and potentially consolidate the logic so that you avoid duplicate or unnecessary document creation. It also means you have fewer technical user IDs to track in SAP, which can simplify compliance management.

3. Optimize Your License Model (Named Users vs. Documents):

There is no one-size-fits-all – the right model depends on your usage profile. Perform a cost comparison analysis: What would it cost to cover all indirect usage with named users versus with digital documents? Often, low-volume scenarios (a handful of external transactions or limited integrations) can be covered affordably by a few named user licenses.

For example, buying 5 extra SAP user licenses might be cheaper than 1,000 document licenses if you only process a few hundred transactions a year. Conversely, high-volume environments, such as thousands of orders from a web shop, are usually better served by document licensing.

You may end up using a hybrid approach: keep named user licensing for internal or low-volume needs and use digital access for large-scale external processes. Importantly, negotiate with SAP when optimizing the model.

SAP has offered license exchange programs, for instance, allowing you to convert the value of unused named user licenses into credit towards digital access documents.

They also, at times, offered steep discounts (up to 90% off) for customers who early adopted the digital access model as part of a formal program, the Digital Access Adoption Program.

Even if those official programs lapse, SAP sales reps often have the leeway to structure a deal that makes moving to digital access attractive, especially if you’re also moving to S/4HANA or a new SAP cloud contract.

The key is to crunch your numbers (with help from license experts) and approach SAP with a proposal that fits your usage. This way, you turn compliance into an opportunity to potentially get a better pricing model.

4. Avoid Double-Counting and License Overlap:

If you adopt the Digital Access model, ensure your licensing scope is adjusted so you’re not paying twice for the same activity. For example, suppose your customer portal orders are now licensed via digital access documents.

In that case, you shouldn’t also need a named-user license for each customer (and your contract should explicitly state that those customer activities are covered by digital access and are exempt from named-user counts).

Internally, educate your SAP security and BASIS teams to correctly classify and separate users: human users vs. technical integration users, and which ones fall under which license model. A clear delineation will prevent confusion.

SAP allows a mix, but you must carefully manage which licenses apply to which scenarios. Many organizations set up separate license measurement groups or classifications in SAP to track “digital access documents’ separately from” named user’ usage, which helps with audits.

5. Fortify Your SAP Contracts:

The ambiguity of indirect access can be lessened by getting clarity in writing. When negotiating renewals, insist on explicit definitions of what constitutes indirect usage and how it will be handled:

• For instance, include wording that mirrors SAP’s stated policy: “Static read access by third-party systems (no changes to SAP data) does not require a license.” This ensures that even if personnel change on SAP’s side, your contract protects that scenario.
• If you’re adopting Digital Access, have the contract clearly state that for the covered document types, you will not also be required to buy named users – Digital Access is the exclusive metric for those.
• If you are not adopting Digital Access yet, consider adding language that if SAP introduces new license metrics (such as document licensing), it won’t be imposed on you unless you agree to it, to avoid unexpected changes.
• Essentially, remove grey areas: list known interfaces and how they are licensed (some companies even append an exhibit: e.g. “Salesforce integration – licensed via 100 Professional Named Users” or whatever was agreed, so there’s a record). While SAP contracts are dense, as a CIO you should treat this like any risk management: involve legal counsel and licensing experts to negotiate terms that prevent misunderstandings later. A well-negotiated contract is one of your best defenses against disputes related to indirect access.

6. Leverage SAP and Vendor Relationship:

Work with SAP proactively. If you know you have a compliance gap, it’s often better to approach SAP (perhaps via your account manager) to discuss how to rectify it, rather than waiting for an audit to catch you. SAP, ultimately, wants to sell licenses, not necessarily to penalize loyal customers.

By coming forward, you might be able to negotiate a better deal, possibly by bundling a needed purchase with another renewal. Also, if you’re moving to S/4HANA, that’s a prime time to clean up indirect access issues – SAP may offer incentives or credits as part of the migration licensing.

Use that opportunity to get a modern contract that settles indirect access once and for all (for example, many S/4HANA contracts now bake in digital access provisions). The tone has shifted in recent years: SAP has publicly stated that it separated its audit function from sales to reduce the feeling that audits are a sales tool.

While enforcement is still a reality, SAP understands the negative press from cases like Diageo’s. Customers who engage in good faith to license what they use will often find SAP receptive to finding a fair solution.

7. Budgeting and License Reserves:

From a financial governance perspective, plan and budget for indirect access as a line item. Much like you budget for user growth, budget for transaction growth as well. If your digital business is expanding (with more online sales and connected devices), anticipate that in 1-2 years, you may need more SAP licenses (user or document) to stay compliant.

Some organizations build a “license buffer” into their agreements – for example, purchasing a block of extra documents beyond current usage or an allotment of additional users at a locked-in price – to accommodate growth without incurring immediate extra costs.

This can be negotiated; for instance, SAP might allow a 10-15% growth margin on document counts before the next price tier kicks in, or agree on price protection for additional blocks. The CIO should ensure that any financial risk from indirect use is understood by the CFO as well, so that there’s no shock when funding needs to be allocated.

By making it a budgeted item, IT leadership can make a case to the business that integrations and innovations have a known cost (licenses), which need funding just like any other infrastructure.

By combining these strategies – governance, smart architecture, optimized licensing, and proactive vendor management – companies can significantly mitigate the risk of indirect access.

Rather than stifling innovation out of fear, CIOs can enable the business to integrate and extend SAP systems confidently, with the assurance that they are properly licensed and in control.

Recommendations

To CIOs and IT Leaders: Indirect access licensing can be complex, but with proper oversight, it’s manageable. Here are our key recommendations to audit, govern, and budget for SAP indirect access:

• Inventory and Audit Regularly: Create an immediate inventory of all third-party systems interfacing with SAP. Conduct an internal audit to identify what indirect activities are happening (what data is accessed or what documents are created). Use SAP’s measurement tools or logs to quantify the volume of indirect transactions. Repeat this audit at least annually, or before any SAP true-up, so you always know your exposure.
• Use SAP’s Evaluation Tools: Take advantage of SAP’s Digital Access Evaluation Service or similar tools to measure document usage. Even if you haven’t switched to document licensing, understanding how many documents your integrations generate will inform your strategy. Treat the results as a planning metric, not just an audit afterthought.
• Compare Licensing Options: Perform a cost-benefit analysis between sticking with Named User licenses versus adopting Digital Access (or a mix). This analysis should consider current usage and future growth. Don’t assume the new model is always cheaper – it depends on your scenario. Conversely, don’t shy away from digital access if it provides scalability for your business model. Choose the model (or combination) that minimizes cost and compliance risk for your situation.
• Engage with SAP Proactively: If your analysis shows a shortfall (i.e., you are under-licensed for the indirect usage occurring), engage with SAP proactively before an audit. Initiate discussions on adjusting your licensing. SAP is more likely to offer a reasonable deal in a voluntary negotiation. Leverage any upcoming contract renewal or S/4HANA migration to include modern indirect use terms or to trade in old licenses for digital access credits. Always negotiate for clarity and fairness in the contract (explicit definitions of indirect use, exclusion of static reads, no double licensing).
• Strengthen Internal Governance: Implement a governance policy that requires no new integration to go live without a licensing review. Your enterprise architecture board or change management should include a checkbox for “SAP licensing impact”. Educate project teams that even if an app doesn’t involve an SAP GUI user, it may still require SAP licenses. This way, licensing is considered at design time, allowing you to plan for any needed licenses in the project budget and avoid surprises later.
• Monitor Continually: Implement monitoring for integration of user activity in SAP. Set up alerts or periodic reports for high-volume document creation by interface accounts. Early detection of a spike (say a new e-commerce channel dramatically increased order volume) allows you to react – either by throttling, optimizing, or purchasing additional document capacity – before it violates your license terms.
• Budget for Indirect Use: Include indirect access in your IT financial planning. For example, if digital sales are projected to grow 50% next year, expect your SAP document license usage to grow similarly – budget for the cost of additional digital access licenses. It’s far easier to justify these costs upfront (as part of enabling new revenue channels) than to request emergency funds after an audit. Having a “licensing contingency” in the budget for unforeseen growth is also a wise move.
• Consult Experts if Needed: SAP licensing is a nuanced topic. Consider consulting independent SAP licensing experts or firms to validate your compliance position and strategies. They can often identify optimization opportunities or negotiation angles that save money. They can also help translate technical usage into license requirements. This is especially useful if your organization lacks dedicated license management staff. An upfront expert analysis can pay off by preventing multi-million dollar compliance issues.
• Foster Awareness: Finally, ensure this topic is understood not just within IT, but by procurement, finance, and business leadership. Indirect access often spans departments (e.g., a sales initiative might launch a new CRM-SAP integration). By raising awareness, other departments will alert IT whenever they plan something that might involve SAP data. A collaborative approach across the organization will help govern indirect access as a shared responsibility, not just an IT problem.

By following these recommendations, CIOs can turn what was once a licensing “gray area” into a well-managed aspect of their SAP environment. The goal is to enable your company’s digital initiatives – such as new customer portals, mobile apps, and IoT projects – without fear.

With the right licensing strategy and governance in place, you can confidently say that SAP indirect access is under control, allowing innovation to continue while avoiding compliance surprises.