Software Shelfware Audit:
Identify Unused Licences, Calculate ROI & Reclaim Spend

What Is Software Shelfware and Why Does It Persist?

A software shelfware identification audit is the process of systematically mapping every licence your organisation owns against measurable usage data — then calculating the financial and contractual implications of the gap. The term "shelfware" covers two distinct problems: products that were procured but never deployed at all, and products that are deployed but used so infrequently that they contribute near-zero business value. In a mature enterprise with 50 or more software vendors, it is routine to find that 25–35% of total licence spend falls into one of these two categories.

Shelfware persists for structural reasons, not careless ones. Procurement cycles operate on multi-year timelines, while business requirements shift quarterly. An Oracle Database Enterprise Edition licence provisioned for a project in 2021 may have been surpassed by a cloud-native alternative before the contract even reached its first renewal. The licence remains active and billable, but the business case that justified it has dissolved. Similarly, SAP user licences procured during an ERP rollout often reflect peak onboarding headcount rather than steady-state usage — creating a permanent overhang that vendors rarely volunteer to correct. The software asset management function is the natural owner of this problem, but without dedicated tooling and defined ownership, the inventory drifts and the waste compounds annually.

There is also an organisational dimension. Business units that procure their own SaaS tools frequently duplicate functionality that already exists in enterprise agreements. A finance team subscribing directly to a BI tool, when Microsoft Power BI is already included in an existing M365 E5 licence, represents shelfware in both directions: the enterprise licence goes unused and the duplicate SaaS subscription generates unnecessary spend. Identifying this requires cross-departmental visibility that most IT and procurement teams simply do not have without a structured audit programme.

Running a Software Shelfware Identification Audit: The Discovery Phase

The discovery phase of a software shelfware identification audit has three parallel workstreams: endpoint discovery, entitlement reconciliation, and usage telemetry. Endpoint discovery identifies what is actually installed across the estate — not what procurement believes is installed. The gap between these two views is frequently significant, particularly for desktop software, development tools, and security products where shadow IT deployment is common. Tools reviewed in our SAM tool market guide 2026 vary considerably in their discovery depth, particularly for non-Windows endpoints and containerised environments.

Entitlement reconciliation maps your contractual rights against the installed base. This requires pulling licence entitlement data from contracts, purchase orders, and vendor portals — sources that are rarely consolidated in a single system. The output is a raw licence position that shows, for each product, how many units you are entitled to use versus how many are deployed. A positive gap (more entitlements than deployments) is the starting point for shelfware reclamation, but it is not yet sufficient evidence for a reduction conversation with a vendor. That requires usage telemetry.

Usage telemetry is the most technically demanding workstream and the one most organisations underinvest in. Login frequency data from identity providers shows who is accessing a system, but it does not distinguish active use from automated service account activity. Feature-level usage data — which functions within a product are actually being used, and by how many users — is what actually moves a vendor negotiation. SAP, Salesforce, and ServiceNow all provide native usage reporting at varying levels of granularity; Oracle and IBM typically do not, requiring third-party tooling or manual log analysis. Collecting 6–18 months of telemetry before initiating any vendor conversation is the standard Redress recommendation: it establishes a defensible baseline and prevents vendors from arguing that low usage in a snapshot period reflects a temporary anomaly rather than a structural pattern. The full discovery methodology is covered in our guide to running an internal software audit.

Usage Thresholds by Vendor — What "Zero" Actually Means

Every vendor defines active use differently, and those definitions matter because they determine what evidence is needed to justify a licence reduction. For Microsoft, a user who has not logged into an M365 application in 30 days is typically classified as inactive, but some contract language requires 90-day inactivity to trigger a downgrade right. For Salesforce, a named user licence is consumed the moment it is provisioned in the org — whether or not the user ever logs in — so reducing Salesforce spend requires not just identifying low-usage accounts but formally deprovisioning them before the renewal date. Oracle takes the most conservative position of any major vendor: a database licence is considered fully utilised if it is deployed on a physical or virtual server, regardless of workload — meaning usage data is frequently irrelevant for Oracle database licence reduction and the conversation must focus instead on architecture changes such as server right-sizing, virtualisation policy revisions, or workload consolidation.

SAP's indirect access and digital access model introduces a further complication: usage thresholds are not just about named users. Any third-party system that reads from or writes to SAP — an e-commerce platform, an RPA process, a middleware integration — consumes digital access licence capacity. A shelfware audit that focuses only on named users will miss this exposure entirely, and may actually conclude that a licence reduction is possible when the hidden digital access usage would justify a true-up instead. This is why the software licence position document produced at the end of a shelfware audit must capture both dimensions: named user positions and indirect access positions, reconciled to current contractual entitlements.

For SaaS vendors — Workday, ServiceNow, Salesforce, and the growing roster of AI-augmented platforms — usage thresholds are evolving rapidly as vendors move from per-user to consumption-based or outcome-based pricing. A shelfware audit in a SaaS-heavy environment needs to capture not just who is using what, but whether the consumption model itself remains appropriate for the organisation's actual usage pattern. A Workday deployment with 3,000 provisioned HCM users but an active headcount of 2,100 is a straightforward shelfware case; a ServiceNow deployment where 60% of consumption is driven by automated workflows rather than human users may require a fundamental renegotiation of the pricing model itself, not merely a seat reduction.

Building the Business Case for Licence Reduction

The internal business case for a shelfware reduction programme needs to answer three questions that finance and procurement leadership will invariably ask: how certain is the identified saving, what is the contractual pathway to realising it, and what is the risk of vendor retaliation in the form of a compliance audit? The first question is answered by the quality of the usage data. If you have 12 months of telemetry showing 40% of Salesforce licences with fewer than two logins per month, the saving is high-confidence. If you have only a 30-day snapshot taken during a holiday period, the data will not survive a vendor challenge.

The contractual pathway question requires a careful reading of the licence agreement. Most enterprise software contracts allow licence reductions only at the point of renewal, and some include minimum volume commitments or true-up obligations that must be discharged before a reduction can take effect. Understanding the timing constraints is as important as identifying the quantum of waste: a £1.2M saving that cannot be realised for 18 months because of a contract lock-in period needs to be built into the programme timeline from the outset. The evidence base gathered during a shelfware audit also forms the foundation for any formal vendor audit dispute — if the vendor attempts to claim entitlement to a true-up at the same time as you are seeking a reduction, having a pre-prepared licence position document is the difference between a managed negotiation and a reactive defence.

The audit retaliation risk is real but manageable. Vendors that receive a licence reduction request from a customer without prior warning are more likely to respond with a compliance audit than vendors that receive the same request as part of a structured renewal conversation. The timing and framing of a reduction request matters as much as the underlying data. Presenting a reduction as a right-sizing exercise tied to a future workload commitment — "we are reducing today's deployment to match current usage, and we will scale the contract back up as the planned migration completes" — is a fundamentally different conversation from presenting it as a straight cost-cutting measure with no forward commitment. Redress advisors work through our enterprise licensing white papers to prepare clients for both scenarios before they enter any vendor conversation.

Approaching Vendors at Renewal Without Tipping Your Hand

The most common mistake organisations make when they have completed a shelfware audit is approaching the vendor too early and with too much transparency about the internal findings. Sharing your full usage data with a vendor account team before commercial terms have been agreed hands the vendor an information advantage they will use against you. The account team's incentive is to defend revenue, and the first response to a customer sharing evidence of low usage is typically not a proactive offer of a reduced contract — it is a review of whether the deployment is fully compliant, followed by a conversation about expanding usage to fill the deployed capacity. This is the vendor playbook, and it works repeatedly on procurement teams that present their cards too early.

The Redress approach is to structure the conversation in phases. In the first phase, which should begin 9–12 months before renewal, the focus is on understanding the vendor's forward roadmap and pricing intentions without disclosing internal usage data. This phase establishes whether the vendor is planning price increases, product consolidations, or commercial model changes that affect the value of the current contract. In the second phase — typically 6 months before renewal — the organisation presents its high-level assessment of deployment versus entitlement, framed as a right-sizing proposal rather than a dispute. The third phase is the formal commercial negotiation, backed by the full licence position document and supported, where necessary, by independent advisory from Redress to validate the technical and commercial arguments. This phased approach consistently produces better outcomes than a single-point negotiation because it denies the vendor the opportunity to mount a coordinated counter-response before the commercial conversation begins.