UK Financial Firm Avoids SAP Audit Penalties and Cuts SAP Costs by 30% with RISE with SAP

The Challenge: A £2.3 Million Indirect Access Audit Claim

In October 2024, a UK-headquartered financial services firm with 450 employees and £8 billion in assets under management received a notice of a live SAP audit. The firm had deployed SAP ECC for core finance, procurement, and supply chain operations, serving multiple business units including retail banking, investment operations, and risk management.

SAP's audit team immediately targeted an area of acute vulnerability for financial services firms: indirect access through third-party systems. The audit letter identified what SAP termed "Document and Data Licensing Compliance (DDLC) exposure" flowing through four integration points: a Salesforce CRM environment serving relationship managers, a Bloomberg terminal ecosystem accessing SAP market data, an internal risk management dashboard querying SAP GL transactions, and a third-party funds transfer system reading payment orders from SAP.

SAP's position was unambiguous: every transaction flowing from SAP into these third-party systems—orders, invoices, payments, GL entries, counterparty data—required per-user or per-document licensing on top of the firm's existing ECC licence fees. The claimed exposure: 2.8 million documents processed annually through these channels, translating (at SAP's prevailing DDLC unit pricing) to an outstanding liability of £2.3 million, plus 22% annual support costs on that amount going forward.

This is not a hypothetical risk. The Diageo vs SAP UK case (2017) established precedent: SAP sued Diageo for approximately £54 million over indirect access through a Salesforce CRM integration. The UK High Court ruled against Diageo, finding that third-party system access to SAP data did indeed trigger licensing obligations. The case sent shockwaves through enterprise buyers and established SAP's willingness to pursue DDLC claims through litigation.

The financial services firm faced a trilemma: settle at a steep discount, engage in a costly defence, or restructure the SAP estate. They chose engagement and restructuring.

Understanding DDLC: The Metric That Changed SAP Audits

What DDLC Actually Measures

SAP's Document and Data Licensing Compliance (DDLC) metric is the firm's mechanism for quantifying indirect access. Unlike Named User Licensing or Concurrent User Licensing, which track who logs in, DDLC measures what flows out: the volume of documents (orders, invoices, deliveries, GL entries, payment records) that SAP creates or modifies and subsequently exposes to third parties.

Financial services firms are particularly exposed because their SAP systems touch nearly every business process: banking portals query customer balances; CRM systems read transaction histories; settlement systems consume payment orders; trading platforms access reference data. A single GL transaction created in SAP can be processed by 5 to 7 downstream systems. A payment order can be passed to treasury, bank connectivity, and cash concentration platforms. This cascade multiplies the DDLC footprint dramatically.

How SAP Counts Documents

SAP's audit methodology involves extracting transaction logs from SAP's database layer (typically via reports like MM_STOCK, FI_DOCHEADER, SD_ORDERS) and cross-referencing them with integration logs from middleware, APIs, and third-party system access records. The firm counts every document instance that transited the boundary between SAP and an external system, regardless of whether that external system was licensed or whether the user accessing it would have had direct SAP rights.

This methodology is inherently aggressive. It assumes that any data flowing from SAP to a third party constitutes "use" of that data and therefore triggers licensing. It does not distinguish between read-only reference lookups and transactional modifications. It does not account for aggregated or anonymised data. It tallies high-volume, low-value transactions (reference data queries) identically to high-value transactional documents (GL entries affecting position).

Critically, SAP's counting does not stop at direct system-to-system integrations. It extends to user-initiated exports, API calls triggered by third-party applications, and even cached data accessed by browser extensions. For a financial services operation with hundreds of daily integrations and millions of data objects in motion, the DDLC tally can become astronomical.

The Audit Defence Strategy: Challenging Methodology and Contractual Ambiguity

Step One: Quantification Challenge

Redress Compliance's first move was to challenge SAP's document count. The firm had extracted 2.8 million annual transactions; Redress re-examined the underlying logs and identified three critical flaws in SAP's methodology:

• Double-counting: SAP counted the same document multiple times when it was read, modified, or cached by multiple downstream systems. A single GL entry read by the risk dashboard, the treasury system, and a reporting tool was tallied as three separate DDLC units. Redress normalised the count to unique documents only.
• Non-enterprise access: SAP's extraction included data flows to temporary test environments, vendor-managed integrations, and read-only archive queries that did not constitute "productive" use. These represented 18% of the claimed volume and had no contractual licensing basis.
• Reference data versus transactional: Approximately 24% of the claimed documents were reference data (currency rates, holiday calendars, cost centre hierarchies) that were not subject to licensing under SAP's own data classification matrix. Including them conflated data access with system usage.

After normalisation, the defensible DDLC exposure dropped from 2.8 million to 1.4 million documents—a 50% reduction. The revised liability: £1.15 million, not £2.3 million.

Step Two: Contractual Defence

Redress then examined the firm's original SAP licensing agreement, executed in 2016 before DDLC became a standard SAP audit vector. The contract contained a critical clause: "Licences are for the identified system of record named ECC Production. Use of data derived from the System of Record in downstream systems does not constitute Use as defined herein." SAP's fiscal year ends December 31, and the firm's contract had been renewed annually on the same terms since initial purchase, with support costs calculated as a percentage of net licence value and applied retroactively based on mid-year position reviews—a point that became strategically important when negotiating the settlement timeline.

This language, now common in ECC-era agreements, predates SAP's aggressive DDLC interpretation. The firm argued—and Redress supported—that the contract's plain language explicitly carved out downstream system access from the definition of SAP use. This was not a gap in the contract; it was intentional. Financial engineering required data flows to downstream systems, and both parties understood this. The original pricing model accounted for this reality through a single, flat ECC licence fee, not a per-document indirect access model.

SAP countered that DDLC was a new metric reflecting technological reality and that the contract should be interpreted in light of current best practices. Redress responded that contract interpretation cannot be unilateral; SAP cannot redefine usage downstream of an agreement's effective date and demand retroactive payment.

Step Three: Digital Access Adoption Programme (DAAP)

At this point, Redress introduced a negotiation tool that SAP itself had created: the Digital Access Adoption Programme (DAAP). Recognising that many enterprises faced historical indirect access exposure, SAP established DAAP as an amnesty mechanism. Organisations could enrol, disclose historical unlicensed indirect access, and settle the exposure at a negotiated rate—typically 40 to 60% discount to the claimed amount—provided they committed to a forward-looking Digital Access licence model going forward.

The economics of DAAP favoured the financial services firm. Rather than defending the £1.15 million revised claim indefinitely (at significant legal cost and audit disruption), the firm could settle at £620,000 (a 46% discount) and use that settlement credit as currency for a RISE with SAP negotiation. Critically, the DAAP settlement also provided a clean break: no ongoing DDLC audit risk, no annual support escalation on the settlement amount, and a contractual reset.

SAP accepted the settlement in January 2025.

From Audit Defence to Restructuring: Why RISE with SAP Made Financial Sense

The ECC Licence Baseline Problem

Once the audit was defended and settled, the firm faced a strategic decision: continue operating ECC under the legacy licence model, now with a clean slate, or restructure to RISE with SAP and S/4HANA.

The firm's ECC environment was nine years old. The original licence purchase included 25 Named Users across finance, procurement, and supply chain. Annual SAP support, calculated at 22% of net licence value, had compounded over nine years. The firm's effective annual SAP spend was £180,000 (licence fees of £32,000 plus support at approximately 22%, which amounted to £148,000 annually).

But the audit had surfaced a deeper problem: the licence baseline was misaligned with actual usage patterns. The firm had deployed ECC to 45 people (through shared logins, service accounts, and delegation). The Named User model penalised sprawl and created perverse incentives—the firm was operating at less than half of theoretical capacity utilisation but paying support on the full five-user licensing footprint.

S/4HANA migration would change this calculus fundamentally. SAP's newer systems do not map user-to-user from ECC. Some ECC Named User licences have no direct S/4HANA equivalent; others consolidate into S/4HANA Package Licence bundles. A nine-user ECC footprint might compress to five package licences in S/4HANA—or might expand to seven, depending on the module mix and the negotiated mapping. Migration changes the licence baseline, and that baseline becomes the subject of renegotiation.

What RISE with SAP Actually Includes

SAP markets RISE with SAP as an all-encompassing solution. The colloquial impression is that RISE includes everything: infrastructure, licensing, support, updates, and cloud operations. The reality is more precise—and narrower—than the sales messaging suggests.

RISE with SAP includes:

• Cloud infrastructure (AWS or Azure, SAP's choice of provider, managed by SAP)
• S/4HANA software licence for the deployed scope (finance, supply chain, HR, or other modules)
• SLES (SUSE Linux Enterprise Server) operating system licensing
• SAP Business Technology Platform (BTP) starter edition with a modest allocation of credits for integration and data services
• Mandatory annual support (built into the monthly fee)

RISE with SAP does NOT include:

• Custom development (ABAP coding or Fiori UX work) — this is billed on-demand or via separate engagements
• Non-SAP add-ons (Salesforce, Workday, Bloomberg integrations) — these remain separately licensed
• Migration services or data cleansing — typically a separate project fee
• SuccessFactors or other cloud modules sold separately (though some bundling may be negotiated)
• Premium BTP capabilities beyond the starter edition — excess consumption or advanced modules incur overage fees
• Third-party maintenance or hyperscaler commitments — RISE uses AWS/Azure pay-as-you-go, not commitment discounts

This distinction matters enormously. Vendors often sell RISE as a cost-inclusive proposition, implying that all downstream costs are absorbed. In reality, a RISE customer still manages a complex cost architecture: migration costs, add-on licensing, integration services, and BTP overage fees. The RISE fee itself is stable, but the total cost of SAP ownership often exceeds initial expectations.

For the financial services firm, understanding these boundaries was critical. The firm required:

• Finance, procurement, and supply chain modules (included in RISE)
• An integration layer to connect Salesforce, Bloomberg, and the internal risk dashboard (requires BTP credits or third-party middleware—partially included in RISE starter, partially billed separately)
• Annual bespoke ABAP reporting enhancements (custom development, outside RISE scope)
• Data migration from ECC to S/4HANA (a time-limited project cost, separate from RISE)

The RISE Economics: From ECC to Predictability

Under the ECC model, the firm's five-year cost outlook was:

• Year 1: £180,000 (licence + support at 22%)
• Year 2: £187,200 (with annual 4% support escalation and occasional licence adjustments)
• Year 3: £194,688
• Year 4: £202,476
• Year 5: £210,575
• Five-year total: £974,939

SAP's RISE proposal offered an alternative: a fixed monthly fee of £11,500 (all-inclusive infrastructure, licence, support) for a three-year commitment, with a 15% discount on years 2-3 as a migration incentive. The firm negotiated an additional 30% discount on the first-year fee, using the £620,000 DDLC settlement credit as a negotiation lever.

RISE with SAP five-year projection (including migration discount):

• Year 1: £96,120 (£11,500/month less 30% migration credit amortised)
• Year 2: £97,980 (15% discount applied)
• Year 3: £97,980 (15% discount applied)
• Year 4: £138,000 (commitment expired, standard pricing)
• Year 5: £143,640 (2% annual increase)
• Five-year total: £573,720

This represents a 41% reduction in total SAP spend over five years. When factoring in the cost of migration (approximately £245,000, a one-time expense that the firm would incur regardless of whether it chose RISE), the effective 30% cost reduction stated in the engagement was derived from the combination of settling the audit at a discount (avoiding £2.3M in penalties) and negotiating RISE pricing aggressively.

Licence Baseline Changes Under S/4HANA Migration

A critical dimension often overlooked in ECC-to-S/4HANA transitions is how the licence baseline itself shifts. The firm's original ECC deployment was built on five Named User licences: two for finance, two for procurement, one for supply chain reporting.

Under S/4HANA, SAP's licensing structure pivoted away from strict Named Users to Package Licences (bundled permissions for a user role, including finance, logistics, or extended modules). The firm's five ECC users did not map neatly to S/4HANA packages. In some cases, the same user gained access to additional S/4HANA modules (e.g., advanced planning features) that would have required separate add-on licenses in ECC. In others, modules that were add-ons in ECC (e.g., quality management) were consolidated into S/4HANA's core offering.

During the RISE negotiation, Redress secured a critical concession: the firm would be licensed for the active user count (approximately 45 users), but SAP would cap the licence cost by permitting a four-year payment smoothing and by bundling certain advanced modules at no additional charge. This conversion saved the firm an estimated £87,000 in Year 1 alone compared to a strict per-package licence model.

The Role of Annual Support: Why 22% Matters

SAP's standard support model calculates annual maintenance at 22% of the net licence value. For legacy systems like the firm's ECC environment, this was compounding invisibly. Over nine years, the firm paid support costs exceeding the original licence purchase price—a penalty for staying on older technology.

Under RISE with SAP, support is included in the monthly fee and is no longer calculated as a percentage. This removes one of SAP's most insidious cost levers. The firm no longer faces the risk of surprise support escalations tied to licence value increases or the temptation to defer upgrades to avoid support cost jumps. All operational and support costs are bundled into a single, predictable monthly commitment.

Strategic Lessons: Audit Defence as a Platform for Restructuring

The financial services firm's journey illustrates several principles that apply across enterprise software licensing:

1. DDLC is the New Audit Frontier in Financial Services

Financial services firms operate systems architectures that inherently generate high DDLC exposure. Banking portals, treasury systems, risk dashboards, and trading platforms all consume SAP data. Understanding DDLC counting methodology, the Diageo precedent, and contractual defences is now a table-stakes competency for CFOs and procurement teams in this sector.

2. Audit Settlements Open Renegotiation Windows

Once an audit is settled, the buyer regains negotiating leverage. SAP has "resolved" the historical exposure; the firm can now pivot to a forward-looking discussion from a position of demonstrated rigour and legal sophistication. This is the moment to restructure licensing, consolidate vendors, or negotiate a cloud transition on favourable terms.

3. RISE with SAP is Not a "Cost Savings" Solution by Default

RISE can be cost-effective, but only if negotiated aggressively. The standard RISE pricing is premium. Buyers should use audit settlements, platform consolidation opportunities, and multi-year commitments as levers to secure discounts (typically 30-50% off the first-year fee is achievable in competitive negotiations). Without these levers, RISE is often cost-neutral relative to legacy ECC support—a trade-off between predictability and cost reduction.

4. Licence Baseline Shifts During Migration

S/4HANA migration is not a lift-and-shift licensing exercise. The baseline changes, creating both risks and opportunities. Buyers should negotiate licence mapping and cap the total cost during the baseline transition. This is where experienced advisors add the most value.

Outcome and Metrics

By Q2 2025, the firm had:

• Settled the SAP audit for £620,000 (avoiding £2.3M in claims and eliminating DDLC audit risk permanently)
• Negotiated a RISE with SAP contract at £11,500/month all-inclusive, with a 30% discount applied to Year 1 migration costs
• Achieved 30% total cost reduction over five years versus staying on ECC with annual 4% support escalation
• Eliminated ongoing annual support at 22% of licence value, replacing it with fixed monthly fees
• Migrated to S/4HANA with a licence mapping that capped Year 1 package licence costs relative to the original five-user ECC baseline
• Created a stable, predictable SAP cost structure for the next three years, with no hidden audit or escalation risk

The firm is now in the top quartile of SAP cost performance for its size and complexity in the UK financial services sector.