Enterprise Software Licensing FAQ: Answers to the Questions CIOs Ask Most

Audit and Compliance Questions

What is a software licence audit and can I refuse one?

A software licence audit is a formal review initiated by a software vendor to verify that your organisation's actual software deployment matches the licences you have purchased. Most enterprise software agreements include audit rights clauses that permit the vendor to conduct audits with reasonable notice — typically 30 to 60 days. You cannot legally refuse an audit that is conducted pursuant to the audit rights clause in your agreement, but you have significant rights regarding how the audit is conducted, what data is shared, and how the results are interpreted.

Before engaging with any audit, review the specific audit rights language in your agreement. Many audit clauses specify that audits may not occur more than once per year, must use an independent auditor (not the vendor's own team), and require confidentiality obligations on audit findings. Exercising these rights can significantly affect the audit process and outcome.

What should I do immediately when I receive an audit notification?

When you receive a software audit notification, take the following immediate steps: do not respond to the vendor until you have engaged independent counsel or a specialist adviser; review the audit rights clause in your agreement to understand the scope and procedural requirements; assemble your internal licence data — purchase records, deployment records, and any previous audit findings; and identify the internal team that will manage the audit (IT, legal, procurement, and finance representatives). The most common mistake organisations make is responding to audit notifications without understanding their rights or their licence position, which allows the vendor to frame the audit on its own terms.

How do I know if I am out of compliance before an audit?

A proactive licence compliance review — sometimes called an internal audit or licence position assessment — compares your actual deployed software against your purchased licence entitlements. This is the same analysis that vendors perform during a formal audit, but conducted before the vendor engages. A proactive review allows you to identify compliance gaps, remediate them, or prepare a commercial response before the vendor's audit team arrives. Organisations that conduct proactive licence reviews before audit notifications typically achieve substantially better audit outcomes than those that engage reactively.

Licensing Model Questions

What is the difference between perpetual and subscription licensing?

A perpetual licence grants the right to use software indefinitely — you pay once for the licence and annually for support and maintenance, which typically runs at 20 to 22 percent of licence cost per year for major vendors like Oracle and SAP. A subscription licence grants the right to use software for a defined term (typically one to three years) at a fixed annual fee that includes support. When the subscription ends, the licence right expires.

The commercial decision between perpetual and subscription depends on time horizon, financial preference (OpEx vs CapEx), and the organisation's relationship with the product. Perpetual licences are advantageous for stable, long-term deployments where the software is expected to remain in use for ten or more years. Subscription licensing is advantageous when flexibility, cloud deployment, or shorter time horizons are priorities. Many organisations in transition — migrating from on-premises to cloud — benefit from subscription licensing during the transition period, accepting higher short-term costs for greater flexibility.

What is an Enterprise Licence Agreement (ELA) and when does it make sense?

An Enterprise Licence Agreement is a broad licence arrangement that covers an entire organisation's use of a defined set of software products, typically at a fixed annual or multi-year cost, in exchange for unlimited or substantially unrestricted deployment rights within the agreed scope. ELAs can eliminate per-unit licence tracking complexity and create predictable cost, but they also create risk: organisations that sign ELAs without an accurate understanding of their actual deployment needs frequently overpay significantly.

ELAs are appropriate when an organisation has high and growing deployment that would otherwise trigger significant per-unit licence fees, when administrative complexity of per-unit tracking exceeds the cost of the ELA, or when the ELA price is genuinely competitive with projected per-unit cost over the agreement term. ELAs are inappropriate when deployment is stable or declining, when the ELA scope includes products the organisation does not use, or when the ELA includes restrictive terms that limit competitive leverage at renewal. Independent modelling of ELA value — comparing the all-in cost of the ELA against projected per-unit licensing over the same term — is essential before signing.

What is shelfware and how do I reduce it?

Shelfware is licensed software that is paid for but not used or significantly underutilised. Industry research suggests organisations waste between 25 and 48 percent of their software budget on shelfware — licences purchased through ELAs, multi-year commitments, or renewal inertia that exceed actual deployment. Shelfware accumulates for several reasons: ELA scope is defined at peak projected usage that is never reached; subscriptions auto-renew without usage review; departmental purchases overlap with centrally managed licences; and cloud migration leaves on-premises licences orphaned.

Reducing shelfware requires both a one-time clean-up and ongoing governance. The clean-up involves a full licence utilisation analysis — comparing actual deployed and active users against licensed quantities for every product in the estate. The ongoing governance involves integrating utilisation data into the renewal process so that every renewal reflects actual usage rather than historical licence counts.

Vendor-Specific Licensing Questions

How does Oracle's audit programme work and why is it so aggressive?

Oracle's audit programme is conducted through its Licence Management Services (LMS) division, which is the largest software audit team in the industry. Oracle initiates audits based on several triggers: renewal activity (Oracle audits frequently precede or coincide with renewal conversations), public cloud deployment (Oracle's licensing in cloud environments is complex and frequently non-compliant), virtualisation (Oracle does not recognise most virtualisation technologies for software partitioning purposes, meaning software installed on virtual machines may require full physical server licensing), and merger and acquisition activity (which often creates unanticipated licence transfers).

Oracle's virtualisation policy is the most consequential and frequently misunderstood aspect of Oracle licensing. Oracle recognises only Oracle VM and Oracle Solaris Zones as "hard partitioning" technologies that limit the licence footprint to the assigned partition. VMware, Hyper-V, and other common virtualisation platforms are not recognised by Oracle, meaning Oracle software on a VMware cluster must generally be licensed for all physical processors in the cluster that could run the software — not just the hosts where it is currently deployed. This single rule is responsible for the majority of large Oracle audit findings.

How does IBM sub-capacity licensing work and what are the compliance requirements?

IBM sub-capacity licensing allows organisations to licence IBM software products based on the virtual processors (Virtual Processor Cores, or VPCs) assigned to the virtual machine running the software, rather than the full physical processor capacity of the host server. For workloads running on a small number of VPCs on a large physical server, sub-capacity licensing can reduce licence requirements by 60 to 90 percent compared to full-capacity licensing.

Sub-capacity licensing is only valid when IBM's Licence Metric Tool (ILMT) is correctly deployed and generating compliant reports. ILMT must be installed and configured to scan all systems where IBM software is deployed. Reports must be generated at least quarterly and retained for audit purposes. If ILMT is not deployed or generates non-compliant reports, IBM's position in an audit is that the organisation must licence at full-capacity — regardless of actual deployment. ILMT compliance is therefore not optional for any organisation using sub-capacity IBM licensing; it is the commercial prerequisite for the licensing model to be valid. IBM's fiscal year ends December 31, which is when IBM's audit activity and renewal pressure peak simultaneously.

What are the most common Microsoft licensing traps?

Microsoft's licensing complexity creates several common traps. The seven-day EA renewal window is the most time-sensitive: organisations have only seven days after the EA renewal date to reduce named user licence counts on annual terms. Missing this window means paying for excess licences for the full following year. The second common trap is the treatment of unlicensed installations — Microsoft's audit programme, conducted through the Software Asset Management (SAM) programme, identifies installations across all devices including those not managed by the IT department. The third trap is cloud licensing: Azure Hybrid Benefit allows on-premises Windows Server and SQL Server licences to be used in Azure, but the rules for active and passive failover licensing in Azure differ from on-premises rules and are frequently misapplied. Finally, Microsoft 365 add-on licensing — Copilot, Power Platform, Teams Phone — accumulates without centralised oversight and frequently creates duplicate or redundant capability.

What is SAP's metric system and how does it affect compliance?

SAP licences its software against user-based metrics — Named User licences — and in some cases against resource-based metrics for specific applications. Named user types (Professional, Limited Professional, Employee, Developer) have specific rights to access different SAP functionality. The compliance risk arises when users access functionality that exceeds their licence type — for example, an Employee licence user accessing transactions that require a Professional licence. SAP's audit methodology counts the functionality accessed by each user and maps it to the highest licence type required. Organisations that have not periodically reviewed user activity against their licence profile frequently discover that a significant proportion of their user base requires a higher licence type than purchased.

True-Up and Renewal Questions

What is a true-up and how do I manage it effectively?

A true-up is a contractual reconciliation process — most commonly in Microsoft EA agreements and IBM Passport Advantage agreements — that requires the organisation to report actual software deployment at a defined point and pay for any excess over the previously contracted quantity. True-ups in Microsoft EA agreements occur annually. IBM true-ups occur at contract renewal for subscription agreements.

Effective true-up management involves three elements. First, tracking deployment accurately throughout the year so there are no surprises at true-up time. Second, right-sizing licences proactively before the true-up date by reducing access for users who have left the organisation or whose role no longer requires the licensed software. Third, using the true-up conversation as a negotiating opportunity — vendors treat true-up conversations as renewal opportunities, and organisations can use the commercial discussion to negotiate better unit pricing on incremental quantities.

How much notice should I give before a major renewal?

For Enterprise Agreements, ELAs, and other major software agreements above five million dollars annually, the recommended planning horizon is twelve to eighteen months before renewal date. This allows time for licence utilisation review, independent benchmarking, competitive evaluation, and stakeholder alignment. Vendors prefer to begin renewal conversations three to six months before expiry — a timeline that favours the vendor's preparation over the buyer's. Beginning your internal preparation at twelve to eighteen months, while engaging the vendor at six to nine months before expiry, consistently produces better commercial outcomes than vendor-managed renewal timelines.

Negotiation Questions

Can I negotiate enterprise software pricing or is the list price fixed?

List price is irrelevant for enterprise software. Every major enterprise software vendor — Oracle, SAP, Microsoft, Salesforce, IBM, ServiceNow, Workday — negotiates pricing with enterprise customers. The question is not whether to negotiate, but how effectively. For large agreements (above one million dollars annually), negotiated discounts of 40 to 70 percent below list price are achievable and standard. For smaller agreements, the discount range is narrower but still material. The primary drivers of negotiating leverage are deal size, competitive alternatives, timing relative to vendor fiscal year-end, and the buyer's knowledge of market-rate pricing through independent benchmarking.

Does engaging an independent adviser help with licence negotiations?

For agreements above five million dollars annually, independent advisory consistently delivers measurably better outcomes than internal-only negotiations. The adviser's value lies in three areas: market-rate benchmarking data (what peer organisations pay for comparable products and volumes), vendor-specific knowledge of what concessions are achievable and what commitments vendors will resist, and negotiating process expertise that prevents common buyer-side mistakes such as anchoring to vendor proposals, negotiating in sequence rather than holistically, or revealing budget constraints that vendors use to anchor pricing. The ROI on independent advisory for major enterprise software renewals is typically ten to fifteen times the advisory fee in year-one savings.