Back to Blog
Digital Access

SAP Digital Access Audit Checklist: 10 Steps to Confident Audit Preparation

Digital Access Audit Checklist SAP Audit Compliance Integration Register

Digital Access is one of the most common findings in SAP Enhanced Audits. Organizations that know their integration landscape, have clarified their DAAP status, and track document volumes go into the conversation prepared. This checklist walks you through the ten essential preparation steps.


Why Digital Access Comes Up So Often in Enhanced Audits

In an SAP Enhanced Audit, the Global License Auditing team systematically analyzes your integration architecture. SAP requests a complete list of all third-party systems with SAP interfaces and evaluates transaction logs to reconstruct which technical users generated which document types.

The nine document types, Sales Order Items, Purchase Order Items, Service Order Items, Manufacturing Order Items, Invoice Items, Payment Items, Goods Movement Items, Journal Entries, and Inbound Delivery Items, are each checked against their licensing basis. Systems without a documented Named User license and without a Digital Access Supplement appear as compliance gaps in the audit findings.

The typical pattern: e-commerce platforms with high order volumes, RPA bots in the invoice process, WMS systems with automated goods movements. All scenarios in which Digital Access licensing obligations arise that remain invisible without ongoing documentation.

The ten steps below structure your preparation. They are not a short-term audit project. They are an ongoing governance task that should be anchored in your regular governance moment cadence.


The 10-Step Checklist

Step 1: Map Your Integration Landscape in Full

Compile a list of every system that communicates with SAP through an interface. Start with IT architecture documentation, middleware configurations (SAP Integration Suite, MuleSoft, Boomi, Azure Integration Services), and the interface register maintained by your SAP Basis team.

For each interface, capture:

  • System category (CRM, WMS, MES, e-commerce, RPA, finance portal, procurement platform)
  • Data flow direction (read-only, write, bidirectional)
  • Authentication model (Named User, technical system user, API key)
  • Operational status (live, inactive, in rollout)

Common gaps: shadow integrations introduced without central IT involvement, and middleware flows that no one has fully documented. Go beyond the architecture documentation and talk to the application teams directly.

Step 2: Identify Document Types per Integration

For each write integration, determine which of the nine license-relevant document types it generates. That information lives in the integration's API calls (BAPIs, RFC function modules, OData services) or in the SAP system's transaction logs.

A CRM platform that creates orders via BAPI_SALESORDER_CREATEFROMDAT2 generates Sales Order Items. An accounts-payable portal that posts incoming payments generates Payment Items and Journal Entries. A WMS that posts goods receipts generates Goods Movement Items.

If you do not know which document types are involved, transaction traces in the SAP system (SM66, STAD) or your middleware logs are the right starting point.

Step 3: Measure Document Volume per Integration

For each integration with identified write activity, measure the monthly document volume. The unit is document items, not transactions: a Sales Order with ten line items counts as ten license-relevant items.

A historical measurement covering twelve months gives a reliable picture of actual volumes. Missing historical data can be reconstructed from SAP transaction logs. For the audit period (typically two to three years), you should have at least estimated figures backed by a documented methodology.

This step is the governance moment for "usage" in the FinOptory model: knowing which integration produces how much lets you spot overage risks early and gives you the negotiating basis for a DAAP agreement.

Step 4: Verify the Licensing Basis per Integration

For each write integration, the core question is: on what licensing basis does it operate?

There are three possible answers:

Named User license: The people or systems accessing SAP through the third-party system are licensed as Named Users. This works when you have a small, identifiable group of users with limited volume.

Digital Access Supplement (DAAP): A DAAP amendment is in place and covers Document-Based Licensing for this integration. This is the right fit for high volumes, anonymous users, or fully automated processes.

Recognized exception: Static Read (no writes to SAP) or the export rule (a licensed SAP user set up the automated process). Exceptions must be documented and verifiable.

Integrations that do not fall into one of these three categories should be recorded as compliance gaps.

Step 5: Classify RPA Systems Separately

RPA bots are a regular part of Enhanced Audit findings. SAP has defined two royalty-free license categories: license type 68 for SAP IRPA-native bots and license type 69 for certified third-party RPA bots.

For each production bot, clarify:

  • Does it fall under license type 68 or 69?
  • Is that documented in the contract or license records?
  • How does the bot authenticate against SAP?

Bots that run under their own technical users, fall outside certified categories, or generate document types beyond the SAP IRPA scope definition require either a dedicated Named User license or a DAAP supplement.

Step 6: Run a Contract Generation Check

Which Digital Access Supplement applies under your current contract? This question is especially relevant in two situations:

RISE customers with an on-premise history: The Digital Access Supplement included in a RISE Enterprise Agreement may differ from the supplement in the original on-premise contract. If the integration landscape was carried over during the RISE migration without a license review, there may be constellations that are evaluated differently under the new contract terms.

Existing customers without a DAAP migration: Customers on SAP contracts signed before 2019 with no DAAP amendment added afterward may still be operating under the Indirect Access rules of the old contract model. A contract generation check clarifies the current position.

Compare your Digital Access Supplement against the current version in the SAP Trust Center (sap.com/about/trust-center/agreements.html).

Step 7: Check M&A Integrations Against EA Scope

If your organization has acquired companies in recent years, those entities may bring their own SAP integrations that are not covered by your Enterprise Agreement.

The EA scope defines which legal entities and which systems fall under the included Digital Access terms. Entities added after the contract was signed typically do not automatically fall within that scope. For these scenarios, apply the same review logic as for external integrations.

If you have post-M&A entities in your SAP environment, check explicitly whether their integrations have been brought into the EA scope or whether they need their own licensing basis.

Step 8: Prioritize and Close Open Gaps

For each identified compliance gap, decide whether Named User back-licensing or a DAAP amendment is the right path.

The decision logic: when you have a small number of identifiable users with limited document volume, Named User is the simpler route. When volume is high, users are anonymous, or processes are fully automated with no identifiable individuals, Document-Based Licensing via DAAP is more cost-effective.

For the DAAP agreement, the measured historical document volume from Step 3 is your negotiating foundation. The DAAP program allows a retrospective settlement of the historical period. The sooner this step is completed, the lower your retroactive exposure if an audit follows later.

Step 9: Prepare the Integration Register for Audit Readiness

The output of Steps 1 through 8 is an integration register that consolidates all relevant information for each interface. This register is your answer to the SAP audit request: "Please provide a complete list of all third-party systems with SAP interfaces."

What makes a register audit-ready:

  • Completeness: all production interfaces are captured, including inactive systems that were active during the review period
  • Currency: the date of the last update is documented
  • Licensing decisions: for each interface, the licensing basis and the rationale behind the decision are clearly traceable
  • Volume: historical measurement data or estimated figures with documented methodology are on file

A register assembled under audit pressure at short notice is much harder to defend than one maintained continuously over months as part of regular operations.

Step 10: Establish a License Gate Process for New Integrations

The most reliable form of audit preparation is not creating new gaps. That requires a license gate process for new integrations: before any new interface goes live, the licensing question is resolved.

The process is not burdensome. The questions are clear: Which document types does the integration generate? What volume is expected? Is there a licensing basis? If not, Named User or DAAP extension?

This step anchors Digital Access governance in ongoing operations rather than in an audit project. It is the governance moment for "entitlements" from a governance perspective: whoever decides which interfaces are active and on what licensing basis proactively steers the organization's compliance position. And it is the governance moment that prevents the audit from becoming a findings exercise in the first place.


What This Checklist Does Not Replace

The ten steps provide a structured foundation for audit preparation. They do not replace the legal review of specific contract positions, the negotiation strategy during the audit itself, or the decision about the right timing for a DAAP amendment.

For complex integration landscapes, RISE migrations with a substantial on-premise footprint, or upcoming renewal negotiations, it makes sense to pair your preparation with an independent assessment of your integration exposure.

The goal of this checklist is a concrete one: anyone who knows these ten points and reviews them regularly will not walk into an SAP Enhanced Audit unprepared.


FAQ

How much time should I budget for audit preparation?

That depends on the size of your integration landscape. Organizations with ten to twenty integrations can work through Steps 1 to 6 within a few weeks. For complex portfolios with multiple ERP systems, international entities, and extensive RPA use, a structured inventory is a multi-month project. That is a strong argument for treating these steps not as a one-time project but as a recurring governance moment embedded in your regular operating cadence.

What is the first step when I receive an audit notification?

Start by aligning internally: IT, procurement, and legal should coordinate before the first response goes to SAP. Then review the scope of the notification: which systems and time periods are named? From there, use your integration register (Step 9) to assess your current position and identify any gaps that can still be addressed before data is handed over to SAP.

Do I have to provide SAP with all integration data?

The SAP General Terms and Conditions require you to cooperate with the measurement process for systems within the contract scope. Systems outside the scope and contractually excluded environments are not automatically part of the audit. What exactly must be provided depends on the specific contract language. If the scope is unclear, a legal review before transmitting any data is advisable.

What happens if I discover a gap during audit preparation?

A gap you identify yourself and proactively close is a significantly stronger negotiating position than a SAP finding. If there is time to close a DAAP amendment or purchase Named User licenses before data is handed over, that materially improves your starting position. If time is short, having solid internal documentation and a substantiated estimate of your exposure is still a meaningful foundation going into the negotiation phase.


Further reading in this series: SAP Digital Access and Indirect Access: Understanding Licensing, Audit Risk, and Governance and SAP Digital Access in the Audit: What SAP Examines and How to Be Prepared.

If you want to structure your Digital Access position before your next audit or renewal: book a contract check or schedule an introductory call.

Next Steps

If you would like your current contract reviewed for risks and available commercial levers: the FinOptory Contract Check is a fixed-price engagement that delivers a structured basis within four weeks.

This article is part of our topic hub on digital access and indirect access in SAP. To have one specific contract assessed, the FinOptory Contract Check delivers a structured basis within four weeks.

Bernhard Maendle
Written by Bernhard Maendle Managing Consultant, FinOptory for SAP

Last updated: July 2026