The average mid-market team pays for 11 tools it forgot it bought. Here is a methodology for auditing your software stack — and the criteria for what stays.

Software subscription management is one of the most reliably neglected operational disciplines at companies under 500 employees. Unlike a capital expenditure, a $400/month SaaS subscription requires no approval after the initial purchase, appears in the general ledger as a single line item that is rarely reviewed at the category level, and auto-renews by default.

The result: most mid-market companies are paying for software that is unused, underused, or redundant with software they already have. The number is not small.

A 2024 survey by Zylo, which manages SaaS spend for enterprise clients, found that organizations use an average of 65% of the SaaS licenses they purchase. For mid-market companies, the unused license rate is typically higher — and the discovery process is often more surprising — because purchasing decisions are more decentralized and less governed.

This article is a methodology for conducting a SaaS stack audit: what to collect, how to evaluate it, and how to make defensible cut decisions.

Phase 1: Discovery

The goal of discovery is a complete list of every software subscription the company is paying for, regardless of department.

Start with finance, not IT. The most complete record of software subscriptions is your credit card and bank statements, not your IT asset register. Pull 18 months of statements and flag every recurring charge from a software vendor. You will find subscriptions that no one in IT knows about.

Interview department heads. Ask each department head: “What software does your team use that we pay for, either on the company card or expense reimbursed?” You will learn about tools purchased at the departmental level that are not in any central register.

Check your email for vendor notifications. Renewal notices, usage summaries, and billing confirmations land in someone’s inbox. Search for terms like “renewal,” “invoice,” “subscription confirmed,” “your plan,” and common vendor names.

The output: A spreadsheet with every subscription, monthly cost, annual cost, which department uses it, who the internal owner is, and contract renewal date.

This process typically takes one person three to five days and produces a list that is larger than anyone expected.

Phase 2: Usage Assessment

For each item on your list, assess actual usage. This is different from license allocation (how many seats you’re paying for) and different from self-reported usage (what people say they use).

For tools with admin consoles: Pull the last-90-day active user count from the admin dashboard. Compare it to the number of licenses you’re paying for.

For tools without usage dashboards: Survey the supposed users directly. “On a scale of 1–5, how frequently do you use [tool] in a typical week? What do you use it for?”

For tools with single owners: Ask the owner: “If we cancelled this tomorrow, what would you lose? Is there anything else in our stack that could do that?”

Classify each tool into one of four categories:

  1. Core: Used regularly by most intended users, no redundancy
  2. Specialized: Used regularly by a subset of users for a specific use case with no substitute
  3. Marginal: Paid for but used infrequently or by fewer than half the intended users
  4. Shadow: Paid for but no active use or the use case is already covered by another tool

Phase 3: The Cut Criteria

Tools in the Marginal and Shadow categories are cut candidates. Apply this framework:

For Shadow tools: Cancel. There is no business case for paying for software that isn’t being used.

For Marginal tools: Ask three questions:

  1. Is the use case valid? (Is someone doing something real with this tool, even if infrequently?)
  2. Is there a lower-cost option that covers the same use case? (Could this be replaced by a feature in a tool you already own?)
  3. Is the usage pattern likely to change? (Is infrequent use a signal of low value, or a signal of a cyclical use case?)

If the use case is valid, there is no cheaper alternative, and the usage pattern reflects genuine if infrequent need — keep it. Otherwise, cancel.

For tools with overlap: When two tools in your stack cover similar use cases, the question is not “which one do we like better” but “which one is more deeply integrated into existing workflows and would be more expensive to remove.” The more embedded tool typically wins, not the better-designed one. This is usually the right call.

The Contracts Question

Discovery frequently surfaces tools under annual or multi-year contracts that cannot be cancelled immediately. Flag these separately: they are costs you will incur regardless of your audit decisions, but they define your next renewal decision date, not your current usage policy.

For tools under contract that you have decided not to renew, set a calendar reminder 90 days before the contract end date. Most SaaS auto-renewal clauses require 30–60 days notice for cancellation. Missing that window typically means paying for another year.

The Output

A completed stack audit produces:

  • Immediate cancellations (Shadow category and Marginal tools with no valid use case)
  • Downgrades (tools where you’re paying for more licenses than you use)
  • Non-renewal decisions (tools under contract that you’ll exit at renewal)
  • Consolidation decisions (redundant tools where you’ll standardize on one)

For a 50-person company, a thorough stack audit typically identifies 15–25% of SaaS spend as immediately reducible. The operational benefit — reduced tool sprawl, fewer integration points, simpler onboarding — is often as valuable as the cost savings.