A business is about to be acquired, or is itself acquiring another. The buyer's integration lead asks a simple question: which of the software we pay for is actually used? The answer takes weeks. The finance team can see the invoices. Nobody can say which modules, add-ons and premium tiers inside those invoices anyone has opened in the last year. The contract is one price for a bundle, so there is no line item to question.
This article covers that pattern: paying for software features that nobody uses because the vendor sold them together. It matters most when a merger, acquisition or restructuring forces a business to defend every line of its technology spend.
The problem in plain language
Software vendors commonly sell suites. A customer who needs invoicing also receives a reporting module, a workflow engine, an analytics add-on and a mobile app. A higher tier may be required to unlock one feature the business needs, and that tier carries five features it does not. The business agrees because the bundle is cheaper than buying the one feature alone, or because it is the only option offered.
Over time the original reason fades. Staff who asked for the extra features move on. The renewal arrives at roughly the same price, perhaps with an annual increase, and is approved because the system is clearly in use. What nobody checks is how much of the system is in use.
What the buyer is actually trying to solve
The finance director, COO or integration lead usually wants to answer three questions: what are we paying for, what are we using, and what would it cost to pay only for what we use. Before a transaction they also want to show a buyer or investor a clean software cost base. After one, they need to merge two sets of contracts without paying twice for the same capability.
Evidence and system mechanism
Licensing and SaaS management is its own discipline
The FinOps Foundation's Licensing and SaaS capability describes the aim as optimising the cost and value of licences and SaaS, minimising both over-deployment, which is a compliance risk, and under-deployment, described as shelfware or waste. It lists understanding contract terms, renewals, use rights and pricing options, and collaborating with engineering, finance, procurement and legal teams. In other words, the people who sign the contract, the people who use the product and the people who pay for it have to look at the same facts.
Centralised tracking and regular audits find the waste
The FinOps paper on SaaS cost management using the FOCUS billing specification recommends centralising licence management so that renewals can be tracked, and conducting regular audits to identify and terminate unused or underused licences. It also argues that consistent billing data across vendors makes analysis possible. The principle applies to a small business without any specification: one list of contracts, with the same fields for each.
Cost models expose drivers early
Microsoft's cost optimisation principles recommend building a cost model that segments expenses and forecasts total cost of ownership, including support and implementation, and assigning clear accountability for cost. A software contract with no named internal owner and no model of what it should cost is difficult to challenge. Related questions about renewals are explored in why software renewals need a confirmed business owner.
Warning signs
- An invoice shows one amount for a suite and nobody can list the modules included.
- Renewal is approved by the person who signs, not by the people who use the system.
- A premium tier is held for one feature that has since been replaced by another tool.
- Two departments pay for overlapping capabilities, as in departments buying overlapping software for the same capability.
- Nobody has compared the licence count with the number of active users in the last twelve months.
Problem owner and why-now trigger
The finance director or COO owns the cost, the procurement lead or office manager often holds the contract, and an application owner in the business knows how it is used. IT may own the technical configuration. Because no single person sees all four views, the bundle survives.
An acquisition or merger is the sharpest trigger. Due diligence asks for a schedule of contracts and costs, and the buyer's integration plan assumes that duplicate capability will be removed. A funding round, a restructuring or an exchange-rate move that raises dollar-priced subscriptions in Rand terms can have the same effect. A looming renewal with a price increase is the everyday version.
Economic consequence
Bundled shelfware is a permanent cost that grows with every increase. If a business pays R60,000 a month for a suite and uses two of its six modules, the unused portion is not only money; it is also support burden, user accounts to manage, data held in places nobody reviews and security exposure through features no one monitors. During a transaction, unexplained software spend lowers confidence in the cost base and can become a negotiating point. The recurring problem of money leaving quietly is also set out in unused software licences and financial waste.
Root cause
- Vendor packaging. The product is sold in tiers that bundle features, and the cheapest route to one feature includes many others.
- No usage data. The business has no regular view of which features are used, by whom.
- Contracts read once. Terms are negotiated at purchase and then filed; renewal dates and notice periods are noticed late.
- Diffuse ownership. Finance pays, IT configures and the users who requested a feature may have left.
Practical intervention
- List every contract once. For each, record the vendor, product and tier, price, billing period, renewal date, notice period and a named business owner.
- Break the bundle into features. Ask the vendor or read the order form to list what each tier includes, then mark each feature as used, partly used or unused.
- Gather usage evidence. Use the vendor's own admin reports, login and activity data, and a short question to the department: what do you use this for, and what happens if it is switched off?
- Price the alternatives. Ask for a lower tier, a modular quote or removal of add-ons at renewal, and compare it with a replacement for the single feature actually needed.
- Calendar the notice dates. Set reminders well before the cancellation or downgrade window closes, and place the decision with the business owner.
- Repeat before every renewal. Treat the review as a routine control, not a rescue exercise before a transaction.
Trade-offs
Downgrading can cost more if the vendor reprices the remaining features, and some bundles are genuinely cheaper than the parts. A feature that is unused today may be needed for a planned process change, so check the roadmap before removing it. The aim is an informed decision, not the smallest invoice.
An illustrative example
Illustrative: a Johannesburg professional services firm of about 120 staff was preparing for a sale. A review of its practice management suite showed it paid for a time recording module, a client portal and an analytics add-on, while staff recorded time in another tool and clients used email. At renewal the firm negotiated a lower tier without the portal and add-on, and presented the buyer with a contract schedule showing owner, usage and renewal date for each system.
Diagnostic questions
- For your five largest software contracts, can you list the modules included?
- Which of those modules has had no activity in the last twelve months?
- Who decides at renewal, and what evidence do they see?
- When is the last date to give notice of a downgrade for each contract?
- If you were acquired next quarter, could you produce a contract schedule within a week?
What good looks like
There is one contract register with an owner for every line. Each renewal is preceded by a usage review, and unused features are removed or negotiated down before the notice window closes. When a transaction comes, the answer to "what are you paying for and why" is already on one page. A broader approach to judging software on outcomes is described in why software portfolio decisions need business value, not only licence counts.
Where Mellorca fits
A digital systems audit can produce the contract, feature and usage register and show where capability overlaps. Digital systems architecture and roadmap work then helps decide what to keep, downgrade or consolidate, so the portfolio is rationalised on evidence.
Method note
The FinOps and Microsoft documents are general frameworks and do not describe any specific vendor's contract. The Rand figures and the example are illustrative rather than client data, and contract terms should be checked with a legal adviser.
Sources and further reading
- Licensing & SaaS FinOps Framework Capability (last verified 10 October 2026)
- FinOps for SaaS: Adopting FOCUS (last verified 10 October 2026)
- Cost Optimization design principles - Microsoft Azure Well-Architected Framework (last verified 10 October 2026)
Related Mellorca reading
- Applications are retained because migration effort is unknown
- Data-export limits are discovered only when leaving a vendor
- Why Application Costs Cannot Be Allocated to Business Units