How to Audit a Small Team's Software Spend (Without Starting a Fight)

Software spend at a small company rarely goes wrong through extravagance. It goes wrong through accumulation: a trial that converted, a tool bought for one project, a second app in a category that already had one. Nobody decided to waste the money. It just stopped being noticed.

What follows is a method for finding it. It is not a productivity philosophy and it does not require a procurement process — it is an afternoon with a list of invoices and one good question.

Step 1: build the list from invoices, not memory

Start from the payment side, not from what people say they use. Pull twelve months of charges from the company card statement, the bank feed and any app-store receipts, then reconcile them into a single sheet. Four columns is enough:

• Tool name and category
• Annual cost, normalised — multiply monthly charges by twelve so everything is comparable
• Billing cadence and renewal date
• Who bought it, and for what

Two things reliably surface at this stage before any judgement is applied: charges nobody in the room recognises, and two tools in the same category that were bought eight months apart by two different people.

If the person who bought a tool cannot be identified from the invoice alone, that is already a finding. Unowned software is unmaintained software.

Step 2: ask the one question that sorts the list

For each tool, ask: does anyone open this without being reminded to?

This question does most of the work of a full usage audit at a fraction of the effort. Tools people open voluntarily have found a real place in someone's day. Tools that need a ritual to stay alive — a weekly reminder, a manager asking whether people have updated it, a process document explaining when to use it — are being kept alive artificially.

A tool that needs a process to keep it in use is not a tool. It is a process, with a subscription attached.

Where a tool has real admin access, verify the answer rather than taking it: most business plans expose last-login or seat-activity data, and the gap between what people believe they use and what the logs show is frequently large.

Step 3: apply the categories that should not be judged on usage

Before cutting, ring-fence the exceptions. Some software earns its cost on the day you need it and looks idle every other day:

• Password management. Cancelling this does not remove the cost, it moves it into a spreadsheet of shared logins.
• Backups and disaster recovery. Usage is zero right up until it is the only thing that matters.
• Anything with a compliance or contractual obligation attached. Check before cutting, not after.
• The tools people spend hours in daily. An editor, a terminal, the primary design application. These deserve the most money and the least deliberation — a 20% productivity difference in a tool used six hours a day dwarfs the entire rest of the sheet.

Step 4: work through the predictable categories of waste

Across small teams the same patterns recur. Check the list against each:

Pattern	What it looks like	Usual outcome
The duplicate	Two document tools, two task trackers	Consolidate — split knowledge costs more than the licence
The absorbed feature	A point tool whose job the main platform now does natively	Cancel after confirming parity on the part you use
The dashboard nobody opens	Analytics or reporting add-on with no recurring viewer	Cancel; reinstate only with a named owner
The cold wiki	Knowledge base whose last meaningful edit is months old	Export first, then cancel
The over-tiered plan	Enterprise tier bought for one feature	Downgrade rather than cancel
The ghost seat	Licences for people who left	Immediate, uncontroversial saving

Ghost seats and over-tiering usually account for more of the total than dramatic cancellations do, and neither requires anyone to change how they work. Do those first — they buy goodwill for the harder conversations.

Step 5: cancel in the right order

• Ghost seats and tier downgrades — no behaviour change, immediate saving.
• Monthly plans — reversible next month if you were wrong. This is the cheapest place to be wrong.
• Annual plans approaching renewal — decide before the auto-renew date, not after.
• Annual plans mid-term — leave them. You have already paid; the decision belongs at the renewal date, and cancelling early buys nothing but disruption.

Export your data before cancelling, not during the cancellation flow. Several tools restrict export once a plan lapses, and a few restrict it the moment you initiate cancellation.

The traps

Annual plans hide death

A monthly subscription that stops being used generates twelve reminders that you are paying for it. An annual one generates one reminder, eleven months after the tool went cold. This is not an argument against annual billing — the discount is usually real — but it is an argument for a calendar entry ninety days before every annual renewal.

Migration cost is always higher than the estimate

Moving documentation or tickets between tools consistently takes longer than planned, and rarely because the export fails. It takes longer because a good chunk of the content turns out to be worth rewriting, and another chunk turns out to be worth deleting. Both are good outcomes. Neither is a two-hour job, and if the saving is small the migration may cost more than the subscription.

Some savings just move the work

Cancelling a transcription tool saves a small monthly fee and adds an hour a week of someone typing. Cancelling a scheduling tool saves a licence and adds a back-and-forth email thread to every meeting. Before recording a saving, ask where the work went. If the answer is "into somebody's evening", it is not a saving.

Someone loves the tool you are cancelling

This is the genuinely hard one, and it is not a spreadsheet problem. A workable rule: the person who wants to keep it explains what they would do instead. If the answer is concrete and clearly worse, keep the tool — they have just told you it is doing real work. If the answer is a shrug, the subscription was habit, and they will usually say so themselves once asked directly.

Expect to be wrong about one or two

Any honest audit produces a reversal — a tool cancelled, missed, and brought back within a couple of months. That is not a failed audit. It is the cost of finding out, and it is far cheaper than the alternative of never testing whether a subscription is load-bearing. Plan for it rather than treating a reinstatement as an embarrassment; teams that treat reversals as failures stop cancelling anything.

Step 6: make the next audit smaller

The habit that prevents the problem recurring is a review date set at purchase. Not a reminder to cancel — a date to ask the sorting question: is anyone opening this without being told to?

Ninety days is enough to know, and for most tools it falls inside the window where cancelling is still trivial. A team that does this consistently finds its annual audit shrinks to ghost seats and tier adjustments, which takes an hour rather than an afternoon.

The point of the exercise

The saving is worth having, but it is not really the payoff. The payoff is that at the end you have a documented, agreed list of what your team actually uses and who owns each piece of it. That list makes onboarding faster, makes the next purchase decision easier, and means the next time someone asks "do we already have something for this?", the answer takes ten seconds instead of a week. The finance side of that list has its own trade-offs — see invoicing and bookkeeping for small teams.