What a Software Audit Should Find Before Renewal

A software audit before renewal should do one thing very well: remove guesswork. Not every finding will lead to a saving, and that is fine. The real value is knowing which licences are needed, which are weakly justified, which terms carry risk, and which renewal choices are still open before the vendor conversation hardens.

For Salesforce, this matters because spend rarely sits in one neat line. It builds up through clouds, editions, add-ons, user types, support, integrations, historic projects, regional teams, and commercial terms agreed over several years. By the time renewal comes round, finance may see a single number, IT may see operational dependency, and procurement may see a negotiation deadline. A good audit gives all three the same map.

The job of a software audit is to reduce uncertainty

A weak audit asks, “How many licences can we cut?” That question is too narrow and usually too late. A strong software audit asks, “What are we committed to, what are we actually using, what must change, and what can we credibly ask for at renewal?”

That shift matters. Cutting visible waste is useful, but the larger value often comes from avoiding a poor commitment for the next term. A renewal can lock in excess capacity, weak flexibility, price increases, product mismatches, or terms that make future change expensive.

The same discipline appears in other parts of business spend. Energy decisions, for example, are not only about paying the current bill. Firms need to understand usage, constraints, regulation, grants, and future demand. Independent advisers such as REE help businesses bring that evidence together before committing money. Software spend deserves the same level of practical scrutiny before renewal.

A useful audit should answer five questions clearly:

• What do we own, and under which contract terms?
• What is assigned, active, dormant, duplicated, or mis-tiered?
• Which licences and SKUs are tied to real business processes?
• Which renewal clauses or vendor timelines reduce our options?
• What negotiation position can we defend with evidence?

If the audit cannot answer those questions, it is not yet renewal-ready.

1. A clean contract and SKU baseline

The first finding should be a reliable baseline. This sounds basic, but it is where many renewals start to drift. Order forms, amendments, side letters, support terms, renewal notices, pricing schedules, and historic concessions often sit in different folders or inboxes. Sometimes the buying team has changed. Sometimes the original business case has disappeared.

The audit should identify every active SKU, quantity, contract end date, billing frequency, committed spend, unit rate, discount structure, renewal notice period, and any uplift language. It should also separate what is contractual from what is merely assumed. Verbal assurances, old emails, and account team comments are not the same as binding terms.

For Salesforce, this baseline also needs licence type clarity. Access is shaped by user licences, feature licences, permission sets, add-ons, and product-specific entitlements. Salesforce’s own help pages on available licence types are a useful reminder that not all access rights behave the same way. That distinction matters when you decide whether a user is genuinely over-licensed or simply configured incorrectly.

This is also the point to look for contractual mechanics that will affect the renewal path. Auto-renewal windows, price uplift caps, minimum quantities, co-terming rules, swap rights, and termination notice deadlines should be visible before any commercial conversation begins. If the contract itself is unclear, it is worth reviewing how to read a software contract before it costs you before moving into negotiation.

2. Usage that separates access from value

A login report is not a usage audit. It is one input.

Someone may log in daily and use only a small slice of the capability they are licensed for. Another user may log in rarely but run a business-critical approval process, integration, or month-end task. A licence may be assigned because a manager asked for it two years ago, not because the role still needs it today.

The audit should separate assignment, activity, role fit, and value. For Salesforce, that means reviewing user status, last login, permission patterns, assigned products, functional role, region, department, and use of relevant features where data is available. It also means distinguishing human users from integration users or admin accounts, because removing the wrong access can break more than a budget line.

Audit finding	What it may mean	Renewal action
Unassigned licences	Paid capacity is sitting unused	Remove, reallocate, or use as negotiation evidence
Assigned but inactive users	Access may be historic, duplicate, or no longer needed	Validate with line managers before reducing
Active users on high-tier licences	Users may need the licence, or may be over-licensed	Compare activity with role and required capability
Add-ons with low adoption	Project scope may have changed after purchase	Decide whether to renew, exchange, or phase down
Integration or admin accounts	Low login activity may still be operationally important	Review technically before making changes

The point is not to catch people out. It is to avoid paying for a shape of organisation that no longer exists.

3. Licence fit, not just licence count

A renewal can look healthy at the surface because most licences are assigned. That does not mean the estate is right-sized.

Licence fit asks whether each user has the correct level of access for the work they actually perform. This is where CFOs, CIOs, and procurement teams often find more useful evidence than in raw headcount cuts. A team might need Salesforce, but not every member may need the same edition, add-on, or level of capability. A department may have inherited licences from a project that has since narrowed. A small group may hold premium access because it was easier to buy one standard bundle than design a cleaner entitlement model.

The audit should find mismatches between user roles and licence levels. It should also identify where process design has forced expensive access. For example, if many light users need full access only to approve, view, or update a limited set of records, the renewal question is not only commercial. It may also be architectural or operational.

This is where IT and procurement need to work together. Procurement can challenge the commercial shape, but IT must confirm whether a lower-cost option is technically workable. Finance can push for reduction, but only after the business impact is understood.

4. Shelfware hidden in add-ons, bundles, and old projects

Shelfware is rarely announced. It hides in polite places: an add-on bought for a transformation programme, a bundle that looked efficient at the time, licences held for a hiring plan that slowed down, or products kept because nobody wants to revisit the original decision.

A software audit should name shelfware without blame. Most unused software has a history. Someone bought it for a reason. The business then changed, adoption lagged, a project paused, or ownership moved. The question is not who made a bad call. The question is whether the next contract should continue funding the old assumption.

The audit should identify shelfware by SKU, quantity, owner, age, original business case where known, current usage, and renewal recommendation. It should also distinguish recoverable shelfware from dead shelfware. Some licences may be redeployed with better governance. Others should simply be removed from the renewal position.

If this is a recurring issue, the broader pattern is worth addressing. SaaS shelfware often points to weak intake controls, unclear ownership, or renewals that happen faster than the business can challenge demand.

5. Commercial terms that set the trap early

Many renewal risks are not hidden in usage data. They are hidden in timing and wording.

A proper audit should find the clauses that change your negotiating room. Notice periods can close options before the renewal project has even started. Auto-renewal language can turn delay into acceptance. Uplift terms can normalise increases that were never re-tested. Minimum commitments can make reductions harder than expected. Co-terming can simplify administration while quietly pulling smaller purchases into a larger renewal event.

This is why renewal work needs to start earlier than many teams expect. If a strategic platform is material to operations and spend, a review three or four weeks before signature is not a review. It is damage control. For larger Salesforce estates, the audit should begin while there is still time to validate usage, speak to business owners, test alternatives, and prepare a credible position. If timing is already tight, the list of software renewals that need attention earlier than you think is a useful way to prioritise where to act first.

The audit output should include a commercial risk log. Keep it simple. Clause, risk, impact, owner, action. That is enough to stop important points being buried in a contract folder.

6. Real demand for the next term

A renewal should not be built on last year’s licence count plus a margin for comfort. It should be built on current evidence and realistic demand.

The audit should test what the organisation actually needs for the next term. That includes confirmed hiring, planned reductions, business unit changes, product rollouts, decommissioning plans, integration changes, and process redesign. It should also challenge aspirational demand. “We might use it next year” is not the same as funded, owned, scheduled adoption.

Good demand testing is direct. Ask each business owner what must stay, what can reduce, what is missing, and what they would stop paying for if the cost sat visibly in their budget. That last question often changes the conversation.

The audit should also show demand confidence. Some requirements are firm. Some are probable. Some are speculative. Treating all three as equal is how organisations overbuy.

7. Dependencies that make reduction risky

Not every unused-looking licence is safe to remove. A strong audit should find operational dependencies before someone makes a tidy but damaging cut.

This is especially true in Salesforce environments, where access can support workflows, reporting, integrations, managed packages, automations, data quality processes, and service operations. A user with low apparent activity may own scheduled jobs, integration credentials, or reports used by senior teams. An add-on with low adoption may still support a regulated process or customer-facing workflow.

The audit should flag these dependencies clearly. It does not need to solve every technical design issue before renewal, but it must stop the business from treating all low-usage items as equal. Licence reduction should be safe, not theatrical.

A practical dependency check should include system owners, Salesforce administrators, security leads, integration owners, and the business process owners who understand what happens when access changes. The outcome is not simply “keep” or “cut”. Sometimes it is “keep for now, redesign before next renewal”. That is still valuable.

8. Negotiation leverage the audit should create

A software audit should lead to a negotiation brief, not just a spreadsheet. Vendors respond better to evidence than to vague pressure. They may not agree with every conclusion, but a well-supported position changes the tone of the conversation.

The audit should produce clear renewal scenarios. One scenario may show the cost of renewing as-is. Another may show a right-sized estate based on validated usage. A third may show a compromise, for example retaining critical products while reducing weakly adopted add-ons or changing the commercial structure.

The strongest negotiation points are usually specific. “We have 180 licences assigned to users with no login in 120 days” is stronger than “We think we have waste.” “This add-on was purchased for a project that has been cancelled” is stronger than “Adoption is low.” “These terms restrict flexibility after the merger” is stronger than “We need a better deal.”

This is not about being combative. It is about entering the renewal with enough evidence to avoid being steered by the vendor’s timeline alone.

9. Clear ownership for the decision

A final finding often gets overlooked: who owns the decision?

Renewals drift when finance owns the budget, IT owns the platform, procurement owns the process, and business units own the demand, but nobody owns the trade-offs. A good audit should make those trade-offs visible and assign decisions to the right people.

Audit output	Primary owner	Decision it supports
Contract and SKU baseline	Procurement	What are we committed to today?
Usage and entitlement analysis	IT and system owners	What is actually needed?
Demand validation	Business owners	What will we need next term?
Commercial risk log	Procurement and finance	What terms must be challenged?
Renewal scenarios	CFO, CIO, procurement lead	What position do we take to the vendor?

The audit should end with decisions, not open questions. Keep, reduce, exchange, redesign, negotiate, or defer. If an item cannot be decided, the audit should state what evidence is missing and who must provide it.

What the final audit pack should contain

A renewal-ready audit pack does not need to be long. In fact, if it is too long, it often fails. Senior stakeholders need the conclusion. Specialists need the evidence. Both should be available.

A useful final pack usually contains an executive summary, a contract baseline, a SKU and licence analysis, a usage evidence appendix, a shelfware register, a commercial risk log, demand assumptions, and renewal scenarios. It should also include a short negotiation brief that states the preferred outcome, fallback position, and non-negotiables.

The best test is simple: could someone who was not involved in the audit read the pack and understand the renewal choice within 20 minutes? If not, the audit may be thorough, but it is not yet useful.

Frequently Asked Questions

When should a software audit start before renewal? For strategic platforms such as Salesforce, start several months before renewal, and earlier if the contract is large, complex, or business-critical. The audit needs enough time for contract review, usage validation, stakeholder challenge, and negotiation preparation.

Is a software audit mainly about cutting licences? No. Licence reduction is only one possible outcome. A good audit should also find mis-tiered users, weak contract terms, risky dependencies, unused add-ons, unclear demand, and negotiation leverage.

Who should own the audit? Procurement should usually coordinate the process, but it cannot own the evidence alone. IT must validate usage and technical dependency, finance must test spend and risk, and business owners must confirm demand.

What makes Salesforce audits harder than general SaaS audits? Salesforce estates often include multiple clouds, user types, add-ons, integrations, permission structures, and historic commercial changes. That makes it important to review both contractual entitlement and operational use.

What if every business owner says they need everything? Ask for evidence. Which process depends on it? Which users need it? What happens if it is removed? Is the demand funded and scheduled, or only possible? The audit should turn preference into evidence-based demand.

Bring evidence to the renewal table

A renewal is a decision, not a date. The earlier you know what is used, what is wasted, what is risky, and what is negotiable, the less you have to rely on instinct when the vendor timeline tightens.

SaaSed helps organisations review Salesforce contracts, SKUs, usage, shelfware, and renewal risk before negotiation begins. If you want a calm, evidence-led view of your Salesforce position, book a complimentary Salesforce audit conversation.