Quarterly Stack Audit: A Four-Column Worksheet and Where to Check Seat Activity

A stack audit is a review of every piece of software a team pays for, done in one sitting, where each line ends in a decision. The reason most of them never happen is that they get framed as a project: catalogue every tool, interview every user, build a scoring matrix. The version described here is deliberately narrower. It uses records you already have, a four-column worksheet, three possible outcomes per line, and a calendar rule that makes the next audit shorter than this one.

Documentation checked September 22, 2026. This is a proposed procedure with a labelled hypothetical example, not a report of audits we ran. An earlier version of this article described four quarterly audits, specific tools discovered, and $2,140 of annual spend cut; those figures had no supporting records and have been removed.

Illustration only; the circled charges do not represent a real statement.

Start from payment records, not from memory

A list of tools written from memory is a list of things you remember. A payment export is a list of things that are actually charging you. Those two lists differ, and the difference is where an audit earns its time.

Export the last twelve months of transactions from every card and account the team uses for software, then filter for recurring merchants. Twelve months matters because annual renewals appear once; a three-month window will miss them. Match each merchant string to a product — a parent-company name on a statement may look nothing like the app — and mark anything you cannot match as unresolved rather than deleting it. If a teammate expenses a personal-card subscription, ask for that statement line too; the shadow-software audit covers how to reconcile payment records against signups and connected apps when the two disagree.

The output of this step is a list of recurring charges with an amount and a cadence. It is not yet a decision list.

Four columns are enough

Put every recurring charge in one sheet. The temptation is to add value scores, criticality ratings, and owner sentiment, and each extra column gives the audit a way to end without a decision. This layout is a suggestion, not a standard:

Column	What to enter	Question it answers
What	Product, plan tier, and number of seats	Is this the same subscription as another line?
Cost per year	Monthly price × 12, or the annual invoice; note the currency	What does this actually cost, on one comparable basis?
Who uses it	A named person, not “the team”; the date they last opened it if the vendor reports one	Can anyone be named who would notice if it stopped?
Renews on	The next charge date, and the cancellation deadline if the vendor states one	When must a decision be made to avoid the next charge?

Normalising everything to a per-year figure is what makes the lines comparable. A $9 monthly plan and a $99 annual plan look similar in a statement and are $108 and $99 in the sheet. If you are choosing between those two cadences, the annual discount is a loan works through what the up-front commitment costs you in flexibility.

Where “who uses it” can be checked instead of guessed

“Who uses it” is the column where a sheet drifts toward optimism. “The team” is not an answer; a name is. For many team products, the vendor exposes per-member activity data that replaces the guess. The table lists three that document this. Access requires an administrative role in each case, and the data lags real activity.

Product	What the documentation says is available	Who can see it	What to record or watch for
Slack	The analytics dashboard has a Members tab with configurable columns (“Edit columns”) and an “Export CSV” button.	“By default, only Workspace Owners and Admins can see member analytics.” Members tab is documented for Pro and Business+; Enterprise adds org-level access for Org Owners, Org Admins and Analytics Admins.	Owners can extend access to all members or disable member analytics entirely, so the tab may be off in your workspace.
Google Workspace	The Accounts user report includes per-app columns such as “Gmail (Web) - last used time” and “Drive - last active time”, exportable “to a Google Sheet, or download it as a CSV file”.	“Requires having the Reports administrator privilege.”	“You won’t see complete data up to the present day”; the report shows the latest date each column covers. Sign-in dates are a separate report.
Microsoft 365	The Active users report lists, per user, a “Last active date” for Exchange, OneDrive, SharePoint, Teams and Viva Engage, plus license-assignment dates, with an Export to CSV.	Roles are listed under “Before you begin” in the usage-reports overview.	“The data in each report usually covers up to the last 24 to 48 hours.” Usernames are hidden by default in usage reports and must be enabled by an admin.

Two cautions apply to all three. First, a last-active date measures whether someone opened the product, not whether the product did anything useful; a seat that is opened weekly for a task a free plan could handle is still a downgrade candidate. Second, absence of data is not evidence of absence of use. A tool that reports no activity data at all, or reports it only on a plan you do not have, goes back to the named-person test: if nobody on the team will say “I use this”, treat the line as unresolved and ask, rather than cutting on silence.

For tools that expose nothing, a member or billing page usually shows at least how many seats are paid for versus how many accounts have been activated, which is enough to catch seats that were bought and never filled.

Three outcomes per line

Each line must end as one of three decisions before you move to the next. Deferring is not an outcome.

• Keep — you would buy this again today at this price. Not “it is fine”, but “if it were cancelled tomorrow, we would re-subscribe at this tier”. Some lines need a reversible dependency test; record them as pending with a date, and keep protective services active during the review.
• Cut — cancel now and accept the loss. This includes tools the team still likes; leaving a tool you still like is a separate problem from deciding whether it earns its line. Before cutting, check the vendor’s data-retention terms on cancellation and export anything you need first.
• Downgrade — a lower tier, fewer seats, or a different billing cadence. This is the outcome people forget because it requires reading the pricing page again, and it is where a large share of the reduction usually sits: the plan was chosen for a feature that was needed once, or for a headcount the team no longer has.

A hypothetical worked example

The following is a fictional five-person studio, constructed to show the arithmetic. The tools and prices are illustrative and are not drawn from any vendor’s current price list.

Line	Before (per year)	Evidence in the sheet	Decision	After (per year)
Design tool, 5 seats at $15/mo	$900	Activity export: 3 members active in the last 30 days	Downgrade to 3 seats	$540
Transcription service, $20/mo	$240	No named user; last invoice paid by a former contractor’s card	Cut	$0
Project tracker, 5 seats at $10/mo	$600	All 5 members active; named owner would re-buy	Keep	$600
Form builder, $29/mo	$348	One person, one form per month; vendor’s free plan covers the volume	Downgrade to free	$0
Cloud storage, 2 TB annual	$120	Named owner; 1.4 TB used	Keep	$120
Total	$2,208			$1,260

The reduction in this example is $948 per year, or about 43% of the starting figure. The number itself is not the point; the pattern is. Two of the three savings came from downgrades, not cuts, and the only cut was the line with no named user. That pattern is common enough to plan for — check the downgrade options before deciding a line is keep-or-cut — but it is not a prediction of what your own sheet will show.

An audit can also surface the opposite decision. If a line’s “who uses it” note says a person is working around a limit that the next tier removes, an upgrade is a legitimate outcome. Framing the exercise purely as cost-cutting makes people defensive about their tools, and defensive people hide tools, which is how a stack becomes invisible in the first place.

Put the renewal on the calendar, not the receipt

The reason a marginal subscription survives is that its decision point arrives as a receipt, after the money has gone. Moving the decision to before the charge is the part of this process that compounds.

For each line marked keep or downgrade, add a calendar event thirty days before the renewal date, titled with the product and the annual amount. Where a vendor states a cancellation cut-off — some annual plans require notice before the renewal date, and the terms page or billing settings usually say so — set the reminder before that cut-off, not before the charge. Small charges deserve the same treatment as large ones; small subscriptions are the hardest to cancel precisely because they never trigger a review on their own.

After a year of doing this, the quarterly audit gets shorter, because obvious cuts have already happened at their own renewal points and the sheet only needs updating rather than rebuilding. Keep the previous quarter’s sheet and diff against it: new lines, changed amounts, and lines whose “who uses it” name has left the team are the ones that need attention.

Running it in a team

Run the audit on spend and present it as decisions. Do not present it as a list of things individual people were wrong to buy. A review that reads as blame has a predictable failure mode: the next quarter’s tools move to personal cards and reimbursement claims, where the payment export no longer sees them. The shadow-software checklist exists for exactly that situation, but it is cheaper not to create it.

Two practical rules help. First, the person who runs the sheet should not be the one who decides every line; the named user in column three gets asked “would you buy it again today at this price?” and their answer is recorded. Second, ask for the personal-card lines up front, with an explicit statement that the goal is to see the whole picture, not to reject reimbursements. If the team has already agreed on a small number of spending categories, tag each line with one; it makes the quarter-on-quarter comparison readable without adding a scoring column.

Limits of this procedure

This is a proposed process, not a tested one. The activity reports in the table above are documented as of the check date and may be renamed, moved, or restricted to different plans later; confirm on the live help page before relying on a column. The hypothetical example demonstrates the arithmetic, not an expected result, and a team with mostly single-user tools or mostly free plans will see a different shape. Nothing here replaces reading a vendor’s own cancellation and refund terms before acting on a cut, and nothing here addresses whether a tool’s data handling is acceptable, which is a separate review.

What the procedure does provide is a repeatable way to reach a decision on every line in one sitting, using evidence that already exists, and a mechanism that moves each future decision to a point where it can still be acted on.