IoT data ingestion and SAP indirect access

The IoT integration question is one of the fastest-growing categories of SAP indirect access exposure. Five years ago an IoT-to-SAP data pipeline was an unusual architecture, found mostly in industrial-IoT pilots and asset-heavy verticals. Today a typical large manufacturer or utility runs four to seven IoT data streams into SAP — meter reads, asset telemetry, shop-floor signals, fleet telemetry, supply-chain track-and-trace events, and condition-monitoring data. Each stream produces machine-generated events that ultimately create or update SAP records. Under the current digital access pricing model, each of those events is a potential billable document, and the cumulative exposure can reach seven figures per year of unrecognised license consumption.

What SAP counts in an IoT pipeline

SAP's digital access pricing model is built around nine document types: sales documents, invoices, purchase documents, service documents, manufacturing documents, quality documents, time-management documents, material documents, and financial documents. An IoT pipeline can produce any of these depending on what the events trigger downstream. A meter-read stream that creates billing line items produces sales documents. A condition-monitoring stream that triggers a maintenance work order produces service documents. A shop-floor stream that creates production confirmations produces manufacturing documents. The counting rules are documented in our document-counting article.

The exposure depends entirely on what the IoT pipeline writes into SAP, not what the IoT pipeline reads from SAP. Read-only telemetry pipelines that ingest data into SAP-adjacent systems without touching SAP records carry no indirect-access exposure. Pipelines that create new SAP documents from machine-generated events carry the full exposure. The architecture review is the substantive work.

The three integration patterns

IoT-to-SAP integrations fall into three architectural patterns. Each pattern has a different exposure profile.

Direct write

The IoT platform writes directly into SAP — typically through IDoc, RFC, OData, or a more recent event-driven API. Each machine event becomes one or more SAP documents. This is the highest-exposure pattern and the most common in industrial deployments. Across the matters we work, direct-write pipelines produce 60 to 80 per cent of the total IoT-driven digital-access exposure.

Aggregated batch

The IoT platform aggregates machine events into batches and writes the aggregated result into SAP on a defined cadence. A meter-read pipeline might write one billing document per customer per month rather than one document per meter read. The exposure is lower because the batch aggregation reduces the document count, but the line-item count inside each batched document still matters — see the document-multiplication traps article.

Read-through with downstream creation

The IoT platform writes into a middleware layer (typically SAP BTP, SAP MII, or a non-SAP integration platform), and a downstream process — often a SAP workflow or a human operator — creates the SAP document. The exposure depends on whether the downstream creation is triggered by the IoT event (counted) or by an independent human action (typically not counted). The distinction is fact-specific and is the most heavily contested category in IoT-related audit findings.

How SAP identifies IoT pipelines in an audit

SAP's audit team has three primary inputs for identifying IoT pipelines. The integration-topology questionnaire that the buyer is asked to complete during the audit. The SAP-side connection logs — RFC, IDoc, OData traffic — which show inbound traffic from named external systems. And the third-party integration discussion that takes place during the on-site audit interviews. Across our engagements, the integration-topology questionnaire is the primary source — and the buyer has substantial control over how that questionnaire is completed. The pattern is described in the audit document request article and in the indirect access audit defence white paper.

The measurement methodology

The measurement of IoT-driven document creation runs in three phases. Architecture mapping documents every IoT pipeline that touches SAP — source system, integration pattern, target SAP module, write cadence. Event sampling counts the events flowing through each pipeline over a defined window, typically thirty days. Document attribution maps each event to the SAP document type it produces or contributes to. The output is a defensible volume estimate that the buyer can present in the position paper. The methodology is the same as the broader digital access measurement covered on the digital access negotiation service page.

The exemption arguments

Several common IoT integration patterns qualify for documented digital-access exemptions. Static-master-data updates that do not create new documents are typically exempt. Read-only telemetry that does not write to SAP is exempt. Sensor-data ingestion into SAP BTP that does not propagate to the SAP digital core is typically exempt. Indirect-static-read scenarios — where the IoT platform reads SAP data for its own processing without writing back — are exempt under most readings of the digital access framework. The exemption arguments are covered in the digital access exemptions article.

The arguments that do not work are the ones based on technology choice. Buyers sometimes argue that an event-driven pipeline using Kafka or a similar messaging layer is "not really an integration" because it is asynchronous. SAP does not accept that argument, and the audit team has clear precedents to reject it. The exemption argument has to be based on what gets written into SAP, not how it gets written.

The negotiation strategy

In a settlement, IoT-driven exposure is typically negotiated as a defined volume per year, capped, with an exemption schedule attached. The buyer's negotiating position is a measured volume with the exemption-eligible streams carved out. SAP's opening position is the unmitigated volume from the connection logs. The settlement lands in the middle, with the cap typically set at 110 to 130 per cent of the measured volume to absorb growth. The pattern is described in the indirect access settlement examples article.

The contractual cleanup

After the settlement, the contractual cleanup runs across three documents. The digital access exemption schedule defines which IoT pipelines are exempt and on what basis. The volume cap defines the per-year document allowance, with an annual true-up procedure. The integration-change protocol defines what notification SAP receives when a new IoT pipeline is added to the landscape, and what the financial consequences are if the new pipeline pushes the buyer over the cap. Without all three documents in place, the settlement is rebuilt at the next audit. The drafting is covered in the audit clauses article and on the S/4HANA topic page because S/4HANA migrations frequently trigger a renegotiation of these schedules.

If you operate IoT-to-SAP pipelines and have not measured the document-creation profile, the place to start is the architecture map. A four to six week engagement typically produces a defensible volume estimate, an exemption schedule draft, and a settlement-negotiation strategy. The work is part of the indirect access advisory service and is most cost-effective ahead of an audit cycle, not in response to one.