How to Build a SaaS Inventory from Scratch

Last updated: October 22, 2026

Key Takeaways

• Build a usable SaaS inventory by linking discovery, ownership, and contract details in one controlled list.
• Keep the first version focused on the fields that show ownership, scope, and renewal timing.
• The best rows answer who owns the app, who administers it, and when it is due.
• Find apps across the company from people, spend, and admin access.

A SaaS inventory is the practical starting point for answering what software the company uses, who owns it, and what is due next. This guide on how to build a SaaS inventory from scratch is most useful when no one can name every app, when department leads keep separate spreadsheets, or when renewals and admin access live in different inboxes.

In short: start with discovery, record the few fields that make the inventory useful later, assign one owner per app, and keep renewal dates and license counts in the same place. If the inventory cannot tell you who bought an app, who uses it, and when it renews, it is just a list.

What a SaaS inventory must do on day one

A SaaS inventory should let a person find an app in under 1 minute and understand its business owner in the same glance. That is the minimum useful standard for a first build. A prettier sheet with no ownership, no department mapping, and no renewal dates fails the job.

The first version does not need every detail a mature software asset management program might hold. It needs the fields that stop confusion later, and you should confirm the final field set with your finance, IT, or procurement lead and a current software asset management reference such as FinOps Foundation guidance or ISO/IEC 19770-1.

• App name
• Vendor
• Department that uses it most
• Business owner
• Technical admin
• Contract owner or procurement contact
• License count purchased
• License count assigned
• Renewal date
• Contract link or storage reference
• Status, such as active, pilot, or retired

Those fields matter because they connect people to decisions. Employees can tell you what tools they use. Department leads can confirm whether the app is still needed. Admins can confirm who can change settings. Contracts and license records explain what was bought, when it renews, and who approved it.

The trade-off is simple: a short inventory is easier to build, but a short inventory that omits owners turns into a dead record. A richer inventory takes longer to create, yet it pays off when someone asks, “Who owns this?” and the answer is already there.

This page supports the broader SaaS buying decisions hub, because a clean inventory is the starting point for better purchase and renewal choices. It is not the buying decision itself; it is the map that makes the decision legible.

How do you create a SaaS inventory?

You create a SaaS inventory by combining discovery, ownership, and contract data into one controlled list. The cleanest first build is a spreadsheet or shared database with 10 to 12 required fields, then a repeatable review process for updates.

Use this procedure to get from zero to a usable first draft:

1. Choose one system of record, such as a spreadsheet in Google Sheets or Excel, or a shared database in Airtable or Smartsheet. The result should be one place where every app row lives, not three versions in three inboxes.
2. List every app name you already know from finance, IT, and department leads. Start with about 20 to 50 known tools if the company is small, then expand by team. The result is a seed list that should help reduce obvious gaps, but it should be reviewed with finance, IT, or procurement guidance and a current SaaS management source.
3. Ask each department lead for the top 10 tools their team uses, including free plans and departmental sign-ups. This step usually catches shadow IT and apps bought with a corporate card. The result is broader coverage than IT-only discovery, though a 15-minute review with each lead should be treated as a practical starting point rather than a guarantee; consult a finance, IT, or procurement professional and compare against a current SaaS management source.
4. Record the owner fields for each app: business owner, technical admin, and department. If one person owns both sides, record that once but keep the role labels separate. The result is a list that still works when staff move roles.
5. Add contract fields: vendor, contract start or signature date, renewal date, license count purchased, and contract storage location. The result is that the inventory can support renewal prep without searching email for 30 minutes.
6. Review duplicates and name variants, such as “Slack,” “Slack Enterprise Grid,” and “Slack HQ.” Merge only after checking whether they are truly separate contracts or one vendor with multiple workspaces. The result is a clean app-level record instead of duplicate noise.
7. Publish the first version to a small review group of 3 to 5 people: one finance contact, one IT admin, and two department leads. The result is faster correction before the list spreads across the company.

A first inventory built this way is not final. It is a working draft. The point is to create a single source that can absorb later details without rebuilding the structure.

Which fields make the inventory useful later?

The most useful fields are the ones that answer ownership, scope, and timing in a single row. If a field will not help a person make a decision in the next 6 months, it is probably optional for the first version.

Here is the field set that earns its place:

• App name and vendor: Needed to identify the tool and avoid duplicate entries.
• Department mapping: Shows where the app sits in the business, such as Sales, Finance, HR, or Marketing.
• Business owner: The person who can say yes or no to keeping the app.
• Technical admin: The person who can change settings, users, or security options.
• Employee group or user segment: Helps distinguish a company-wide tool from a team-only tool.
• License count purchased: Tells you what the company paid for or committed to.
• License count assigned: Shows current allocation, even if usage tracking lives elsewhere.
• Renewal date: Puts the next decision on the calendar.
• Contract reference: A file path, document ID, or storage location for the agreement.
• Status: Active, trial, pilot, paused, or retired.

The exact shape of each field matters less than consistency. If one row says “Marketing” and another says “Mktg,” the inventory loses search value. If one renewal date is a true date and another is a note like “Q4,” the list becomes harder to sort and filter.

A common mistake is to overbuild the first version with too many columns, especially feature fields that look useful but never get maintained. That costs time during entry and produces stale data in 90 days. Keep the first pass focused on identity, ownership, and renewal timing.

A second mistake is to store contracts in a separate location with no reference back to the app row. That forces someone to search across folders later. Instead, store a direct link or a clear reference code in the inventory row itself.

How to discover apps across the company without guessing

You discover apps across the company by asking for them from three directions: people, spend, and admin access. One source alone will miss something, and the misses are usually the most embarrassing apps.

Start with people. Send department leads a short request for every tool their team uses, including the ones purchased outside IT. Ask for the app name, owner, purpose, and whether it has paid seats. A 15-minute review with each lead is often enough to surface the hidden tools that never reach central procurement, though a finance, IT, or procurement professional should confirm the final list and current guidance from a SaaS management source.

Then look at spend. Review recurring card charges, expense reports, and vendor invoices for SaaS names. Monthly or annual charges often reveal products that staff no longer mention because the app became routine. This step is especially useful for small teams with fewer formal purchase controls.

Next, check admin surfaces. If the company uses a single sign-on platform, app directories and connected-app lists can expose tools tied to company identity. If it does not, use admin consoles for major systems like Google Workspace or Microsoft 365 to see connected services and delegated access. The goal is not a perfect software asset scan. It is to catch the obvious apps before they vanish into departmental memory.

Do not confuse discovery with completeness. The first pass will still miss trial tools, personal card purchases, and niche apps used by one team. That is normal. The point is to create a live baseline, not a courtroom exhibit.

The honest trade-off here is speed versus coverage. A 1-hour discovery sprint gives you a starter list quickly, but a 2- to 3-week review with department leads and finance catches more shadow tools. If the company is tiny, start fast. If the company has multiple departments and several admins, slower is safer.

How should ownership and department mapping work?

Ownership should be split into business and technical roles, and each app should belong to one department even if multiple teams use it. That structure keeps the inventory usable when employees change jobs or when an app spans the whole company.

Use this rule:

• Business owner decides whether the app stays.
• Technical admin handles configuration, access, and setup.
• Department owner ties the app to the team budget or headcount.
• Secondary users can be noted, but they should not replace a named owner.

This matters because many app lists fail when they confuse “heavy user” with “decision maker.” The person who opens the app every day may not know the contract terms. The person who signed the contract may not know who administers it. The inventory should separate those roles.

For department mapping, choose one primary department per app and allow a secondary tag if needed. A company-wide tool such as email or conferencing may sit under IT or Operations, while a sales tool sits under Revenue. If HR and Finance both use a workflow tool, pick the department that controls the renewal or budget, then note the secondary team in a comment field.

Avoid the trap of multi-owner rows with no final decision maker. “Owned by Sales and Marketing” sounds inclusive, but it breaks accountability. When renewal season arrives, no one knows who is supposed to act. One named owner per role solves that problem.

A practical standard is to require an owner review every 90 days for active apps. That does not mean a deep audit. It means confirming the named people and department still match reality.

What does a good first version look like in a spreadsheet?

A good first version is a narrow spreadsheet with stable columns, clean dropdowns, and a small set of required fields. It should be easy to filter by department, renewal date, and owner without needing a custom report.

Set up the sheet with one row per app and one tab for the live inventory. Keep the required fields locked or at least clearly marked:

• App name
• Vendor
• Department
• Business owner
• Technical admin
• License count purchased
• License count assigned
• Renewal date
• Contract location
• Status

Then add simple controls:

• Dropdowns for department and status
• Date formatting for renewal dates
• Freeze the top row
• Filter views for each department lead
• Conditional formatting for renewals within 60 or 90 days

A spreadsheet is not glamorous, but it is often the right place to start. It works well when the company is still discovering its app footprint and the process is not yet mature. The limitation is governance: a spreadsheet can drift if no one owns updates. It also gets messy when too many people edit at once.

A database-style tool makes sense later if the inventory needs permissions, audit trails, or structured forms. That said, a more complex tool does not fix weak discipline. If no one updates owners after a reorg, the platform does not matter.

Keep the first version readable by someone outside IT. A finance lead should be able to scan it and understand what is coming due. A department lead should be able to spot their team’s apps in 2 clicks or less.

How do you keep the inventory current after the first build?

You keep it current by assigning a monthly or quarterly update cadence, naming a single keeper, and tying updates to events that already happen. Without that, the inventory becomes historical, not operational.

Set a simple rhythm:

• Monthly: review new apps, owner changes, and new contract entries.
• Quarterly: ask department leads to confirm their active tools.
• 30 to 90 days before renewal: verify owner, department, license count, and contract location.

The keeper can be an IT operations lead, a procurement contact, or a SaaS admin, but the role must be named. If everyone owns the inventory, no one does. That person does not need to approve every app; they need to maintain the record and chase missing fields.

Tie updates to events already on the calendar. New vendor contracts, staff changes, offboarding, and renewals all create natural update points. If someone leaves, check the apps they owned. If a team grows, check whether the license count still matches the headcount. If a tool is retired, mark the status and archive the contract reference instead of deleting the row.

The biggest mistake at this stage is waiting for a “perfect cleanup.” That costs momentum and hides risk. A rough but current inventory is more valuable than a polished one that has not changed in 9 months. The second mistake is allowing department leads to own updates informally without a deadline. A 10-minute review request is better than a vague promise.

A SaaS inventory earns its keep when it can answer basic questions fast: what do we have, who owns it, how many seats are committed, and when is the next decision due. If it can do that, it is doing the job.

What should be in a software inventory?

A software inventory should include the software name, vendor, owner, department, license counts, and renewal timing. Those fields let the company see what it has, who manages it, and what needs attention next.

A stronger inventory also includes a contract reference and a status field. If the list is only a catalog of app names, it will not support renewal planning or ownership changes. The first build should favor clarity over depth, with consistent names and one row per application.

How often should you update your SaaS inventory?

You should update your SaaS inventory at least quarterly, with monthly changes for new apps, owner changes, and renewals. That cadence keeps the record close enough to reality to be useful without turning maintenance into a full-time job.

If the company changes quickly, monthly updates are safer. If the company is small and stable, quarterly may be enough. The inventory should also be updated whenever someone leaves, a new app is approved, or a contract is signed. A stale record is worse than a short one because it creates false confidence.

Drafted with AI; not yet reviewed by a person.