Digital Access by User: Analysis in ECC and S/4HANA
Digital Access is not measured like a conventional named-user licence. The metric is based on defined document types created through indirect or digital access. Standard measurement therefore starts with document volumes, not with the people, interfaces or automations behind those volumes.
For ongoing contract governance, an aggregated number is often not sufficient. When document volumes change, the next question is which technical connection, bot or SAP user caused that usage. This attribution provides the basis for assessing usage in its business context, assigning responsibility and forecasting development through the next renewal.
SAP provides different standard reports for ECC and S/4HANA that can analyse Digital Access-relevant document volumes for selected users. FinOptory initially runs these reports manually as part of the Managed Service. The responsible FinOptory consultant therefore requires a dedicated user in every relevant source system. No additional interface or change to FinOptory reporting is required for the first analysis.
Why Digital Access needs an additional user perspective
With named-user licensing, attribution is built into the licence model: a user is assigned to a licence category. Digital Access follows a different logic. SAP considers the initial creation of defined document types through indirect or digital access. These include Sales Documents, Invoice Documents, Purchase Documents and Material Documents.
This document logic is decisive for contractual measurement. Internal governance needs an additional perspective. An organisation must understand which technical usage sits behind the counted volumes. A shared interface user may create documents for several processes. An RPA user may create a high number of similar transactions within a short period. A technical user may support more than one business unit.
User attribution does not automatically answer every commercial allocation question. It does, however, provide the technical starting point:
- Which user IDs create Digital Access-relevant documents?
- Which document types and volumes are assigned to those IDs?
- In which ECC and S/4HANA systems does the usage arise?
- Which interface, automation or organisational responsibility sits behind each ID?
This turns an aggregated measurement into a governable usage structure. That structure can support contract forecasting, integration reviews and renewal preparation.
Which SAP reports apply to ECC and S/4HANA
SAP distinguishes between the standard Digital Access measurement and supplementary reports for estimation and analysis.
For ECC: Report DAC_ECC_COUNT_DOCTYP_ITEM is provided through SAP Note 2992090. It is used to analyse Digital Access-relevant document types and items in an ECC environment.
For S/4HANA: The corresponding report is DAC_S4_COUNT_DOCTYP_ITEM. SAP Note 2999672 describes its delivery and technical prerequisites.
For standard measurement: RSUVM_DAC is SAP's central report for Digital Access measurement. SAP Note 2837612 describes related corrections and prerequisites.
In a mixed landscape, ECC and S/4HANA are handled separately. The relevant report is executed in the system whose documents are being analysed. A central system cannot replace local execution when documents and technical user context reside in the source systems.
Results can subsequently be consolidated across systems. System, client, period, user and document type should remain separate dimensions. This preserves the evidence of where each volume originated.
The process in five steps
1. Define systems and users
The first step is scope definition. Compile a list of all productive ECC and S/4HANA systems relevant to the processes under review. Record at least the SID, client, release and support package level for each system.
Then define the user IDs to be analysed. These normally include technical users, interface users, RPA users and shared integration accounts. Add the business process, technical owner and responsible business unit wherever possible.
2. Verify technical prerequisites
Before execution, confirm that the required SAP Notes and reports are available in each system. Note 2992090 applies to ECC and Note 2999672 to S/4HANA. The general prerequisites for Digital Access measurement and SAP Passport identification should also be reviewed. SAP documents the Passport context in Note 2738406.
Release and support package levels are part of this check. The presence of a report name alone does not confirm that all relevant corrections have been implemented. SAP Basis should therefore verify the Notes in each specific system and document the result.
3. Provide the FinOptory user
FinOptory performs the analysis as a Managed Service. A dedicated dialog user is therefore created for the responsible FinOptory consultant in every ECC or S/4HANA source system in scope. A central user in another SAP system is not sufficient for local report execution.
The user needs permission to sign in through SAP GUI, start the relevant report, read the required data and display and export the result or spool. If the report must run as a background job, the customer-defined job permissions are also required. SAP Note 1732566 can serve as a reference for the support permissions described by SAP. The minimum customer role is verified for the relevant release and completed selectively using SU53 or an authorisation trace. Change, development, transport and administration permissions are not required.
4. Execute reports with comparable parameters
The analysis period must be defined in advance. A completed period, such as the most recent contract year or the last twelve full months, provides a suitable baseline. Trend analysis requires the same period logic across all systems.
FinOptory runs DAC_ECC_COUNT_DOCTYP_ITEM in ECC and DAC_S4_COUNT_DOCTYP_ITEM in S/4HANA for the selected users. Selection parameters, run date and system context are documented. The result list or spool is exported in a format suitable for further analysis.
The first result is a technical attribution. It shows which volumes are visible under a particular user ID. It does not yet determine which business unit has commercial responsibility for the transaction. That link is established in the next step.
5. Connect technical and business ownership
Link each result to the corresponding integration or automation register. A technical user should be associated with at least one system, interface, process, owner and business unit.
Dedicated user IDs usually provide a clear connection. Shared IDs reduce precision. If three interfaces use the same technical user, the document volume can initially be attributed to that user but not automatically to an individual interface. Separating user IDs may therefore improve future governance.
The result is a traceable chain: document volume, SAP system, user ID, technical connection and business responsibility. This chain forms the basis for assessing usage according to its cause.
What you provide for the first analysis
Six information packages are sufficient for the manual starting point:
- System list: All relevant ECC and S/4HANA systems with SID, client, release and support package level.
- User list: Technical, interface and RPA users to be analysed, including owner and process context.
- Period: A consistent analysis period aligned with the contract year or renewal preparation.
- Report status: Confirmation that
DAC_ECC_COUNT_DOCTYP_ITEM,DAC_S4_COUNT_DOCTYP_ITEMandRSUVM_DACare available in the respective systems. - FinOptory access: A dedicated dialog user for the responsible FinOptory consultant in every source system, including SAP GUI access and report, read, job and spool permissions.
- Result exports: Report output with documented selection parameters and run date.
This information allows the first baseline to be created without an automated data connection. The manual run also reveals system boundaries, user quality and data gaps before a recurring process is established.
How to interpret the results
User-based count reports supplement Digital Access measurement. They do not replace the contractual assessment or SAP's formal measurement logic. Four limitations should be documented:
Estimation reports and standard measurement are different results. DAC_ECC_COUNT_DOCTYP_ITEM and DAC_S4_COUNT_DOCTYP_ITEM support analysis and estimation. RSUVM_DAC remains the relevant standard report for formal Digital Access measurement.
A technical user is not necessarily the commercial cause. One account may support several integrations or business units. Business attribution therefore requires a maintained integration register.
Shared users limit granularity. The more connections share one user ID, the less precise the attribution. The analysis then exposes a limitation in the current user architecture.
Systems must remain traceable separately. Early aggregation across ECC and S/4HANA can hide relevant differences. Consolidation should occur only after system, client and report parameters have been documented.
These limits do not reduce the value of the analysis. They define which conclusions are supported and where additional attribution is still required.
From a manual baseline to ongoing contract governance
The first report run answers a specific question: which Digital Access-relevant document volumes can be attributed to selected users in the organisation's ECC and S/4HANA systems?
Ongoing governance adds three rhythms: repeat the analysis with comparable parameters, maintain user and integration assignments, and reconcile the results with contract scope and renewal planning. This connection shows whether a volume development is temporary, project-related or structural.
FinOptory deliberately starts with the available SAP standard reports and executes them directly as part of the Managed Service. A later technical integration is possible, but it is not a prerequisite for the first analysis. The immediate objective is a documented and reproducible baseline from the source systems.
Further reading: The nine Digital Access document types, Building an integration register and Preparing a Digital Access audit.
If you want to place SAP contract and usage data into an ongoing governance structure, the FinOptory Contract Check provides a defined starting point.
Frequently asked questions
Which report applies to ECC?
ECC uses DAC_ECC_COUNT_DOCTYP_ITEM. SAP Note 2992090 describes delivery and prerequisites.
Which report applies to S/4HANA?
S/4HANA uses DAC_S4_COUNT_DOCTYP_ITEM. The corresponding SAP Note is 2999672.
Can the report be executed centrally from another SAP system?
The user-based analysis is executed in each source system. Multiple ECC and S/4HANA systems therefore require multiple runs, followed by consolidation of the results.
Does FinOptory need its own SAP user?
Yes. To deliver the Managed Service, the responsible FinOptory consultant needs a dedicated dialog user in every ECC or S/4HANA source system under review. The role is limited to report execution, read access, background jobs and display and export of results.
Is the result the formal Digital Access measurement?
No. The user-based count reports support analysis and estimation. Formal Digital Access measurement uses SAP's standard measurement with RSUVM_DAC.
About the author
Bernhard Mändle is Managing Consultant at FinOptory. He helps organisations govern SAP contracts after signature, align usage and cost, and direct SAP investment with a structured data basis. His experience covers SAP contract negotiation and governance across On-Premise, BTP and SAP Cloud ERP, Private Edition. He is a DSAG member and independent of SAP, resellers and system integrators. More at finoptory.ai and on LinkedIn.
Sources:
Next steps
If you want to attribute Digital Access volumes in your ECC and S/4HANA systems to users, we jointly define the systems, access paths and analysis periods required.
This article belongs to the topic hub Digital Access and Indirect Access in SAP. The technical Managed Service setup is documented in the onboarding guide.
Last updated: August 2026