The 15-Point Software Audit Checklist for 20-to-200-Person Companies

Most growing companies do not have a software-spend problem because they bought the wrong tool. They have a decision-system problem: no one owns the evidence required to keep, change, downgrade, or retire a subscription.

That distinction matters. A useful audit should not begin with a target percentage or a list of replacements. It should produce a defensible finding for each meaningful cost: what is being paid for, who relies on it, what would break if it changed, and whether the saving remains after transition and support costs.

Use this checklist annually and ahead of every major renewal. It is designed for companies with roughly 20 to 200 employees, where tool sprawl can emerge faster than procurement discipline.

Start with a rule: protect the work before reducing the spend

A cheaper product is not automatically a better decision. Keep a tool when it is genuinely used, protects a critical workflow, has a clear owner, and would cost more to replace than to retain.

For every proposed change, calculate:

Annual net saving = verified reducible cost + approved labor reduction − implementation cost − migration cost − ongoing support cost − credible reversal risk

Only treat the result as a saving when the evidence is sufficient for the owner, finance, and affected team to act on it. This is the same discipline behind our keep, cancel, or swap framework.

1. Build one complete subscription register

Pull card transactions, invoices, expense claims, procurement records, and team-owned renewals into one list. Record vendor, product, entity, renewal date, contract owner, billing owner, total annual cost, and payment method.

The first finding is often not a cancellation. It is an unowned renewal or a payment route that hides the true cost.

2. Compare paid seats with assigned seats

For each seat-based product, compare invoices with the current identity directory and administrator seat list. Flag licenses that are paid for but unassigned, duplicate identities, or held by former employees.

Do not remove access until a functional owner confirms that a shared workflow will not be interrupted.

3. Check recent activity, not just login status

An assigned seat is not necessarily an active one. Review meaningful product activity over an agreed period, usually 60 to 90 days, alongside manager confirmation. A rare but essential user should be documented as an exception rather than treated as waste.

4. Reconcile offboarding against SaaS access

Compare the HR departure list with each major SaaS administrator list. This catches subscriptions still attached to departed employees, paid personal accounts, and handovers that were never completed.

Make this a monthly control after the audit. It is much cheaper than rediscovering the same issue at renewal.

5. Put every renewal on a calendar with an accountable owner

Capture notice periods, auto-renewal terms, price-lock dates, and negotiation windows. A renewal calendar should trigger a review early enough to change scope before contractual leverage disappears.

The owner does not need to run procurement. They do need to confirm whether the tool is still required and who will supply the usage evidence.

6. Match plan tier to actual requirements

List the features that justify a premium tier, then ask the users who depend on each one. If the answer is vague, test whether a lower tier, a smaller workspace, or a different billing model would preserve the workflow.

Avoid an immediate downgrade where a feature is tied to security, compliance, customer commitments, or a production process.

7. Separate core licenses from optional add-ons

Review storage, analytics, AI credits, support packages, phone numbers, security modules, sandbox environments, and other add-ons independently. They are often bought at a point in time and never revisited.

The right decision may be to retain the platform and remove a narrow add-on.

8. Identify duplicate capabilities across the stack

Map tools by job to be done: CRM, support, project management, document signing, reporting, automation, knowledge base, scheduling, and internal apps. 2 products with overlapping labels are not necessarily duplicates. Compare the specific workflow, data ownership, integrations, and user groups.

Treat potential consolidation as a research question until the teams agree on a viable destination.

9. Find the work being entered twice

Ask each function where the same client, employee, project, or transaction data is copied between systems. Repeated entry can be a cost issue, but it may also reveal a reporting-control or data-quality risk.

Document the workflow before proposing automation. A bad process automated faster is still a bad process.

10. Test whether reports are assembled manually

If a recurring management, finance, sales, or operations report depends on copying data into spreadsheets, record the frequency, people involved, error correction, and decision it supports. Then compare a process change, a native report, an integration, and a targeted automation.

Count labor reduction only when the responsible leader agrees that the time can actually be redeployed or removed.

11. Review integrations for unnoticed failure and avoidable cost

List paid automation, connector, and data-sync services. Check error queues, task volumes, duplicate flows, unused connections, and the person responsible for maintaining each one.

An inexpensive integration can still be costly if no one can safely support it. Include monitoring and ownership in the decision.

12. Challenge expensive automation only after understanding the workflow

When an automation platform has grown expensive, first map the triggers, systems, exceptions, and business impact. Alternatives may include simplifying the workflow, moving a stable process into an existing platform, or self-hosting an automation tool.

Self-hosting can reduce subscription cost, but only where there is a named technical owner, secure hosting, monitoring, backups, and a workable recovery plan.

13. Apply the same standard to internal-tool platforms

Low-code and internal-tool subscriptions should be assessed on total cost, not per-user price alone. Include the application owner, authentication, database dependencies, source control, support coverage, and the effort required to change course.

Keep the incumbent when it remains the lowest-risk way to support a business-critical internal application.

14. Review customer-support systems with service quality in view

Support platforms influence response time, customer history, routing, analytics, and team habits. Before consolidating or replacing one, define the service level that must be protected and identify the integrations and data that have to move.

A cheaper help desk is not a saving if it increases response workload or damages customer experience.

15. Treat email and marketing tools as data and deliverability decisions

For email platforms, inventory list size, sending volume, segmentation, automations, consent records, templates, and deliverability controls. Cost may be reducible through a plan change or cleaner list management, but any replacement must preserve compliance and sender reputation.

Do not approve a migration based only on subscription price.

Turn the checklist into decisions, not a savings spreadsheet

For each item, create a short finding with 5 fields:

1. Evidence: invoice, administrator export, usage data, workflow interview, or contract.
2. Decision: keep, cancel, downgrade, consolidate, renegotiate, or investigate.
3. Business owner: the person who can validate the operational impact.
4. Implementation and risk: dependencies, migration steps, support ownership, rollback plan, and timing.
5. Financial effect: one-time cost, recurring cost, and the basis for any claimed net saving.

This ledger makes it clear which changes are ready to execute, which require further evidence, and which are sensible to leave alone. It also prevents teams from adding together speculative estimates as though they were validated savings.

A practical 3-week audit rhythm

In the first week, build the register and collect contracts, invoices, seat data, and renewal dates. In the second, interview functional owners and test the largest findings. In the third, validate the financial effects, implementation requirements, and decision owners. Then turn approved changes into a renewal and execution plan.

The result should be a calmer, more accountable operating system for software spend, not an indiscriminate campaign to replace tools. A company that can explain why each major subscription stays or changes will usually make better renewal decisions long after the audit is complete.

This checklist is educational. Any potential saving depends on the company’s actual contracts, usage, implementation needs, and operating risk.