Introduction – Why Indirect Use Is Now Central to SAP Audits
SAP “indirect access” refers to users or systems interacting with SAP software without logging in through the standard SAP GUI or portal. In other words, when a third-party application, interface, or device triggers SAP to process data, that counts as indirect usage.
This issue has moved front and center in SAP license audits today. Why? Because companies are more connected than ever – web portals, mobile apps, IoT sensors, robotic process automation (RPA), and integration platforms all weave into the SAP backend. Every one of those connections is a potential licensing time-bomb if not managed.
Historically, SAP’s licensing was based on named users: every person accessing SAP directly or indirectly needed a user license. But modern digital business models broke that paradigm.
Instead of thousands of employees punching data into SAP, an e-commerce site or an automated sensor might now generate transactions in SAP without any human ever logging in.
SAP responded by shifting towards a “Digital Access” model – essentially counting documents created in the system, rather than just named users. For an overview, read our overview guide, SAP Licensing Risks & Penalties: What’s at Stake in Non-Compliance.
This document-centric approach (introduced around 2018) tries to capture the business value generated by SAP through indirect use. For SAP, it’s a way to monetize the explosion of digital integrations. For customers, this means that indirect use is no longer an edge case; it often leads to the biggest surprise costs in an audit.
Many legacy system architectures weren’t built with these licensing nuances in mind. Companies integrated applications freely to streamline processes, not realizing that each API call or interface might incur an SAP charge.
Now, SAP’s audit teams are laser-focused on indirect usage because it’s both common and often overlooked by customers. If you’re a CIO or CTO, you need to treat technology integrations as part of your license compliance scope.
The technical architecture is now a primary risk surface, not just the contract language. The remainder of this post explores common scenarios that trigger indirect access fees, real-world case lessons, and strategies to mitigate these risks.
Landmark Case: Diageo Judgment & What It Teaches Us
One of the wake-up calls for SAP customers was the Diageo case in 2017. Diageo, a global liquor company, had connected its Salesforce CRM and a customer portal to its SAP systems.
The idea was that sales reps and customers could interact via Salesforce and a web portal (aptly named “Gen2” and “Connect”), placing orders and viewing data that ultimately went into SAP.
No one was directly logging into SAP – so Diageo assumed their existing SAP licenses covered everything. SAP disagreed, and the dispute ended up in UK High Court.
The court ruled in SAP’s favor, deciding that even though users only accessed SAP indirectly through Salesforce and the portal, those interactions still counted as SAP use requiring licenses. The price tag? Roughly £54 million (tens of millions of dollars) in license fees were deemed owed for unlicensed indirect access.
This landmark judgment shocked many SAP customers. It highlighted that contracts rarely had explicit terms for indirect access, and SAP was willing to enforce its view aggressively.
In Diageo’s case, the company had already paid for SAP Process Integration (PI) software (a middleware intended to facilitate interfaces). Still, the court rejected the argument that PI acted as a “gateway license” covering the end users.
Essentially, it didn’t matter if you used a technical middleman – SAP delivered the business benefit, so SAP wanted its share.
The Diageo case teaches a few key lessons: First, if third-party systems (like Salesforce) are creating SAP transactions or documents, SAP will likely insist that those require SAP-named-user licenses or equivalent document licenses.
Second, the absence of clear contract language on indirect use leaves customers at the mercy of SAP’s standard policies, which are very broad.
Finally, the financial stakes are enormous – tens of millions in this case – turning what many thought was a gray area into a very black-and-white (and costly) precedent. This case set the stage for SAP to pursue other companies: soon after Diageo, several other high-profile compliance actions popped up, proving it wasn’t an isolated incident.
Typical Indirect Access Trigger Scenarios – Interfaces, IoT, Middleware & More
Not sure where your SAP indirect access exposure might be? It helps to look at the technical scenarios that commonly trigger SAP’s attention.
Below are five typical scenarios, each described by what the trigger is, why SAP might charge for it, and how you can mitigate the risk:
| Scenario Trigger | Why It Rings SAP’s Bell (Licensing Risk) | Mitigation / Defense |
|---|---|---|
| Customer/Partner Portals & CRM Interfaces (e-commerce sites, self-service portals, Salesforce) | External users (customers or employees) use a non-SAP portal or CRM that in turn creates or changes data in SAP (e.g. placing orders, updating account info). Even if those users never log into SAP, SAP sees its ERP generating business documents (sales orders, etc.) on their behalf. From SAP’s perspective, that’s unlicensed use of SAP functionality. In a traditional model, each of those portal users would need a license. Under Digital Access, each document (order, invoice) created via the portal counts towards your license usage. | Isolate and limit direct SAP calls: Use a middleware or buffer to batch portal transactions into SAP rather than real-time one-by-one calls. This can reduce document count and make usage more auditable. Contractual clarity: If possible, negotiate contract clauses that allow specific external-facing processes (like an e-commerce site orders) without a full named-user charge for every customer – for example, by using SAP’s special licenses or the document model. Monitor usage: Track how many documents these portals actually create in SAP so you can anticipate costs. |
| Middleware / Integration Hubs (SAP PI/PO, MuleSoft, API gateways) | Companies often funnel external connections through middleware, hoping it shields them. In reality, if the middleware passes data into SAP that triggers transactions (like an order coming from a third-party logistics system via SAP PI), SAP considers it the same as a direct input. The middleware might use a single technical account (a form of “multiplexing”), but SAP’s policy is that it doesn’t matter – it will count the end usage. So a message broker sending 1000 transactions on behalf of various sources could be seen as 1000 indirect uses. | Decouple and minimize: Ensure the integration layer isn’t blindly forwarding every external interaction into SAP. Buffer data and send only what’s necessary. If 10 different systems ask SAP for info that a single cached query could handle, use that cache. Avoid hidden users: Don’t rely on one “generic” SAP user account to serve hundreds of external users without clarifying licensing – SAP audits will spot high-volume generic users. Restrict interface scope: Document what each middleware interface does and limit it to least-privilege access (e.g. if an interface only needs to create a delivery, don’t let it also create invoices). This containment can help if you need to argue the scope in an audit. |
| IoT Devices, Sensors & RPA Bots (machines creating SAP transactions) | Non-human operators can still create a big licensing footprint. For example, an IoT sensor on a production line might post inventory movements or trigger quality inspections in SAP automatically. Or an RPA software bot might input invoice data into SAP. From SAP’s view, each of those events (a goods movement, an inspection lot, an invoice posting) is a use of SAP. The fact that it’s a sensor or script, not a person, offers no exemption – SAP counts the documents created and the functional use of its software. High-frequency IoT updates can rack up thousands of document creations quickly. | Aggregate and throttle: Instead of every single sensor ping creating an SAP update, funnel them through an IoT platform or middleware that groups events. For instance, send one consolidated SAP update per hour instead of one per second if possible. This reduces document count dramatically. Filter events: Only push the critical events into SAP (e.g., threshold exceptions) and handle the rest in a separate database for analysis. Licensing strategy: Consider SAP’s specialized IoT connectors or inquire if a specialized license is available for certain high-volume machine data (SAP’s preference will still be Digital Access, but it doesn’t hurt to ask). Most importantly, know your volumes – if your factory’s sensors will generate 10,000 SAP transactions a day, you need to budget licensing for that or find a way to cut it down. |
| External Applications & BI Tools (third-party apps reading/writing via SAP APIs) | This scenario involves non-SAP applications – think of a cloud analytics tool, supply chain planning software, or a home-grown app – that pull data from SAP or push data into it through APIs or ODBC connections. If an external app merely extracts data from SAP for reporting, one might assume it’s harmless. However, SAP often argues that live data access (even read-only) by external users or systems is licensable, since those users are indirectly using SAP’s data in real time. And if the external app writes back (e.g., a planning system updating SAP with forecasts), that clearly creates or changes SAP records, which is counted as indirect use. | Read via replication, not live: A best practice is to avoid live direct queries to SAP from external tools. Instead, replicate the needed SAP data to a data warehouse or interface file, and let the third-party tool query that. If there’s no live connection to SAP, SAP can’t claim those users are “using” the SAP system. For write-backs, segregate and document: Limit external write access to specific controlled interfaces. For example, maybe only one designated API user ID can post forecast data into SAP, and you track how many documents that creates. Contract carve-outs: If analytics or read-only access is important, negotiate language in your contract that pure data retrieval (especially by internal users or certain systems) is not counted as indirect usage. Some SAP customers have successfully gotten clauses inserted that allow, for instance, “read-only use of SAP data for analytics by non-SAP applications shall not require a named user license.” You must get this in writing though – otherwise, SAP may later assert a violation. |
| Bulk Data Loads & Batch Jobs ( IDoc feeds, scheduled file imports) | Many SAP systems receive periodic batch inputs – maybe a nightly file of sales orders from an e-commerce platform, or a supplier sends a batch of invoices to load into SAP automatically. These behind-the-scenes jobs can create thousands of documents in one go. Because there’s no interactive user, companies sometimes overlook them in licensing considerations. But SAP counts those documents the same. Each order, invoice, or master data record created via a batch input is an instance of SAP being used indirectly. Over a year, a daily batch job creating 500 orders adds up to 182,500 SAP documents created – a significant license impact under the digital access model. | Use certified integration tools: If possible, use SAP-provided or certified batch interfaces (like SAP’s Business Integration tools or Data Services) which come with clear license terms. They won’t exempt you from indirect use costs, but at least you know what to count. Optimize the batch process: Combine records where feasible so you create fewer individual SAP documents. For instance, process one consolidated invoice for a vendor per day instead of 100 separate invoices, if business allows. Monitor volume: Treat batch interfaces as you would active users – keep an eye on how many documents they create. If a new project will start loading large files of transactions regularly, forecast the licensing impact first. And again, ensure your contract doesn’t inadvertently exclude batch processes from scrutiny – address it proactively by defining what’s allowed. |
Multiplexing is not a defense: Note that in several scenarios above, a common mistake is assuming you can “hide” indirect use by funneling many users or devices through one technical user login (a practice known as multiplexing). SAP’s audit stance is clear: multiplexing does NOT reduce liability.
They will seek to license the true number of users or the actual volume of documents, regardless of how many technical accounts are used. In short, you can’t outsmart the license rules with a technical workaround – you need a contractual or architectural solution instead.
Read about hidden costs, Under-Licensing vs Over-Licensing Risks: The Hidden Costs of Getting SAP Licensing Wrong.
How Digital Access (Document Model) Shifts the Exposure
SAP’s Digital Access model fundamentally changed how indirect usage is measured and billed. Under this model, rolled out in 2018 and now the go-forward approach SAP promotes, you no longer count “named users” for indirect scenarios. Instead, you count the digital documents created in SAP by any indirect access.
SAP identified nine core document types that cover most business transactions: for example, Sales Documents (sales orders, quotes), Invoice Documents (billing documents, supplier invoices), Purchase Documents (purchase orders), Material Documents (inventory or goods movements), Manufacturing Documents (production orders), Quality Management Documents (inspection lots), Service & Maintenance Documents (service orders, maintenance notifications), Financial Documents (journal entries), and Time Management Documents (timesheet entries).
If an external system triggers SAP to create any of these, it increments your document count.
This document-centric licensing has some advantages. It’s more transparent in that you can measure how many documents you actually create and pay for that volume, rather than requiring a license for every possible user who might touch SAP.
For organizations with huge numbers of occasional or indirect users (think of a million customers making orders via a website), paying by document could be far cheaper than trying to license each user.
SAP also provided tools like the Digital Access Evaluation Service (DAES) to help customers scan their systems and estimate document counts. This helps in forecasting: you can simulate how many documents your interfaces produce in a year and budget accordingly.
However, digital access shifts the risk lens towards transaction volume. High-volume automated scenarios can significantly increase your costs.
For example, a single IoT device might post thousands of small events as SAP material documents. Under named-user licensing, you might have ignored it (since no human user), but under document licensing, every one of those events counts.
So the new question is: how many documents are your integrations generating? A lot of companies were surprised by the results when they first measured this.
Mitigation in the document model comes down to two things: governance and negotiation. On the governance side, you should actively manage how and how often external systems create SAP documents. If you can consolidate 100 small transactions into 10 larger ones, that’s 90 documents saved.
If you can archive or purge redundant document creation (such as avoiding logging every single sensor heartbeat as a separate record), do it. Small design choices in integrations – such as caching results, batching updates, or filtering out unnecessary writes – can have a big impact.
One company, for instance, realized its external partner system was re-sending the same customer data every hour, creating duplicate update documents in SAP each time. Tweaking that to only send changes reduced the document count drastically.
On the negotiation side, SAP’s Digital Access Adoption Program (DAAP) has been an avenue to transition to this model with less pain. SAP has offered steep discounts (often 90% off list price) on the initial purchase of digital access licenses, and sometimes even amnesty for past indirect use if you sign up.
The program’s details evolve, but as of now, it’s still available. The takeaway is that if indirect use is a ticking bomb in your landscape, SAP is basically saying, “move to the document model and we’ll make it worth your while (and avoid the ugly audit fight).”
But you must estimate your document volumes carefully – even discounted, if you vastly underestimate usage, you could face unexpected overages later. The document model comes with tiered pricing: if you exceed your licensed document count, you have to buy more.
Always negotiate some buffer or flexible terms if you can (e.g., the ability to true-up at a fixed price, or a grace threshold).
In summary, Digital Access is a more modern solution to the indirect use puzzle, but it requires you to think in terms of process volumes.
The key risk shift is from “Do I have unlicensed users?” to “Am I generating more SAP transactions than I planned for?” Keep that question at the forefront as you design and expand your integrations.
Proactivity saves costs. Cost of Non-Compliance vs Compliance: Why Investing in SAP License Governance Pays Off.
Real-World Cases Beyond Diageo: The Stakes Are High
Diageo might have been the wake-up call, but it wasn’t long before other SAP customers found themselves in similar hot water. One notorious example was Anheuser-Busch InBev (the world’s largest brewer).
In 2017-2018, AB InBev disclosed that SAP had initiated an arbitration claim for roughly $600 million in license fees, alleging widespread unlicensed indirect access. The sheer size of that number sent shockwaves through CIO circles.
While the details weren’t all public, it was understood that AB InBev’s complex web of systems – spanning supply chain, perhaps brewery IoT systems, and sales apps – had introduced indirect uses of SAP software on a massive scale over the years.
SAP was effectively seeking back payment and compliance on a grand level. (For context, $600M could be more than some companies’ entire IT budget for a year.)
Beyond headline cases like AB InBev, many other enterprises have quietly faced indirect use disputes or panic.
Industries with heavy automation and integration have been especially at risk: manufacturing firms connecting shop-floor machines to SAP, consumer goods and retail companies linking customer apps and Point-of-Sale systems to central SAP ERP, and pharmaceutical or high-tech companies with sprawling interface landscapes.
In numerous SAP audits in recent years, the auditors zeroed in on interfaces that had existed for ages. For example, a global manufacturer found that an “innocent” interface between SAP and its warehouse management system – which was just moving inventory data nightly – actually led SAP to claim the warehouse system’s users should all have SAP licenses (or that each inventory movement should count under digital access).
The client had thought read-only data exchange was low risk, but because it was a live link pulling real-time stock levels for warehouse staff, SAP’s stance was that those staff were indirectly “using” SAP.
These real-world run-ins underline an important point: even read-only or low-touch integrations can trigger license claims if they are not clearly accounted for. SAP has consistently maintained that if SAP’s software is being used to retrieve live data or execute transactions on someone’s behalf, it’s within their rights to demand a license for it.
We’ve also seen scenarios where an executive dashboard (displaying SAP KPIs to managers) was considered indirect use for each manager viewing it, and cases where third-party sales apps writing orders to SAP led to multimillion-dollar compliance discussions.
The stakes, as illustrated by these cases, include massive financial exposure, project disruption (an audit claim can put integrations on hold or force rushed re-architecting), and, of course, strained vendor relationships.
Nobody wants to be the next Diageo or AB InBev headline. The good news is that awareness is much higher now, and SAP’s introduction of the digital document model gives a clearer framework to work within. But awareness alone isn’t enough – you need to actively defend and manage your position, as discussed next.
Audit Defense Strategies for Indirect Access Claims
Finding out you’re on SAP’s radar for indirect access compliance can be nerve-wracking. However, you’re not powerless. There are concrete steps and strategies to defend your organization and, ideally, resolve the issue on favorable terms.
The approach combines technical groundwork, data gathering, and savvy negotiation.
Below is a checklist of audit defense steps to consider:
Checklist: Preparing Your Indirect Access Defense
- Map all interfaces and data flows: Conduct an architectural inventory of every system that connects to SAP, including every interface, API, file import/export, and integration point. Document what each one does (read vs write, what data, which users or devices interact). This complete picture is your foundation. You can’t defend what you don’t know exists.
- Classify risk for each connection: For each interface, label it as read-only, write/transactional, or mixed. Identify whether it involves human end-users (e.g., employees, partners, customers using another application that communicates with SAP) or just system-to-system interactions. Those that create the nine document types or have many users behind them are at higher risk. Prioritize these in your analysis.
- Gather usage data and logs: SAP will often rely on its own tools (like log analysis and the Digital Access evaluation) to claim indirect usage. You should pull your own statistics. For key interfaces, gather logs showing how many transactions or documents they create, and since when. If an interface has been in place for 5 years but has only been actively used in the last 1 year, that’s crucial to know. Usage logs can help challenge SAP’s assumptions (for example, if SAP estimates you created 1 million documents via a B2B portal, but your logs show only 100k, you have evidence to dispute their figure).
- Don’t accept the first quote – negotiate: If SAP presents a compliance bill or a proposal to buy licenses, remember it’s a starting bid. You have levers to pull. One effective tactic is proposing a “cap and slide” settlement – for instance, agree to purchase a certain number of digital access documents now (covering current usage) with a capped price for any growth in the next year or two. Essentially, you cap the immediate cost and have a predefined cost if usage increases, instead of an open-ended liability. SAP, in many cases, prefers a cooperative solution (they’d rather sell you something than fight in court).
- Leverage the Digital Access Adoption Program (if beneficial): If you’re still on the old model, consider using SAP’s carrot. Under DAAP, you might negotiate a package where you trade some existing user licenses for digital document licenses. As noted, SAP often provides deep discounts and crucially waives past indirect use findings once you’re on the new model. This can turn a scary audit penalty into a palatable future license purchase. Just ensure the package truly covers your needs – negotiate for extra document capacity if you suspect growth, and get credit for licenses you give up.
- Carve-outs and clarifications in writing: As part of any settlement or resolution, push to include language that clarifies tricky scenarios. For example, if SAP has been auditing you for read-only interfaces, insist on a clause that states read-only data extraction (with no document creation) is not licensable. Or carve out specific integrations: e.g., “Interface X between SAP and __ system is acknowledged and permitted under the following conditions…”. Getting these in writing protects you in the next audit and avoids re-litigating the same issue.
- Use time to your advantage: An audit isn’t resolved overnight. You typically have time to analyze and respond. Use it to your benefit – don’t rush to buy without fully understanding your exposure. Also, if you’re nearing a contract renewal or big SAP purchase (like S/4HANA migration or RISE agreement), that can be a leverage point: SAP might soften its stance on indirect use claims if you are committing to a new investment. Conversely, if you’re not planning any purchases, be prepared for SAP to be a bit tougher (but even then, they usually will negotiate rather than risk you pushing back hard or lawyering up).
- Engage experts if needed, as indirect access is complex. Many firms bring in software licensing advisors or legal counsel experienced in SAP audits to help formulate a response. These experts know SAP’s playbook and where there’s flexibility. The cost of advice can be trivial compared to the potential compliance fees at stake.
The overarching strategy is to be proactive, demonstrate to SAP that you understand your environment, and negotiate a business solution rather than passively paying a “fine.”
By mapping your interfaces and gathering your own data, you transform the audit from a one-sided report into a fact-based dialogue. Companies that come to the table prepared often achieve much better outcomes, ranging from heavily discounted license orders to even getting certain claims dropped.
Contractual Protections & Proactive Measures
Dealing with indirect access in audits is one thing – but the ideal is to bake protections into your SAP contracts and architecture upfront so you’re prepared (or even avoid issues entirely).
Here are some proactive measures and contract clauses to consider for indirect use:
- Define indirect use in the contract: Don’t leave the term “indirect access” to SAP’s imagination. Clearly define what constitutes indirect use for your agreement. If possible, narrow it. For example, state that indirect use means creating the specific nine document types via external systems, and nothing else. The goal is to prevent SAP from broadening the definition later.
- Exclude read-only and static data scenarios: If you have use cases where external systems or users only view or pull SAP data, explicitly carve that out as non-chargeable. E.g. “Read-only access to SAP data for reporting or inquiry purposes by external applications shall not require additional licenses.” SAP might push back on fully exempting this, but even a compromise like “non-production systems or data extracts are exempt” can help.
- Include an interface catalog in the contract: One strategy is to list your known interfaces (or categories of interfaces) in an appendix to the contract, along with the agreed licensing treatment for each. For instance, “E-commerce web store -> SAP sales orders: covered under Digital Access licenses, max X documents/year” or “Warehouse management system -> SAP inventory updates: permitted under existing licenses as long as only Y type of document is created.” This level of specificity forces both parties to be clear and can prevent surprises.
- Set audit guardrails: If possible, negotiate terms for audits and true-ups related to indirect use. For example, you might add that any findings will first be discussed in good faith to allow the customer to remediate or purchase additional licenses at regular rates (not some punitive rate). Also consider time limits – e.g., “no compliance claim for indirect use will go back more than 2 years.” While SAP might resist strict limits, having any guardrail is better than none.
- Thresholds and buffers: If you adopt the digital document model, set a reasonable buffer above your expected document count to account for additional documents. For instance, if you anticipate 1 million documents, see if SAP will agree that up to 1.2 million is covered at no extra charge (to account for business growth). Alternatively, fix a price for additional documents if you go over, so you’re not at SAP’s mercy later. The contract could say “additional documents can be purchased in blocks of 100k at $X per block.” Clarity here avoids nasty cost surprises.
- Right to optimize or true-down: If you invest in cleaning up your interfaces or reducing indirect use, ensure the contract allows you to benefit. That might mean the ability to reduce some license counts if you significantly cut down document creation. Or at least the right to an annual review where you can re-negotiate if your actual usage diverges greatly from the forecast. You don’t want to be overpaying perpetually for volume you no longer have.
- Keep legacy entitlements alive (if they favor you): Some older SAP contracts had generic language or even special licenses (like a “SAP NetWeaver Foundation” license or a blanket API use clause). If you have anything like that which could be interpreted as allowing certain indirect usage, preserve it in new agreements. SAP’s newer contracts tend to standardize terms, but you can append your old concessions as riders. For example, if your 2010 contract said something like “External third-party software access via SAP PI is included,” carry that forward explicitly. It could save you in a dispute.
- Audit support and collaboration: You might not get it, but there’s no harm in asking for contractual recognition that you’ll manage indirect use jointly. For example, a clause that “Customer will regularly report on indirect usage and SAP will provide guidance to remain compliant, and any discrepancies will be addressed prospectively.” This at least sets a tone that if something is discovered, it’s solved looking forward, not as a gotcha for back-charges.
The theme of all these measures is preventive clarity. The more you and SAP agree on how integrations are handled license-wise, the less room there is for a costly argument down the line.
In parallel, you should also architect with compliance in mind: Build integrations in ways that minimize direct SAP touches, keep an audit trail for interface activity, and periodically review your system connections, especially when you add a new software tool to your landscape.
Being proactive on both technical and legal fronts is the best recipe to avoid indirect access trouble.
5 Indirect Access Risk Mitigations to Remember
Finally, as you plan and protect your SAP environment, keep these five key indirect access risk mitigations in mind:
- Map and document every interface to SAP – You can’t control what you haven’t identified. Keep an updated inventory of all systems, APIs, and integrations touching your SAP, including what they do.
- Distinguish read-only vs. transactional usage – Treat connections that only view data differently from those that write or trigger transactions. Push for carve-outs or special terms for read-only scenarios in your SAP agreements.
- Simulate and monitor document volumes – Before contract renewals or architecture changes, estimate how many SAP documents your integrations generate. Use SAP’s tools or your own logs to project usage under the digital access model, allowing you to budget and negotiate accordingly.
- Negotiate exclusions or thresholds upfront – Don’t wait for an audit. In your next SAP contract or renewal, bake in clauses that exclude certain low-risk uses (like static reporting) and set thresholds for high-volume processes so you know what’s covered.
- Leverage logs, monitoring, and evidence – Implement monitoring on interfaces (who’s calling SAP and how often). If an audit comes, you’ll have hard data to either validate or challenge SAP’s claims. Data is your ally for defense and in discussions with SAP – it keeps the conversation factual and solution-oriented.
By staying vigilant on these fronts, you can embrace the benefits of integrated and digital processes without stumbling into a licensing trap.
Indirect access risk is manageable with foresight, good architecture, and solid contract hygiene. In the end, understanding how SAP views your interfaces – and planning for it – turns a potential compliance minefield into just another aspect of savvy IT management. Happy integrating (responsibly)!
