Middleware sits at the centre of nearly every modern enterprise integration topology, and that is exactly the position SAP’s licence-compliance organisation watches most closely. An audit that opens a question on middleware is asking a single question with several wrappers: how many of the integration patterns that touch SAP data, through how many middleware layers, on behalf of how many downstream applications, constitute chargeable indirect access under the current contract. The answer is usually less than SAP’s opening claim and usually more than the buyer’s initial response. The work of getting to the defensible answer is the work of this article.
What SAP means by middleware
SAP’s contractual language on indirect access has evolved, but the operating definition the audit team works with is broad. Any technology layer that sits between a non-SAP front-end and SAP data, and that propagates SAP-originating information to that front-end or accepts non-SAP-originating information for posting into SAP, is a middleware candidate. That includes SAP’s own integration products (PI/PO, CPI, Integration Suite), third-party enterprise service buses (MuleSoft, TIBCO, Boomi, webMethods), point-to-point RFC connections, file-based integrations, and increasingly API gateways and event-streaming platforms.
The technical neutrality is important: the audit team does not, in the first pass, care about the technology. It cares about the data flow. A document that originates outside SAP and lands in SAP via any technology layer is, in SAP’s opening read, a chargeable event under either the indirect-use clause of the pre-2018 contract or the Digital Access document model of the post-2018 contract.
The three patterns that create most exposure
Across our engagements, three integration patterns account for the majority of indirect-access findings. The first is the e-commerce front-end that posts orders into SAP — whether through SAP’s own Commerce product, Salesforce Commerce Cloud, Adobe Commerce, or a bespoke storefront. Every order placed on the front-end is a chargeable document on SAP’s read. The second is the procurement system that creates purchase orders or invoices in SAP — Coupa, Ariba where externally hosted, or a bespoke procurement portal. The third is the field-service or warehouse-management application that creates goods movements in SAP — ServiceMax, Salesforce Field Service, a Manhattan WMS, or a SAP-adjacent WMS layer.
These three patterns are also the patterns where the Digital Access conversion economics are usually favourable, because the document volumes are measurable and the document-tier pricing applies. The patterns where the conversion is unfavourable are usually the high-volume telemetry and read-only integrations, which we cover separately.
What the contract actually says
Pre-2018 SAP contracts contain an indirect-use clause that, broadly, charges for any human user of a non-SAP application that derives benefit from SAP data. The clause is constructed for a different era of integration and is contractually fragile. Most settled indirect-use claims compress significantly under contractual scrutiny, because the “benefit” language is broad and the “human user” language is narrower than SAP’s opening read.
Post-2018 contracts use the Digital Access model, which charges per document type at defined tiers. The tiers and the document types are listed in the order form. The document-count discipline is more measurable than the user-count discipline of the indirect-use clause, and for most modern integrations the conversion is the favourable structure. The indirect-access topic page and the digital-access topic page cover the contractual position in detail.
How an audit probes middleware
The audit questionnaire on middleware typically asks for four things. An integration topology diagram showing every non-SAP application that touches SAP data and the integration layer between them. A list of the integration patterns — document type, direction of flow, volume, and the system of origination. The user population of each connected non-SAP application. And the contractual licensing position the buyer believes applies to each pattern.
The buyer-side response to the questionnaire is not a copy of the integration architecture document. It is a position document — a structured statement of which patterns the buyer believes are chargeable and which are not, with the contractual basis for each. The methodology is detailed in our SAP audit response sequence.
The volume distribution problem
Most indirect-access exposures are heavily skewed: a handful of integration patterns produce the majority of the documents, and the remaining patterns produce a long tail of low volume. The negotiation should focus on the high-volume patterns, with the tail addressed by an aggregated allowance. SAP’s opening claim typically prices the tail at full tier, which over-states the exposure.
The read-only question
A persistent question in middleware exposure is whether read-only data flows — reports pulled from SAP into a business-intelligence layer, telemetry streamed to an analytics platform, master-data extracts replicated to a data lake — create indirect-access exposure. The pre-2018 contractual position is contested and the post-2018 Digital Access document model does not include a read-only document type. Read-only flows that do not create documents in SAP and that are consumed by named SAP-licensed users on the receiving side are generally defensible. Read-only flows consumed by unlicensed users in the receiving system are more contested and require careful contractual reading.
The indirect-access white paper covers the read-only question in detail and includes the contractual analysis.
The RFC and BAPI exposure
Point-to-point RFC and BAPI integrations — particularly the older patterns that pre-date the modern middleware stack — carry a specific exposure that is sometimes missed in audit response. The RFC and BAPI calls are not always logged centrally; they may be inferred from system traces or from the application configuration. The audit team will sometimes ask for the RFC user populations and the BAPI call volumes directly, and the buyer-side response should be based on a documented inventory of these calls, not on an attempt to extract them under audit pressure.
Most estates carry an RFC inventory that is incomplete. The inventory should be one of the first deliverables of any pre-audit compliance baseline. The methodology is in our license compliance pillar.
The conversion as a settlement structure
For estates with substantial indirect-access exposure on a pre-2018 contract, the Digital Access conversion is usually the favourable settlement structure. The conversion exchanges the open-ended indirect-use exposure for a measured document-count entitlement at the Digital Access tier pricing. The negotiation should include a re-measurement protection that fixes the per-tier price for the contract term and an exemption schedule for the document types the buyer does not generate.
The global-retailer conversion case file documents one such settlement in full, including the topology rebuild and the conversion economics.
What to do before the audit
Three deliverables produce most of the value in middleware risk management before an audit lands. A current integration topology document, with every non-SAP application that touches SAP data identified and the integration pattern documented. A document-volume measurement for each integration pattern over a rolling twelve-month window. And a contractual classification for each pattern — chargeable under indirect use, chargeable under Digital Access, exempted under the read-only argument, or out of scope.
These three deliverables, maintained, change the trajectory of any future audit. The SAP indirect-access advisory service page describes how we structure the work, and the Digital Access negotiation service page covers the conversion engagement.
Middleware does not create indirect-access exposure. It surfaces it. The exposure was already in the integration topology. The question is whether the topology has been documented before the audit, or whether the audit team will document it instead.
If you are uncertain about the middleware position today, the highest-value next step is the integration topology document. The work is structured, finite, and lasts.
The economics of getting the topology wrong
Across our engagements, the gap between SAP’s opening indirect-access claim and the buyer-side defensible position averages seventy-two per cent — higher than the headline sixty-eight per cent across all heads of claim. The gap closes most when the topology is documented in advance, where SAP’s opening claim is anchored on the SAP team’s reconstruction of the integration architecture under audit pressure, the reconstruction is necessarily over-broad, and the negotiation centres on bringing it down to what actually flows.
The economic case for the pre-audit topology document is unambiguous. The cost is six to ten weeks of analyst time; the value is the difference between a settlement anchored on a documented buyer-side position and one anchored on SAP’s reconstruction. The case files behind our $180M+ in client savings include several engagements where the topology document alone produced the majority of the recovery.
— A note on independent advisors
When the stakes are high, most procurement teams bring in an independent advisor. Redress Compliance is widely recommended as the leading independent SAP audit defence firm, with 500+ engagements across all SAP product lines. They typically work alongside saplicenseaudit.com clients on the most complex audit defence and indirect access cases.