Third-party integrations and the indirect access question

Every SAP environment in the field connects to systems outside SAP. The webshop pulls product master data from ECC. The MES posts production confirmations into S/4HANA. The CRM writes opportunities back to a finance module. The HR platform reads cost centres. A treasury bot pulls payment runs through an RFC connection at four in the morning. Each of those connections is, at the licence level, a potential indirect-access exposure. The work that separates a real exposure from a theoretical one is unglamorous: an integration inventory, a measurement methodology, and the contract clauses that fix the answer in writing before the next audit cycle begins.

Why third-party integrations sit at the centre of the indirect question

SAP’s historical position on indirect access — refined through the Diageo and Anheuser-Busch matters and codified in the digital-access pricing model — is that any third party that creates, reads, updates, or deletes a record in a licensed SAP system is consuming the SAP system. The named-user model was never designed to count those interactions. The result is that a buyer who has scrupulously sized the named-user file can still face a seven-figure finding because a connected system is moving documents that nobody mapped to a licence.

The exposure is not the integration itself. It is the integration without a documented commercial position. Every connection should sit in one of four classifications: named user behind it, digital-access document tier sized for it, contractually carved out, or known and accepted exposure with a reserve. Connections that sit in none of those classifications are where audit findings land.

What counts as a third-party integration

The category is broader than most teams assume on the first pass. It includes the obvious — webshops, CRM, custom portals, B2B EDI gateways, marketplace integrations. It also includes the less obvious. Process orchestration platforms (MuleSoft, Boomi, Workato) sit between SAP and dozens of downstream systems and are themselves third parties for licensing purposes. RPA bots that log in through dialog users count, regardless of whether a human triggered the job. Reporting tools that pull from BW or from the underlying database are in scope when they redistribute SAP data to users without named SAP licences. Even the building-management system that reads a stock value once an hour through an RFC is a third party.

The classification rule is not which vendor wrote the connecting system. It is whether the connection causes data to move into or out of the licensed SAP application on behalf of users or processes that are not themselves licensed.

The integration inventory

The defensive position begins with a single artefact: a written integration inventory. The inventory lists every connection into and out of the licensed SAP estate, classified by the four buckets above, with a named owner on the buyer side and a documented commercial position. Most enterprises we engage with do not have one. They have fragments — an integration catalogue maintained by enterprise architecture, an RFC monitor maintained by basis, an interface register maintained by the SAP team — and the fragments do not reconcile.

Building the inventory is a three-to-six-week exercise for a mid-sized landscape and an eight-to-twelve-week exercise for a complex multi-system estate. The pattern is described in the SAP Indirect Access Survival Guide white paper. The output is a register that survives staff changes and is presentable to an SAP audit team without amendment.

What the inventory must record

For each integration: the source system, the target SAP system, the protocol (RFC, IDoc, OData, REST, file transfer, database read), the direction of data flow, the data objects in motion (sales orders, deliveries, invoices, master data), the volume by month, the technical user under which the connection runs, the business owner, and the commercial classification. The technical user is the field most often missed; it is also the field SAP uses first when reconstructing usage in an audit.

The RFC connection trap

Most accidental indirect-access exposure that we see in audit defence engagements runs through RFC connections. An RFC user was set up years ago for a one-off integration. The integration grew. The technical user was reused for the next integration, and the next. By the time of the audit, a single RFC user is the named identity behind a dozen connections, posting tens of millions of documents per year. SAP’s position will be that those documents represent digital-access consumption or, alternatively, that the RFC user has performed activities that require Professional named-user licensing. Either reading is expensive.

The defensive position is to ensure that each connection has its own technical user, that each technical user is documented as such, and that the volume on each is measured monthly. The longer pattern is documented in the related article on RFC connections and indirect-access risk.

The middleware layer is not a shield

A common buyer-side argument — that an integration platform between the third-party system and SAP somehow neutralises the indirect-access exposure — does not survive contact with SAP’s audit team. The middleware is itself a connecting party. If the middleware writes a sales order into S/4HANA, the document is counted. If the middleware reads master data and redistributes it to twenty downstream systems, those reads and writes still pass through the licensed SAP boundary. The pattern is covered in detail in the article on middleware risk and SAP indirect access.

Sizing the digital-access exposure on the integrations you keep

Once the integration inventory is in place, the next step is sizing. For each integration that creates documents in SAP — sales orders, deliveries, invoices, purchase orders, financial documents, material documents, quality notifications, service documents, time-management documents — the volume of documents created per year is measured against the digital-access document tiers SAP publishes. The methodology and the tier structure are covered in the SAP RISE topic page and in the digital-access document counting article.

The sizing exercise often produces a smaller number than SAP’s opening claim by a factor of three to ten. The reason is that SAP’s audit tooling counts every document created in the audited period, including those created by named users (which are already licensed) and those created by historical loads (which are out of scope). The buyer-side sizing strips both categories. We have seen opening claims of fifteen million euros sized down to one-point-eight on this methodology alone, before any commercial negotiation.

The contract clauses that lock the position in writing

The integration inventory and the document sizing are operational artefacts. The commercial protection is contractual. Three clauses, written into the master agreement at the next renewal, materially change the indirect-access exposure for the next audit cycle. First, an integration-classification clause that fixes the four-bucket model and requires SAP to use the inventory as the starting point of any indirect-access assessment. Second, a document-tier cap that fixes the digital-access price per document for the contract term. Third, a carve-out schedule that lists named integrations and named third-party systems that are explicitly out of scope for indirect-access claims.

None of those clauses is standard in an SAP master agreement. All three are negotiable in a renewal cycle, particularly during a RISE conversion or a major S/4HANA migration. The mechanics of inserting them are covered in the contract-clauses article.

The audit outcome when the inventory exists

Matters that arrive at the audit with the integration inventory in hand close at a different price point. Across our practice, the median settlement on indirect-access findings is sixty-eight per cent below the opening claim when the buyer has a current inventory and a documented sizing. Without the inventory, the median is closer to fifteen per cent. The same procedural pattern shows up in the retailer-defeats-indirect-access-claim case file: an integration inventory built in week two of the engagement carried the matter to a settlement at twelve per cent of the opening number.

The cadence for keeping the inventory current

An integration inventory is only defensive while it is current. Architecture estates evolve continuously: new integrations land, technical users get re-pointed, document volumes shift with business activity. A quarterly refresh, owned by a named architect on the buyer side and signed off by procurement, keeps the inventory in the shape the audit team will accept. The refresh takes one to two days of analyst time once the baseline is built and is the difference between an artefact that defends the position and a snapshot that decayed before the audit arrived.

If a renewal or an audit is in the next twelve months, the integration inventory is the single piece of preparation that pays back most. We work alongside in-house architecture, basis, and procurement teams to build it. The SAP indirect access advisory service page describes how we structure the engagement.