Ask the leadership team of almost any mid-sized business to list every AI tool the company is currently paying for, and you'll get a confident answer that turns out to be wrong by three or four tools once someone actually checks the credit card statements. This isn't a sign of poor management — it's a structural consequence of how AI tools get adopted in practice: a team lead signs up for something to solve an immediate problem, expenses it on a company card, and the subscription quietly renews every month without ever showing up in any conversation about "our AI tools," because nobody framed it as one of those at the time. Before adding one more subscription, the higher-leverage move is almost always finding out what's already being paid for.

Why this matters more than it sounds like it should

An unmapped set of AI subscriptions isn't just a minor cost-control issue — it creates three compounding problems. First, duplicate spend: two different teams often end up paying for functionally overlapping tools (two separate AI writing assistants, two separate meeting-transcription tools) because neither team knew the other had already solved the same problem. Second, unmanaged data exposure: every AI tool with access to company data is a place company information lives outside your direct control, and a tool nobody remembers signing up for is a tool nobody is checking for that exposure. Third, invisible dependency: teams build real workflows around tools that were adopted informally, and when a tool's pricing changes or it gets discontinued, the disruption catches everyone off guard because the tool was never tracked as something the business depended on.

Step 1: pull every actual data source, not just what people remember

Memory-based lists always undercount. Pull three real sources instead: the company's actual credit card and expense statements for the last twelve months, filtered for software and subscription charges; single sign-on or identity provider logs, if your company uses one, which show every third-party application anyone has authenticated into with a company account; and a direct, specific question to every team lead — not "what AI tools do you use" (too vague, invites the same undercounted answer) but "list every recurring software charge on your team's budget, AI or not, and we'll sort out which ones count afterward."

AI itself is useful here for the tedious part: feed a year of expense line items to an AI tool and have it flag every line that looks like a software subscription, categorize likely AI-related tools by name recognition, and produce a first-pass list for a human to verify and complete — turning what would be hours of manual statement review into a review-and-correct task instead.

Step 2: build the inventory with the fields that actually matter

A useful inventory isn't just a list of tool names — it needs enough structure to support the decisions that come after it. For each tool, record: what it's used for and by whom, what data it has access to (this is the field most inventories skip and the one that matters most for the exposure risk above), what it costs monthly or annually, who owns the relationship (who'd know if it broke, who approved it, who could cancel it), and whether it overlaps in function with anything else on the list.

A worked example: a 40-person marketing agency ran this exercise and found eleven distinct AI tools across the organization, only six of which any single leader had known about beforehand. Two were AI writing assistants purchased independently by two different account teams, at a combined cost of $1,140 a year more than standardizing on one would have cost. One was a transcription tool nobody remembered approving, still billing $49 a month, tied to a former employee's account, with continued access to recordings of client meetings — discovered only because the inventory exercise specifically asked "what does this tool have access to," not just "what does it cost."

Important

When building the data-access field, be specific rather than categorical. "Has access to client data" is too vague to act on; "has read access to the shared client meeting recordings folder, no write access, tied to an individual's account rather than a company-managed one" is specific enough to actually decide whether that access is appropriate and who should be responsible for revoking it if the person leaves.

Step 3: categorize by function to surface the overlaps

Once the inventory is populated, group tools by the actual function they serve — writing assistance, meeting transcription, data analysis, customer support, image generation — rather than by vendor or department. Overlaps that were invisible when the tools lived in different team budgets become obvious immediately once they're grouped by function, which is exactly what happened with the two writing assistants in the marketing agency example above: nobody had noticed the duplication because the tools sat in two different account teams' budgets, and nothing had ever put them side by side.

Step 4: score what's left against a simple set of criteria

For every tool that survives the overlap review, run it through a short scorecard rather than deciding case by case from memory: is it actually used regularly (check actual login or usage data where available, not just whether someone remembers liking it), does its data access match what it actually needs to do its job, is its cost justified by measurable time saved or output produced, and is there a named owner accountable for it. A tool that fails two or more of these — rarely used, broader data access than its function requires, cost that's hard to justify, no clear owner — is a strong candidate for cancellation regardless of how useful it seemed when it was first adopted.

Step 5: decide, and set a recurring date to do this again

The inventory exercise produces three outcomes for each tool: keep as-is, keep with tightened access or a reassigned owner, or cancel. For the marketing agency, the result was consolidating onto one writing assistant (saving the $1,140 overlap cost), immediately revoking the former employee's transcription tool access and reassigning the subscription to a current team member, and cancelling two tools nobody could demonstrate active use of, for a combined annual savings of just under $3,000 — real money, found entirely by looking rather than by negotiating harder on any single contract.

Set a recurring date, ideally tied to a natural business rhythm like an annual budget review, to run this again. Tool sprawl isn't a one-time problem that gets solved and stays solved — it re-accumulates at the same rate it did the first time, through the same mechanism: individual, reasonable, small decisions made without anyone tracking the aggregate.

Common mistakes in running this

The most common mistake is relying only on memory-based lists from team leads and skipping the harder step of pulling actual expense data — this reliably misses exactly the tools that matter most to find, since a tool important enough to remember was probably already being tracked somewhere. A second mistake is treating the exercise purely as a cost-cutting project and skipping the data-access field, which misses the exposure risk that's often more consequential than the dollar amount involved. A third is doing this once, treating it as solved, and not scheduling a recurring pass, which guarantees the same undercounted-inventory problem reappears within a year.

Handling the tools people are reluctant to give up

Not every consolidation conversation goes smoothly, and it's worth planning for the case where a team resists giving up a tool the inventory flags as redundant. The productive move here isn't to mandate cancellation from a spreadsheet — it's to ask the team to demonstrate the specific capability their preferred tool has that the consolidated option lacks, in a real side-by-side comparison on their actual work, not a hypothetical one. Sometimes this surfaces a genuine gap worth paying for twice; more often it surfaces a preference built on familiarity rather than capability, and seeing the comparison run on their own real tasks tends to be far more persuasive than being told the decision from above. Either way, resolving this concretely, rather than either overriding the team or quietly letting the duplicate spend continue, is what keeps the inventory a living tool rather than a document that identified a problem nobody then acted on.

It's also worth deciding in advance who has the authority to actually cancel something the inventory flags, before the exercise turns up a result — waiting until you're staring at a specific redundant subscription to figure out whether that decision belongs to the department head, finance, or IT tends to stall the whole consolidation step exactly when momentum matters most.

What this sets you up for

A completed, current tool inventory isn't just a cost-control exercise — it's the foundation for making any future AI tool decision well, because you can't sensibly evaluate whether a new subscription is worth adding without first knowing what you already have, what it costs, and where the actual gaps are. Businesses that skip this step tend to keep adding tools reactively, one team's immediate need at a time, and end up right back where this article started: unable to name everything they're paying for.

The AI-Powered Data and Knowledge Engine covers this inventory process as the necessary first step before any broader AI tooling strategy, on the reasoning that you can't manage what you haven't mapped. The book's AI Tool Inventory resource gives you the structured template used in the worked example above, the Technology Selection Scorecard helps you evaluate anything new against the same criteria before it gets added, and Technology Budgeting covers how to fold the resulting numbers into a forecast you can actually plan against rather than discovering the true cost after the fact.