Building the Digital Access baseline

A defensible Digital Access baseline is the most consequential single artefact in the audit-defence portfolio of any SAP estate that integrates non-SAP applications. The baseline sets the document count, the originating-system attribution, the tier placement, and the exemption schedule that bound every subsequent audit conversation. Built before the audit lands, it shifts the conversation onto buyer-side documentary terms. Built under audit duress, it is a forensic exercise against a clock. This article walks through the methodology, the data sources, the analyst-day budget, and the deliverable structure of a baseline that is fit for that purpose.

Why the baseline exists

The Digital Access model charges per document at a contracted tier. Every conversation about Digital Access pricing — the conversion from indirect use, the renewal of an existing entitlement, the addition of new integration flows, the response to an audit measurement — turns on the document count. The count, when SAP produces it, is the gross volume from the relevant transaction tables, with no originating-system attribution. The buyer’s count, when it exists, separates the documents that originated from named SAP users (not chargeable) from those that originated from non-SAP applications (chargeable). The separation is the baseline.

Across the estates we have measured, the gross count and the chargeable count differ by between thirty and seventy per cent. The settlement value of every conversion, every renewal, and every audit response sits inside that gap. The baseline is the artefact that captures it.

The data sources

The baseline draws on four data sources, each from a different layer of the estate. The first is the transaction-table history for each Digital Access document type — VBAK for sales documents, EKKO for purchasing documents, MKPF for material documents, and the corresponding tables for the other six types. The history provides the gross volume. The second is the change-document log (CDHDR and CDPOS), which provides the timestamps and the user identifier on each posting. The third is the middleware session log, which provides the originating-system identifier for each interface flow. The fourth is the user table (USR02 and SU01), which separates technical users from named human users and provides the role and licensing attributes of each.

The four sources are joined on the user identifier and the timestamp. The join is straightforward in concept and exacting in execution — in any reasonable estate, the data volume is large, the keys are not always clean, and the originating-system attribution requires a series of inferences where the source-system field is unpopulated. The methodology that handles those inferences consistently is the discipline that distinguishes a defensible baseline from a number on a spreadsheet.

The measurement window

The baseline is measured on a rolling twelve-month window. Shorter windows do not absorb seasonal variation; longer windows accumulate stale data that is hard to attribute. The window is reset quarterly and the prior window archived, so that the year-over-year comparison is always available. The discipline matters at audit time because SAP’s measurement window is rarely the buyer’s preferred window, and the ability to produce a count for any twelve-month period inside the last three years removes the most common opening lever.

The attribution methodology

Each posting in the baseline is attributed to one of four categories. A named-user posting, where the change-document log identifies a human SAP user who was interactively in the session at the moment of posting. An interface posting with clean attribution, where the originating-system identifier in the middleware log maps to a named external application. An interface posting with derived attribution, where the technical user is mapped to a known RFC destination and the destination is in the register. And an unattributed posting, where no source-system identifier is available and the technical user is not in the register. The four-category split is the analytical core of the baseline.

The first two categories are largely automated against the data sources. The third requires the RFC-destination register, which is rarely complete on the first pass and which should be maintained as a quarterly deliverable. The fourth is the residual, which should be small in a mature estate and is typically negotiated as an aggregated allowance at the next contract event.

The static-data exemption

The Digital Access order form carries a static-data exemption: replication of master data that does not change the operational state of SAP is not a document for licensing purposes. The exemption is applied at the attribution stage, against the document types that admit it — typically material documents and certain time-management documents. The exemption is sometimes contested at the margin and the buyer-side position should be written into the baseline methodology and held consistently. The exemptions explainer covers the standard and contested cases.

The deliverable

The baseline is delivered as a single document with four exhibits. The methodology note — data sources, joins, attribution rules, exemption treatment, and version history. The aggregate count — gross volume, chargeable volume, and the split by document type and originating system. The detail exhibits — the breakdown by RFC destination, by integration flow, and by month. And the variance commentary — the year-over-year change in volume by category, the unattributed residual, and the projected volume at the next renewal cycle. The document is, in mature form, fifteen to twenty pages. It is the artefact that goes to SAP at the moment of any Digital Access conversation.

The deliverable is also the input to the tier negotiation. The Digital Access Pricing Decoded white paper documents the tier structure and the per-document price benchmarks across the engagements we have negotiated.

The analyst-day budget

A first-pass baseline for a single-instance ECC or S/4 estate, with a moderate number of integration flows, runs to fifteen to twenty-five analyst-days. The work splits roughly into seven days on data extraction and validation, eight days on attribution and the RFC register, four days on exemption application and variance commentary, and three days on document preparation. Multi-instance estates and estates with non-trivial middleware topologies run higher. The discipline of repeating the work each quarter, against the same methodology, drops the run-rate cost into the range of three to six days per quarter after the first build.

How the baseline changes the audit response

An audit conducted against a current, validated, well-documented baseline follows a different trajectory from the typical pattern. The opening claim is read against the baseline inside ten business days, the attribution gaps are identified, and the position paper goes back to SAP inside six weeks rather than ten. The settlement closes at the chargeable volume in the baseline rather than the gross volume in the opening claim. Across our engagements where the baseline existed before the notification, the average reduction is higher than the headline sixty-eight per cent. The baseline does not change SAP’s opening number. It changes the speed and the documentary basis of the buyer’s response. The Digital Access negotiation service page describes how we run that engagement.

Where the baseline sits in the broader programme

The Digital Access baseline is one of three artefacts in the licensing data room of a mature SAP estate. The named-user inventory is the second; the indirect-use register is the third. Together they bound every conversation with SAP about licensed posture. The license position statement article and the logistics-firm case file describe how the three artefacts work together in the field.

The refresh discipline

A baseline measured once is a snapshot. A baseline maintained quarterly is an instrument. The refresh discipline preserves the methodological consistency of the measurement, captures the year-over-year variance, and detects the structural changes — new integration flows, decommissioned applications, expanded portals — that shift the chargeable volume between measurement points. The quarterly cycle is run by a single named owner, against the documented methodology and a versioned changelog, with the prior cycle archived and the variance commentary appended. The discipline is the difference between a baseline that survives the next audit conversation and one that is rebuilt from scratch under time pressure.

The refresh budget, after the first build, is three to six analyst-days per quarter. The cumulative output is a trailing four-quarter baseline that supports every Digital Access conversation — conversion, renewal, expansion, audit response — on the buyer’s documentary terms. The audit data room article places the baseline in the broader compliance portfolio.