The Integration Register as the Compliance Foundation for Digital Access

Anyone who wants to understand their Digital Access exposure needs a complete answer to one straightforward question: which systems have an interface to SAP, and what do they write into it?

That question sounds simple. In practice, it is not. CRM systems, warehouse management solutions, RPA bots, e-commerce platforms, treasury systems: all of them can generate document items through their SAP interfaces that trigger a licensing obligation. Which ones specifically do so, and whether the applicable license basis is documented, is rarely tracked systematically in most SAP portfolios.

The integration register closes that gap. It is not an audit document you create once and file away. It is a living tool within your governance cadence, the governance moment that determines whether you enter an Enhanced Audit with a clear picture or with a backlog of explanations.

Why the integration register is the starting point

Digital Access governance begins with visibility. If you do not know which integrations in your portfolio create which document types in SAP, you cannot assess license status, identify overage risk, or prepare for a DAAP negotiation.

In practice, integration landscapes grow over time, often without a central inventory. IT architecture documentation captures systems and interfaces from an operational perspective. The question of which interfaces create document types subject to licensing is rarely carried along.

That creates a governance moment around entitlements: which interfaces are active, which document types do they generate, and is the license basis for each interface documented? That is not purely a technical question. It is a governance question, and it sits with contract management and procurement.

The integration register is the structured answer: built systematically, maintained within the governance cadence, and used as a reliable foundation at renewal and audit.

What information to capture per integration

A reliable integration register captures seven categories of information for every interface to SAP.

System name and owner: The name of the third-party system, the technical point of contact, and the business unit responsible for it. That assignment matters because licensing decisions affect the business side, not just IT.

Communication direction: Does the system only read SAP data (Static Read, no licensing obligation), or does it write back to SAP? For bidirectional interfaces, the write direction is what triggers the licensing requirement.

Document types generated: Which of the nine defined document types does the interface create in SAP? Sales Order Items? Goods Movement Items? Journal Entries? Interfaces that create nothing from the list of nine types carry no Digital Access obligation.

Monthly document volume: How many document items does the interface generate per month? That number is the planning basis for DAAP quotas and the input for the Named User vs. Document-Based Licensing decision.

User base: Who is behind the interface? Internal employees, external customers, suppliers, or fully automated processes (bots)? The answer directly influences which licensing path is appropriate.

Current license basis: Named User license, Digital Access Supplement (DAAP amendment), a recognized exception (Static Read, export rule, IRPA type 68/69 bot), or no documented basis. This entry is the core of the compliance assessment.

Status date and last review: When was the interface last verified for accuracy? An entry that is not maintained loses its evidentiary value.

These seven fields are the minimum. In larger portfolios, additional fields may be useful, for example the middleware through which the interface runs, or the review status following a RISE migration.

How to build the register (step by step)

Building the integration register follows a structured five-step process.

Step 1: Identify all systems with an SAP interface

The first step is a comprehensive inventory. Sources include IT architecture documentation, middleware configurations (SAP Integration Suite, SAP PI/PO, iPaaS platforms such as MuleSoft or Boomi), interface registries, and, often overlooked, past SAP contract negotiations where specific integration components were already addressed commercially.

A survey of business units is also recommended: which external systems consume SAP data or write to SAP? Business units frequently know about systems that appear in no IT documentation, because they were introduced as business applications without a formal IT architecture review.

Step 2: Capture document types and volume per interface

For each identified interface, determine which of the nine Digital Access document types it creates and at what volume. Volume should be calculated over a representative period of at least twelve months to account for seasonal variation.

For interfaces where volume cannot be read directly from a monitoring tool, transaction logs in SAP or the middleware can serve as the source. The SAP Measurement Tool, which is also used in the DAAP process, is a suitable instrument for this exercise.

Step 3: Assess license status per interface

With the inventory from step 1 and the volumes from step 2, assess the license status for each interface. Is there a documented license basis? If yes, which one? If not, flag that interface as a gap.

Not every gap carries the same risk profile. An interface that generates thousands of Sales Order Items daily with no license basis has a different exposure than one that writes a handful of Inbound Delivery Items per month. Gap prioritization should reflect both volume and document type.

Step 4: Make licensing decisions and implement them

For each identified gap, decide: Named User or Digital Access? The decision logic follows the relationship between user base and document volume. When the user population is known, identifiable, and limited in size, Named User is often the simpler path. When users are anonymous, volumes are high, or processes are fully automated, Document-Based Licensing is the stronger option.

Document that decision. In an audit, the traceability of the decision logic matters at least as much as the outcome itself.

The result feeds into a contract change: a DAAP amendment for Document-Based gaps, a Named User addition for identifiable user scenarios. For DAAP negotiations, the integration register is the factual basis you bring to SAP.

Step 5: Establish the register as a living document

The integration register only holds its value if it stays current. That requires two mechanisms.

First, new integrations go through a license review before go-live. That is not an optional step, it is a mandatory checkpoint in the rollout process. Deploying a new interface without a prior Digital Access review creates a compliance gap.

Second, a quarterly review of the register. Check volume trends, capture changed system configurations, add new integrations, mark inactive interfaces as such. That cadence is part of the systematic governance approach for the governance moment around entitlements.

Introducing new integrations: license review as a mandatory checkpoint

One of the most common causes of Digital Access gaps is not the existing portfolio. It is the new integration introduced without a license review. An RPA rollout approved on short notice. A new e-commerce platform where the interface architecture is in the spec but the license question is not. An additional WMS module treated as a technical extension.

The governance moment for new integrations comes before go-live, not after. The license review should be embedded in the rollout process, anchored in the acceptance criteria or the release checklist.

Three questions need answers before a new integration goes live. First: does it create any of the nine Digital Access document types in SAP? Second: which licensing path applies, Named User or Digital Access? Third: is the license basis documented in the integration register and reflected in the contract?

Answering those three questions before go-live avoids the remediation effort that accumulates in many portfolios during a RISE migration or an Enhanced Audit.

Ongoing maintenance: the quarterly review process

The integration register loses its value if it is not maintained. Quarterly reviews are the cadence that keeps it current.

A structured quarterly review covers four checkpoints.

Volume trends: Has document volume per integration changed significantly over the past quarter? Which interfaces are approaching their agreed quota? Are there growth trends that point toward an overage situation in coming quarters? These questions are the governance moment around usage.

New integrations: Were new interfaces introduced or existing ones materially changed during the past quarter? Are they captured in the register with a documented license basis?

Inactive integrations: Which interfaces are licensed but no longer active? Licensed but inactive integrations are an opportunity to return quota or adjust agreements. Maintaining the register quarterly surfaces those opportunities systematically.

Infrastructure changes: Were middleware components replaced, new API types introduced, or system boundaries shifted by a RISE migration? The governance moment around infrastructure asks whether those changes affected the Digital Access status of any interface.

How the integration register is used at renewal and audit

The integration register is not only an internal governance tool. It delivers its greatest value in two external situations.

In the SAP Enhanced Audit

In an Enhanced Audit, SAP requests a complete list of all third-party systems with SAP interfaces. If you maintain a current integration register, you can fulfill that request in a structured way. Without a register, you are conducting the inventory under time pressure, with the risk of gaps.

A complete register signals to SAP that the integration estate is known and actively governed. That shifts the dynamic in the audit: you come not as a reactive party providing explanations on demand, but as a party that knows its estate and is prepared to discuss it.

For interfaces where the license basis is documented, the conversation about back-claims does not arise. For gaps that were already identified and addressed through a DAAP amendment, there is no retroactive exposure. The integration register is what ensures an Enhanced Audit produces no surprises.

In the renewal negotiation

SAP renewals are the governance moment around cost, where document volume and quota structure are negotiated. If you know your volumes, have documented your growth assumptions, and can demonstrate the current license status of all integrations, you negotiate from a solid foundation.

Going into a renewal negotiation without a complete view of your integration estate risks SAP proposing quota increases based on their own measurements, which may exceed your actual requirements.

The integration register is not a negotiating argument in the rhetorical sense. It is the factual foundation without which an independent negotiating position on Digital Access cannot be credibly established.

FAQ

What format works best for an integration register?

That depends on portfolio size. For smaller integration landscapes with fewer than twenty interfaces, a structured spreadsheet format is sufficient. For larger portfolios, or those with frequent changes, a dedicated governance tool that tracks version history, status changes, and volume trends is worth considering. The format is secondary. What matters is that it is maintained consistently.

How precise does the volume data need to be?

Precise enough to identify overage risk and negotiate DAAP quotas. Exact daily figures are not required. Monthly averages based on a twelve-month period are a reliable foundation. Completeness across the register matters more than precision at the individual interface level.

Who owns the integration register?

In practice, ownership sits at the intersection of IT architecture, contract management, and procurement. IT provides the technical information on interfaces and volumes. Contract management assesses license status. Procurement ensures licensing decisions translate into contract changes. Without clear ownership, the register will not be maintained.

Can FinOptory help build and maintain the integration register?

Yes. The contract check includes an inventory and assessment of the integration estate. Within the Managed Service model (We govern), the integration register is maintained as part of the ongoing governance cadence and deployed at renewal and audit.

The integration register is not a large project. It is a structured step that makes the governance moments around Digital Access operational in the first place. If you know your integration estate, you govern. If you do not, you react.

If you want to understand where your portfolio stands today, the contract check is the right starting point. In four weeks, you will have a reliable picture of your Digital Access status and clear recommendations for the next step.