Software Licensing Pitfalls: How Businesses of All Sizes Can Stay Compliant

The Compliance Landscape Has Changed — Most Organisations Haven't Kept Up

Software licensing compliance was relatively straightforward in the era of on-premises software and simple per-seat licensing. You bought a number of licences, you deployed that number of users, and compliance was a counting exercise. That world no longer exists. Virtualisation, cloud, SaaS, hybrid deployments, container-based architectures, and the proliferation of AI-embedded software have all created licensing complexity that most organisations are not equipped to track, particularly without dedicated software asset management capability.

The consequence is predictable: licence drift — the gradual divergence between contractual entitlements and actual deployments — accumulates silently. Vendors, whose audit programmes have grown significantly more sophisticated in recent years, identify the drift before the customer does. The financial impact is calculated at list price, without the discounts that a proactively managed customer relationship would command. The result is the $3.4 million average audit settlement that characterises 2025's software compliance landscape.

The good news is that the most costly pitfalls are also the most common and the most documented. Organisations that understand where compliance risk concentrates can take targeted steps to eliminate the gaps that vendors exploit — without embarking on an expensive SAM tooling overhaul that takes two years to deliver results.

Pitfall 1: Misunderstanding Virtualisation Licensing Rules

Virtualisation is the single most common source of material software licence compliance gaps in enterprise environments. Oracle and IBM are the two vendors where virtualisation licensing errors produce the largest financial exposures.

Oracle's licensing in virtualised environments is governed by the distinction between hard partitioning and soft partitioning. Hard partitioning — using physical domains, LPARs with hard partition settings, or Oracle VM — is accepted by Oracle as a means of limiting the processor count that must be licensed. Soft partitioning — using VMware, Hyper-V, or other hypervisors without hard partition controls — is not. Oracle's position is that in a soft-partitioned environment, the entire physical server's processor count must be licensed, regardless of which processors the virtual machine is actually running on. An organisation that has deployed Oracle Database on a VMware cluster and licensed only the VMs, rather than the physical hosts, is potentially undercounting its Oracle processor licence requirement by a factor of four to ten times.

For IBM: sub-capacity licensing allows organisations to license IBM software based on the PVU or VPC value of the virtual machine rather than the physical server. However, this approach is only valid if IBM License Metric Tool (ILMT) is correctly deployed and reporting within 90 days of installing the IBM software. Many organisations run IBM software on virtualised infrastructure and claim sub-capacity licensing without having properly configured ILMT. In an IBM audit, sub-capacity claims without valid ILMT data are rejected, and the full physical server capacity becomes the licence requirement. This ILMT gap is one of the most consistently exploited compliance weaknesses in IBM's audit programme, and it affects organisations of all sizes that have deployed IBM middleware, Db2, or Cloud Pak components on virtualised infrastructure.

Pitfall 2: Shadow IT and Decentralised SaaS Purchasing

IT now controls only 15 percent of SaaS spend and 13 percent of application ownership in the average enterprise, according to Zylo research. The remaining 85 percent of SaaS spending happens across business units, individual teams, and departmental budgets — without central visibility, without licence compliance review, and frequently without any connection to the organisation's vendor relationship management. The result is a shadow IT estate that represents both financial waste and compliance exposure.

The compliance risk from shadow IT is not always obvious. Some SaaS applications are adopted without reviewing the vendor's terms of service for organisational deployment, creating non-compliance with fair use provisions. Others are adopted by multiple teams simultaneously, creating functional duplicates that add cost without adding capability and that may each have different and incompatible contractual terms. Still others are adopted by employees who leave the organisation, leaving active accounts — and active subscription charges — attached to dormant credentials.

The practical response for organisations of all sizes is to implement a minimal SaaS intake process: a lightweight review that captures the application name, business owner, number of users, cost, and confirmation that the vendor's terms permit the intended use. This does not require enterprise SAM tooling — a simple shared register maintained by IT or finance catches the most significant shadow IT risks without imposing a bureaucratic burden that business units will route around.

Pitfall 3: Microsoft EA Changes Affecting Smaller Organisations

Effective November 2025, Microsoft eliminated volume-based discounts for Online Services under Enterprise Agreements for organisations with fewer than 2,400 users, actively directing these organisations toward the Cloud Solution Provider (CSP) model instead. For mid-sized organisations that have historically relied on EA pricing for Microsoft 365, Azure, and Dynamics 365, this change represents a material pricing increase that was not anticipated in existing renewal budgets.

Organisations affected by this change face a specific pitfall: many are renewing existing EAs without understanding that the commercial landscape has shifted beneath them. The EA may still be technically available, but the pricing is no longer optimised for organisations below the 2,400-user threshold. CSP agreements — delivered through Microsoft's partner channel — offer a different commercial model with different flexibility and protection characteristics. Understanding which model is appropriate for your specific situation, usage profile, and growth trajectory requires commercial analysis that most IT teams are not resourced to perform independently. The pitfall is signing an EA renewal at disadvantageous terms when a CSP transition would have been commercially superior.

SAP Indirect Access

SAP's indirect access licensing framework is another pitfall that has caught organisations of all sizes off guard. Indirect access occurs when a non-SAP application — a custom application, a third-party platform, or an integration layer — queries SAP data through an API or interface. SAP's position is that each user accessing SAP data indirectly through such integrations requires an appropriate SAP named user licence, regardless of whether they interact directly with the SAP user interface.

This licensing requirement is frequently overlooked when organisations deploy digital transformation projects, e-commerce platforms, or data analytics tools that integrate with their SAP ERP system. The compliance gap can be substantial: an e-commerce platform serving thousands of daily customers that retrieves product, pricing, or inventory data from SAP may represent a requirement for thousands of SAP indirect access licences that the organisation has never purchased. SAP's audit programme has specifically focused on indirect access in recent years, and settlements — while often negotiated to a fraction of the theoretical exposure — regularly reach seven figures for mid-sized and large organisations.

Pitfall 4: Mismanaging Cloud Licence Transitions

Cloud migration creates a specific class of licensing pitfall that many organisations discover only after incurring the cost. On-premises software licences are not automatically valid in cloud environments. Microsoft's licence terms for Azure use rights, Oracle's Cloud@Customer policies, and IBM's cloud deployment requirements all have specific rules governing whether existing on-premises licences can be used in cloud or hybrid cloud environments — and under what conditions.

A common scenario: an organisation migrates a workload running Oracle Database from an on-premises server to an AWS EC2 instance, assuming that its existing Oracle processor licences transfer automatically. Oracle's Licence and Service Agreement does not permit deployment in public cloud environments such as AWS, Azure, or Google Cloud without specific authorised cloud deployment terms — either through Oracle's own cloud (which qualifies as hard partitioning) or through specific licensing arrangements that Oracle has negotiated with some hyperscalers. The organisation that has migrated an Oracle workload to AWS without addressing this is non-compliant from day one of the cloud deployment.

The reverse scenario is equally common: an organisation that has purchased cloud consumption credits or subscriptions for a vendor's SaaS platform continues to maintain and pay for on-premises licences that cover the same functionality, paying twice for the same capability during a transition period that extends far longer than planned. A structured licence rationalisation review at the beginning of every cloud migration programme — before commitments are made on either side — prevents this double-spend.

Pitfall 5: Inadequate Renewal Preparation

Renewal is the moment at which software vendors hold the most leverage, and organisations that have not prepared adequately — with usage data, competitive alternatives, and a clear understanding of their contractual entitlements — consistently overpay relative to peers who have invested in renewal preparation. The pitfall is not merely paying too much at renewal; it is also accepting unfavourable contractual terms that create compliance risk and reduce flexibility for the next three to five years.

Common renewal pitfalls include: accepting auto-renewal clauses that trigger without adequate notice of commercial terms; agreeing to minimum commitment increases without validating that usage data supports the higher entitlement; signing multi-year agreements without price stability clauses, leaving the organisation exposed to annual price increases that were not anticipated in the business case; and failing to negotiate audit protection provisions — such as a right to cure compliance gaps before financial penalties are applied — that significantly reduce the financial impact of any future audit finding.

The foundation of effective renewal management is a 90-day lead time standard applied consistently to every major vendor contract. Starting the renewal process 90 days before expiry — with a current licence position, usage data, and a competitive market reference — gives procurement teams sufficient time to negotiate rather than simply accept the vendor's opening position.

Staying Compliant: A Practical Framework for Any Size Organisation

The compliance framework that works for a 50,000-person enterprise is not practical for a 500-person mid-market company. But the principles are the same, and they scale. First: maintain a complete, current record of what you have bought. A spreadsheet listing every active software agreement — vendor, product, licence metric, seat count, renewal date, and cost — is the starting point for any compliance programme, regardless of organisation size. Second: understand the deployment rules for your three to five most expensive and highest-risk vendors. The virtualisation rules for Oracle and IBM, the indirect access framework for SAP, and the cloud use rights for Microsoft are not negotiable — they apply regardless of whether you have read them. Third: conduct a usage review before every major renewal. Comparing licences purchased to active deployments before renewing consistently identifies savings opportunities and eliminates the risk of renewing surplus capacity. Fourth: establish a renewal calendar with 90-day advance notification for all contracts above a defined spend threshold. Surprises at renewal are the result of inadequate planning, not vendor aggression.