FinOps for SAP RISE: Stop Paying for the Tier Above

FinOps for SAP RISE starts with one question: are you paying for what you actually use? When people talk about FinOps — the discipline of controlling cloud costs — almost nobody looks at the company’s largest IT contract: RISE with SAP. And yet that is exactly where the hidden money lives. The RISE cost is driven by three levers: the license (FUE), HANA memory (sizing), and cloud consumption. Companies that manage all three pay a fair price. Companies that do not, however, pay for the tier above.

In this guide, we explain FinOps for SAP RISE from scratch — with special attention to the FUE model, which almost nobody explains properly — plus a calculator so you can estimate your own position.

In one sentence — FinOps for SAP RISE is like reviewing your household bills: the license is your mobile plan (everyone pays for allowance they do not use), the memory is the size of your apartment (you pay for the space whether you live in it or not), and consumption is the electricity bill. All three can be reviewed — and all three come down.

Lever 1 — FUE: the single currency of SAP licensing

In RISE, SAP abandoned selling licenses by type and created a single currency: the FUE (Full Use Equivalent). All users are converted into FUEs, and the contract defines how many you bought. The conversion works like this:

Developerdevelops in the system Advancedcreates and changes across a broad scope Corefunctional use within a limited scope Self-Serviceviews, approves, records entries FUEthe contract’s currency 1 user = 2 FUE 1 user = 1 FUE 5 users = 1 FUE 30 users = 1 FUE
The FUE model: the broader the access, the more expensive the user — and the developer is the most expensive of all.

Calculate your FUEs




Estimated total: 34 FUE

A didactic estimate using the standard conversion — your contract and the official measurement rule. Ask Inove for the real X-ray.

The detail that catches everyone

The classification is not based on what a user does — it is based on what the user CAN do: the authorizations they hold. The measurement applies rules that map profile → user type. Therefore, click each money drain to understand it:

💸 Drain 1 — Broad profile, small usage

The user who “only views reports” but inherited a profile with write transactions counts as Advanced (1 FUE) instead of Self-Service (1/30 of an FUE). Multiplied by dozens of users, this is the most common drain — and, in addition, the easiest one to close with authorization engineering.

👻 Drain 2 — Invisible consumption (the workflow case)

We saw it in practice: workflow approvers who only click “approve” being classified in high tiers, because the workflow design (the logic that defines the approval agents) gave them a formal role in the purchasing process. Nobody could explain the FUE overage — until we looked at the workflow design. Once the design was adjusted, the overage dropped.

🧟 Drain 3 — Forgotten users

Technical users, data-load users, and accounts of former employees keep counting for as long as they exist without correct typing or an expiration date. Therefore, user hygiene is direct money.

What about Digital Access? The license for “users who are not people”

FUE covers people logging into SAP. Today, however, much of the work is not done by people: the e-commerce platform creates orders, a robot (RPA) posts invoices, the supplier portal writes documents, a third-party WMS moves stock. This “by proxy” usage — external systems writing into SAP with nobody logged in — is called indirect access, and SAP licenses it with a different ruler: Digital Access.

The logic is a toll per document created: instead of counting users, you count how many documents external systems generate inside SAP. SAP defined nine document types that pay this toll — among them sales orders, invoices, purchase orders, manufacturing orders, service orders, and financial documents. Each type has its own weight in the bill, and one detail matters: creation is charged, not reading — querying data from outside generates no toll; creating a document does.

⚠️ Why does this surprise so many companies?

Because integration grows in silence. The e-commerce platform that created 200 orders per day starts creating 5,000; a new robot starts posting invoices; a marketplace goes live. None of them “buys a license” — yet all of them generate documents. Then, at renewal (or in an audit), the bill arrives all at once. In RISE, the Digital Access volume is negotiated in the contract — and whoever comes to the table without knowing how many documents they generate is negotiating in the dark.

🧭 How to defend yourself (and pay a fair price)

Three moves: (1) inventory the integrations — everything that writes into SAP from outside (interfaces, robots, portals, EDI); (2) measure document creation by origin, using SAP’s own estimation tools, so you know the real number; (3) negotiate with evidence — at the RISE renewal, bring the measured volume and the growth projection. In addition, on the architecture side, design integrations that do not create documents needlessly (grouping, validation before posting).

In short: FUE licenses the people; Digital Access licenses the machines. Complete FinOps for SAP RISE looks at both — plus memory and consumption, the levers that follow.

Lever 2 — HANA memory (sizing)

The RISE contract is also sized by HANA database memory — and each sizing tier has a price. Because HANA keeps data in RAM, database growth pushes the contract upward. The answer, therefore, is data volume management (DVM): archiving, technical housekeeping, attachments outside the database, and data tiering (NSE). A lean database = a lower tier at renewal.

Lever 3 — Cloud consumption

BTP, additional environments, integrations, and usage-based services complete the bill. Here, classic FinOps applies: measure, assign an owner, and optimize. For example, in a recent public-cloud FinOps engagement, we found committed use discounts (CUDs) sitting at 0% utilization and machine families with less than half of the discount actually captured — money contracted and never used. In RISE, the equivalent happens.

Where AI helps on this journey — we use AI to accelerate every step: mass analysis of user typing (crossing profiles with real usage), intelligent reading of measurement reports, detection of anomalous consumption patterns in the cloud, and contract scenario simulation before renewal. As a result, what used to take weeks of spreadsheets takes days — with evidence.

How Inove helps

We run complete FinOps for SAP RISE: an X-ray of the contract and the FUE measurement, user retyping and authorization engineering, DVM to hold the sizing down, and cloud consumption management — with the real-world experience of a team that has already reduced FUE overages and operates multi-cloud FinOps.

Our long-standing vision: we want our clients to have zero IT headaches and be happy — paying a fair price, never the tier above.

Where to start with FinOps for SAP RISE

  1. Contract X-ray — FUEs purchased × measured × actually needed.
  2. Retyping plan — next, close the three drains without taking access away from anyone.
  3. DVM — a volume plan for the renewal.
  4. Continuous FinOps — finally, license, memory, and cloud watched all year round.
Infographic: the 3 levers of FinOps for SAP RISE — FUE, Digital Access, memory, and consumption
The 3 levers of the contract — and the 3 drains where the money escapes.

Read next

Want to know how many FUEs you really need? Talk to Inove Solutions — the X-ray usually pays for itself.