SAP engine licensing — the metrics SAP audits, the traps buyers miss.

SAP engines come in four families — each with its own metering logic.

Engines are the SAP components licensed independently of named users. They fall into four broad families. Database engines (SAP HANA, the legacy ASE/IQ/MaxDB stack, runtime licenses for third-party databases) are metered by memory capacity (HANA) or by core/CPU (legacy databases). Application engines (Convergent Charging, Convergent Invoicing, Bank Communication Management, Treasury & Risk Management) are metered by record throughput, document volume, or transaction count. Integration engines (PI/PO, Cloud Integration, Event Mesh) are metered by message count or connection count. Master data engines (Master Data Governance, Product Lifecycle Management) are metered by master data records.

Each family has its own measurement instrument. HANA memory is read directly from the database. Application engine consumption is reported via specific transaction codes (USMM extracts, LAW consolidation). Integration engine throughput is metered by the runtime itself. Master data is counted at fiscal year-end against the contract baseline. The buyer's compliance position is the sum across all four families — and most buyers monitor only the first.

HANA is licensed by GB — and the GB counted is not the GB you think.

SAP HANA is licensed per GB of provisioned in-memory capacity. The metric counted in compliance is the licensed capacity allocated to the HANA instance — not the GB in active use. Idle memory still consumes entitlement. The licence model further distinguishes runtime editions (allow only SAP applications running on the database, lower price point) from full-use editions (allow non-SAP workloads, materially higher price). A common compliance finding is non-SAP analytic workloads (Tableau, Power BI direct query) running against a runtime HANA — which converts the licence to full-use retroactively at audit.

HANA right-sizing is one of the highest-ROI optimisations in the SAP estate. We typically find 15–30% over-provisioning in HANA instances that have not been re-sized since their initial migration, with corresponding licence over-commit that is recoverable at the next renewal.

Runtime license boundary policing

The runtime-vs-full-use boundary is a frequent audit topic. The technical test SAP applies is whether non-SAP applications execute SQL directly against the HANA database. A read-only BI tool connecting through an SAP-controlled view layer (SAP Analytics Cloud, BW/4HANA) typically remains within runtime scope. A direct ODBC/JDBC connection from a third-party BI tool typically does not. The architecture decision and the licence decision must be made together.

Document-counted engines scale linearly with business growth — and so do the bills.

Digital Access (the indirect-use metric) is the most prominent document-metered engine, but it is not the only one. Convergent Charging is rated by billable event volume. Treasury & Risk Management is rated by financial position count. PI/PO is licensed by message volume. Each of these grows with the underlying business. A buyer who signs a 3M document allocation at S/4HANA migration may find themselves at 8M three years later, with a contractual right to be charged for the overage at list price.

The negotiation move is to build true-up flexibility into the original contract: bracketed pricing (price per million documents tiered down at higher volumes), a multi-year shelf reservation that the buyer can draw against, or a fixed-fee cap that converts to consumption pricing only beyond a high water mark.