Batch jobs, scheduled ABAP programs, IDoc inbounds, and middleware-driven mass postings are the quietest category of indirect-use exposure and the one most often under-counted in the opening days of an audit. The transactions they post are visible in SAP. The originating system, the user attribution, and the contractual basis on which they are licensed are usually less visible. SAP’s audit team works through the visibility gap quickly. The buyer’s response is to close it first, before the opening claim is filed, and to read the resulting picture against the master agreement. This article describes how that work runs.
What counts as a batch posting
For licensing purposes, a batch posting is any document creation, change, or deletion in SAP that is executed under a technical user, a service account, or a non-interactive session. The pattern covers nightly interface jobs that load orders from a customer portal, hourly IDoc inbounds that synchronise master data, scheduled ABAP programs that run period-end postings, mass-update transactions executed from a middleware layer, and queue-driven posting that drains from a message broker. The common thread is that no human is interactively in the SAP session when the posting occurs.
SAP’s reading of these postings, under the legacy indirect-use clause, is that each posting represents indirect use by whoever caused the data to arrive at SAP — usually a customer, a dealer, or an employee at a non-SAP application. Under the Digital Access model the reading is more direct: each posting that originates outside SAP is a chargeable document at the contracted tier. Either reading turns the volume of batch postings into a licensing event.
How SAP measures the volume
SAP’s system measurement tools, configured to count documents, will return the gross document count by type from the relevant transaction tables. Without the originating-system attribution, the count is the gross volume. With the attribution — which the buyer can produce but SAP’s standard measurement cannot — the count separates into chargeable and non-chargeable. The attribution work is described in our document counting article and is the single largest determinant of the final settlement.
The attribution requires three data sources. The technical user ID under which the posting executed, the source-system field where populated, and the integration log from the middleware layer. The three together permit each posting to be attributed to either a named SAP user (not chargeable) or a non-SAP application (chargeable under Digital Access). The proportions vary widely across estates; the variance is the work.
The RFC connections behind the batches
Most batch interfaces post into SAP via an RFC destination configured to a technical user. The destination is registered, the user has a defined authorisation profile, and every posting that flows through the destination is attributable to it. The discipline that an SAP basis team should maintain is a register of every RFC destination, its purpose, its originating system, and the document types it is permitted to post. Without the register, the originating-system attribution at audit time is a forensic exercise. With it, the attribution is a lookup. The RFC connections explainer covers the register methodology in detail.
Service accounts and identity separation
A service account that posts batch transactions to SAP should never share an identity with a human user. The discipline holds two values. It clarifies the originating-system attribution at audit time. And it prevents a human session from being mis-classified as an interface session or vice versa. The audit-time cost of mixed identities is non-trivial; the operational cost of separating them is small. The separation should be enforced from day one of any new interface and remediated where it has been allowed to drift.
The contractual footing for batch postings
The contractual basis under which batch postings are licensed sits in one of three regimes. The legacy indirect-use clause, which in older agreements applies broadly and is the source of most large opening claims. The Digital Access model, which prices the document count at a contracted tier and is, for high-volume estates, usually the favourable structure. And the negotiated carve-out, which in some master agreements excludes specific batch flows from the scope of paid licensing. The reading of which regime applies to which batch flow is the analytical step that converts the gross document count into a defensible licensed posture.
The conversion economics are detailed in the Indirect Access Survival Guide white paper. The negotiation is run as a defined engagement; the indirect access advisory service page describes the process. The SAP ECC topic page provides the broader contractual context for ECC-vintage agreements.
How a batch-driven opening claim is broken down
A typical opening claim against batch-posting volume reaches the buyer with a single gross document count and a per-document price at the highest applicable tier. The breakdown the buyer prepares replaces that with five distinct lines. The documents posted under technical users attributable to named SAP human sessions. The documents posted under technical users attributable to non-SAP applications and falling inside an existing Digital Access entitlement. The documents posted under technical users attributable to non-SAP applications and falling outside any current Digital Access entitlement — the chargeable volume. The documents in a static-data category that are exempt under Digital Access. And the unattributed residual, which is the negotiation buffer.
Across the engagements we have run, the third line — the actual chargeable volume — is typically twenty to forty per cent of the gross count in SAP’s opening claim. The settlement gap is the difference between the gross and the chargeable. The work that closes it is structural, finite, and documentary.
The operational implications
For SAP basis and integration teams, the implications of the Digital Access reading on batch postings are not abstract. The originating-system attribution at the moment of posting determines the licensing cost of the posting; the attribution is set by the technical user, the RFC destination, and the source-system field. Each is configured by basis or integration staff and rarely reviewed for licensing impact. The review should run quarterly. The deliverable is a register that maps every batch flow to its originating system, its document type, and its licensed posture.
The middleware layer matters as much as the SAP layer. A middleware platform that strips the originating-system identifier and re-posts under a generic technical user produces an unattributed posting at SAP. The cost is the difference between the tiered rate and the closest priced category. The remediation is straightforward: configure the middleware to preserve the originating identifier and post under a destination-specific technical user. The cost of remediation is small. The audit-time saving is consequential.
Batch postings are the most measurable and the most under-managed category of indirect-use exposure. The volume is in the system. The attribution is the work.
Where to start
If the batch-posting register does not exist today, the single most useful project of the next quarter is to build one. The methodology is in the middleware risk article and the logistics-firm conversion case file. The work is finite, the deliverable lasts, and the settlement value is high. The first conversation is at no cost and under privilege.
The middleware checkpoint
The middleware layer is the leverage point at which most batch-posting exposure is created, and it is also the leverage point at which most of it can be remediated. The standard remediation pattern runs in four steps. Audit the middleware platform for the originating-system identifier on every flow that posts to SAP. Configure each flow to preserve that identifier through to the SAP-side technical user. Map each technical user to a destination-specific RFC entry in the SAP RFC register. And include the resulting map in the quarterly compliance review. The pattern converts the batch-posting exposure from a moving forensic target into a documented, attributable, defensible measurement that anchors every subsequent SAP conversation.
The pattern is described in the RFC connections article and applied in the logistics-firm case file. The work is finite, the deliverable is durable, and the audit-time saving is, across our engagements, the single largest line in the closed settlement.
— 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.