the SaaS list is a finance export

Ask the head of IT at a 300-person company how many SaaS tools the company uses. The answer will be somewhere around 50, defended by the procurement system’s count.

Ask the security lead the same question. The answer will be somewhere around 35, defended by the SSO integration list.

Ask the CFO the same question. If she has time to pull the data, the answer will be 180 to 250, drawn from twelve months of recurring vendor charges across the credit card and ACH feeds.

The CFO’s number is the closest to reality. It is also the number nobody in IT or security ever asks for, because the question is filed under “procurement” or “finance” rather than “security,” and the organizational seams prevent the data from flowing.

This essay is about that specific dataset, the finance-sourced SaaS inventory, and why it’s the most underused, highest-fidelity asset in your company’s identity program. It’s also about the five-step exercise that turns that asset into the foundation of your SaaS visibility.

the data already exists

Every SaaS tool in use at your company is paid for, one way or another. The payment generates a financial record. The record lives in one of a small number of places.

Corporate credit card transactions. Somebody expensed a subscription. The charge shows up on the card statement, which is imported into the expense management system (Concur, Expensify, Ramp, Brex, Airbase), which feeds into the general ledger.

ACH and wire transfers. Somebody signed a contract with an invoice. The invoice is paid through AP. The vendor name, payment amount, and frequency are captured in the AP system and feed into the general ledger.

Employee reimbursements. Somebody paid personally and got reimbursed. The reimbursement shows up in payroll expenses with a vendor tag.

In every case, the data is there. The vendor name is captured. The amount is captured. The date is captured. Whether it’s recurring is captured, or can be inferred from the frequency.

What’s not captured, by default, is the taxonomy. The expense system knows the vendor is “Adobe Creative Cloud Subscription.” It doesn’t know that this vendor is a SaaS tool that has implications for your identity program. The tagging to indicate “this is SaaS” has to be applied on top of the raw data.

Applying the tagging is mechanical. You need a mapping from vendor names to categories. “Adobe Creative Cloud Subscription” → SaaS. “Starbucks Corporate” → not SaaS. The mapping is a spreadsheet with a few hundred rows. Building it the first time takes a day. Maintaining it after that takes a few minutes per quarter.

Once the tagging is in place, the finance data becomes a queryable SaaS inventory that updates itself every time a new vendor enters the expense system.

three lists of your SaaS, and what each one can see

the lists security usually has

partial by design

• Single sign-on: only tools someone connected to SSO
• Procurement: only tools that went through approval
• Security tools: only what their connectors reach

the finance export

everything paid for

• Cards, invoices, bank transfers and expense claims
• Tools bought by any team, on any budget
• Paid for even when nobody uses them

the taxonomy problem is smaller than it looks

The reason IT and security don’t use finance data is usually that the taxonomy problem feels insurmountable. The finance data has thousands of vendor entries. Categorizing all of them sounds like a project.

In practice, spend is heavily skewed: a few dozen vendors usually account for most of the total, and the rest is a long tail of small tools. If you want to catch everything, you categorize the long tail as well. If you want to catch the vast majority, you only need to categorize the top 50 or 100.

The categories themselves don’t need to be sophisticated. A three-tier taxonomy is usually enough. SaaS/not SaaS. If SaaS: tool category (productivity, development, sales, marketing, analytics, etc.). If SaaS: data sensitivity (customer data, employee data, financial data, internal-only).

The data sensitivity tier is what makes the taxonomy actually useful for security. A SaaS tool that holds customer data is a different risk profile from a SaaS tool that holds only internal-only data. The category helps you prioritize where to focus your SSO integration, access review, and offboarding attention.

Mapping the top 50 vendors takes an afternoon. Mapping the next 50 takes another afternoon. After that, you can see most of the spend, and each further hour of categorisation adds less.

the reconciliation produces the real list

The finance list, by itself, is not quite the real list. It includes vendors you’ve stopped using but haven’t canceled. It misses some genuinely free tools. It double-counts vendors who rebrand or change billing names.

The reconciliation is a comparison between three sources.

The finance-derived SaaS list, as described above. Call this F.

The SSO-federated application list, pulled from your IdP admin. Call this S.

The procurement-approved application list, pulled from your vendor management system. Call this P.

Run the comparison. For each vendor that appears in F, check whether it’s in S and whether it’s in P. For each vendor in S or P, check whether it’s in F.

The results will fall into specific buckets.

In F, S, and P. The fully managed applications. These are the ones your identity program knows about and has integrated. Typically the smallest bucket.

In F and P but not S. Applications you’ve approved and are paying for, but haven’t integrated with SSO. These are usually enterprise applications where SSO integration was deferred or wasn’t prioritized.

In F and S but not P. Applications you’re paying for and have integrated with SSO, but don’t appear in the procurement system. Often this is because procurement was bypassed at the original purchase and procurement has never been updated. Investigate whether the procurement record should be backfilled.

In F but not S or P. Applications you’re paying for that have neither been SSO-integrated nor approved through procurement. This is shadow IT in its purest form, the tools that entered the company through credit cards and never got centralized. This bucket is usually the largest of the discovery buckets.

In S or P but not F. Applications listed as known but not showing up in your payment data. Possibilities: the application was retired but the integration wasn’t removed, the application is genuinely free, or the payment is happening through a channel you didn’t query. Worth investigating.

The output of this reconciliation is a unified SaaS inventory that’s more complete than any single source. The intersection of F, S, and P is your known footprint. The union is your actual footprint. The gap between them is the work to be done.

the quarterly update is the practice

Running this exercise once produces a moment-in-time inventory. Running it quarterly produces a living inventory that tracks changes as they happen.

The quarterly cycle is small after the first iteration. The taxonomy is mostly stable. New vendors appear, and new vendor entries need to be categorized. Old vendors may drop off if they’re no longer being used. The reconciliation logic stays the same.

The output of each quarterly cycle is a diff. New tools that entered the environment since last quarter. Tools that disappeared. Tools that moved between buckets (for example, a shadow IT tool that got formally onboarded and now shows up in all three sources). The diff is what drives the action list.

New shadow IT tools get routed to a conversation. Who bought this? What is it for? Should it be onboarded officially? Should it be consolidated with an existing approved tool? The conversation happens quarterly, driven by fresh data.

The companies that run this consistently end up with a natural cadence of SaaS portfolio management. Every quarter, the long tail of shadow IT either gets absorbed into the approved stack or gets rationalized away. The cumulative effect over a year or two is a significantly smaller and cleaner SaaS footprint, with known owners and integrated access control.

The companies that don’t run this accumulate SaaS tools monotonically. The footprint grows every quarter. The shadow IT share grows. The visibility gap grows. The identity program operates on an increasingly partial view.

turning the finance export into an inventory

1. exportrecurring charges, last 12 months
2. tagwhich lines are SaaS
3. reconcileagainst SSO and procurement
4. follow upevery unknown vendor is one conversation

the specific technical setup

The setup doesn’t require a dedicated tool. It can be done with spreadsheets and quarterly exports.

From your expense management system (Concur, Ramp, Brex, Expensify, etc.), export a CSV of all vendor charges from the last twelve months. Include vendor name, total amount, frequency (monthly, annual, one-time), and paying department.

From your AP system, export a CSV of all invoice payments from the last twelve months. Include vendor name, total amount, frequency, and owning cost center.

Merge the two exports. Deduplicate by vendor name (watch for variants, “Adobe Creative Cloud” vs “Adobe” vs “Adobe Systems”). The result is your unified payment list.

From your IdP admin, export the list of federated applications. Include application name, number of users, and last-login date.

From your vendor management system, export the list of approved applications. Include application name, owner, approval date.

Put all three lists in a spreadsheet. Use a lookup function to cross-reference by application name (with fuzzy matching or a manual normalization step). Build the four-bucket analysis described above.

The first iteration takes a day. Subsequent iterations take an hour, once the lookups are built.

For companies with a SaaS management tool like Zylo, Productiv, Torii, or similar, the tool can automate parts of this. The tool typically pulls from the expense system and attempts to categorize and match to SSO data. The tools are useful for ongoing management. For the initial inventory, a spreadsheet works fine and is easier to reason about.

what the finance data reveals that other sources don’t

Specific patterns that show up in the finance data but not in SSO or procurement.

The long-tail subscription. A single person pays $20/month for a writing tool. The charge is too small to trigger a procurement process. It’s not integrated with SSO because SSO integration isn’t offered at the $20/month tier. The tool never appears on IT or security’s radar. It shows up in finance.

The team subscription that outgrew its origin. A marketing team signed up for a $200/month team plan two years ago. The team has since grown. The plan still exists. The team lead renews it annually. It’s never been mentioned in any IT meeting. It shows up in finance.

The cross-charge from a different entity. A subsidiary of the company pays for a tool that’s used by employees of the parent company. The subsidiary’s finance shows the charge. The parent’s IT has no visibility into it. The reconciliation across entities shows it.

The reimbursement-based subscription. An employee pays personally for a tool useful for their work and submits a reimbursement. The reimbursement flows through payroll, not the expense system directly. It shows up in payroll data. It doesn’t show up in any SaaS inventory.

The grandfathered annual payment. A tool was purchased with a multi-year contract three years ago. The payment hits once a year. If you’re only looking at the last three months of finance data, you miss it. If you’re looking at the last twelve, you catch it.

The cumulative volume of these categories, in a mid-market company, is usually larger than the entire known SaaS footprint. The procurement-approved list is the tip. Finance sees the iceberg.

the exercise

Here is the specific exercise for Monday morning.

Email your CFO or controller. Ask for a CSV export of all recurring vendor charges from the last twelve months, across all payment channels (credit card, ACH, wire, reimbursement). Specify that you need vendor name, date, amount, and frequency at minimum.

Receive the CSV within a day. The CFO will provide it because the request is simple and the data is routine.

Open the CSV. Sort by vendor name. Scan for SaaS-looking entries. If you’re unsure, google the vendor name.

You will see vendors you don’t recognize. Each one is a conversation. Who is paying for this? What is it for? Does it hold our data? Does it need to be integrated with SSO?

By the time you finish the first pass, probably two to three hours, depending on your company size, you will have a list of tools larger than your IT or security team’s list. You will have answered, for the first time, the question “what SaaS do we actually use?”

The answer will not make you comfortable. Every subsequent quarter of doing this exercise will make you more comfortable. The discomfort is the cost of finally seeing the shape of the footprint you’ve been operating.

The CFO has always had the answer. The question has always been which one of you would think to ask.

Ask.