How to run a SaaS audit: a step-by-step review of your software stack

A SaaS audit has a reputation as a once-a-year ordeal: someone blocks out a week, chases forty people for answers, produces a spreadsheet, and everyone agrees it was useful before quietly letting it go out of date. By the following year the stack has changed enough that the exercise starts from scratch.

It does not have to work that way. A good audit is a repeatable process, not a heroic one-off, and most of the value comes from the first pass being thorough and the tenth pass being easy. This guide walks through how to run one end to end, and how to set a cadence so it never becomes a fire drill again.

Step one: gather every source of truth

No single system knows what your company runs on. Each source catches what the others miss, so the first job is to pull them all together before you try to make sense of any of them. Start here:

• Card and bank statements. Export at least twelve months so annual charges surface, and include every company card, not just the central account. This is the most reliable source, because everything you pay for has one thing in common: it gets paid.
• Single sign-on and identity logs. If you use SSO, the list of connected applications is effectively a list of the tools people log into, and the login dates tell you which ones nobody has opened in months.
• Expense reports and reimbursements. Subscriptions bought on personal cards and claimed back never touch the company card feed, so they hide here.
• Vendor and browser email. Search shared and finance inboxes for receipts, invoices, welcome messages and renewal notices. A saved bookmark or a shared password-manager entry counts too: it tells you a tool was adopted even if nobody remembers by whom.

The overlap between these sources is the point. A tool that appears on a card statement but not in SSO, or in an expense claim but nowhere else, is exactly the kind of unowned subscription an audit exists to catch. Our companion guide on finding software nobody owns goes deeper on where to look and how to run the discovery sweep.

Step two: build the register

Turn the raw list into one record per tool, in a single place. Resist the urge to capture everything you could know about each subscription; capture the handful of fields that will actually change a decision later. For each tool, record:

• The name people say out loud, and the vendor domain, which is what stops two spellings of one product becoming two rows
• What it is used for, and which team relies on it
• The annual cost, the billing cycle, and the number of seats you are billed for
• The renewal or expiry date, and whether it auto-renews
• The notice period from the termination clause, recorded as a number of days

You do not need every field perfect on day one. Get the renewal date and notice period in first, because together they give you the only date that really matters. Our guide on the register fields that matter covers the full set, and which columns to leave out because they rot faster than you will ever update them.

Step three: assign an owner to every tool

This is the step audits skip and later regret. Every tool needs a named person against it, not a team and not a shared inbox. "Marketing" does not answer an email about a renewal; a person does. The owner is whoever would make the call to keep, renegotiate or drop the tool, and if you cannot name one, you have found a problem worth recording in its own right.

Assigning ownership tends to expose the real state of the estate faster than any other step. The tools everyone assumed someone else looked after turn out to belong to nobody, and those are usually the ones quietly renewing unused. StackTrackr keeps a named owner against each record so accountability is never a mystery; you can read more on the ownership features.

Step four: flag the problems

With the register built and owners assigned, go through it once and mark the tools that need a decision. Three categories catch most of the waste:

• Unowned. Nobody will defend it, and often nobody remembers buying it. These are your strongest cancellation candidates, especially anything with no recent logins.
• Duplicate. Two or three tools doing one job because teams bought independently. Pick the survivor and plan the move for the others at their next renewal, not immediately.
• Unused or over-provisioned. A tool nobody opens, or a contract billing for fifty seats when the team is now thirty-five. The gap between seats paid for and seats used is where renegotiation leverage lives.

For anything you decide to drop, check what depends on it first, including any integration quietly running against its API, and export your data before the account closes. Access usually ends the day the subscription does. Our guide on the hidden cost of auto-renewing SaaS covers the traps in more detail.

The audit in order

Pulled together, a full pass runs like this. Work through it top to bottom the first time, and you will have a defensible picture of the whole stack:

1. 1Export twelve months of card statements, expense reports, SSO logs and vendor emails into one place.
2. 2Create one record per tool, deduplicating on the vendor domain rather than the product name.
3. 3Record cost, seats, renewal date, notice period and auto-renew status for each.
4. 4Assign a named owner to every tool, and flag any that have none.
5. 5Mark each tool as keep, consolidate or cancel, and mark any unused or over-provisioned seats.
6. 6Compute the cancellation deadline for every tool you want to change, and diarise it before the notice window closes.
7. 7Set the date of your next review before you close the audit.

Step five: set a cadence so it stays current

A one-off audit fixes today's estate and does nothing about next year's. The tools you cancelled will be replaced by new ones, and the duplicates will re-form as teams keep buying independently. The only durable fix is to stop treating the audit as an event and start treating it as a standing state.

Two habits do most of the work. First, make the register part of buying: a tool is not bought until it has a row, an owner and a renewal date, so the estate never drifts out of view between reviews. Second, let the register speak first. If it sits silently and waits to be consulted, it will not be; if it emails the owner before their notice window closes, it gets read and corrected, which is how it stays true. A quarterly glance at the flagged rows then replaces the annual week-long scramble.

StackTrackr is built to hold exactly this: one record per tool, a named owner against each, cancellation deadlines computed from the notice period, and reminders that reach the owner before the window shuts. See the features overview for the full picture, or start free and turn your first audit into a register that keeps itself current.