How to measure licence utilisation without asking your vendor — three steps you can run yourself

You can produce a defensible licence utilisation number in-house, without your vendor's reporting, in three steps: build an inventory of what is actually owned, get a usage signal you control, and attach a euro figure to the gap between the two. None of it requires buying a platform. All of it requires someone to own the question.

The reason to do it independently is not suspicion. It is that a vendor's usage report answers the vendor's question — how much of our product are you entitled to — and not yours, which is how much of what we pay for gets used.

Why shouldn’t you rely on the vendor’s own usage reporting?

Because it makes your renewal position dependent on the party across the table, and because organisations that do it lose the ability to see their own waste.

The clearest documented case is public. Germany's federal audit office examined Bundeswehr software procurement for the period 2006–2019 and reported more than €50 million spent on software that went unused, with at least €5 million a year in ongoing maintenance on unused licences (Bundesrechnungshof, *Mehr als 50 Mio. Euro für ungenutzte Software*, published April 2022). In more than 20 cases software was bought and either never used or used to a considerably smaller extent than licensed.

The mechanism the auditors described is the part worth copying down. The Bundeswehr, they wrote, had obtained no independent overview of the extent to which it used the vendor's software — it lacked "Analyseinstrumente und die nötigen Kenntnisse", the analysis instruments and the necessary knowledge. The only usage data it had came from the vendor's own contractual audits, exercised three times, most recently in 2019. And the maintenance fee tracked licences *bought*, not licences *used*: whether the software was actually used, the report notes, was "nicht maßgeblich" — not decisive.

That is a national audit office describing, in a public document, the exact failure this article is about. Two caveats so the figure travels honestly: those numbers describe one organisation over thirteen years, not a market rate, and the separate figures in that report measure different things — €50m is unused-software spend, not the total contract value.

Step 1: inventory what is actually owned

Not what procurement believes is owned. What is being paid for.

The source of truth is the money, not the asset register. Twelve months of card and bank statements plus the accounts-payable ledger, filtered for anything recurring. Two categories reliably surface that no licence dashboard holds:

• Subscriptions on personal and departmental cards. Normal, not exceptional. A team that needed a tool in a hurry two years ago is still paying for it.
• Tools bought twice. Two departments solving the same problem with different vendors, each unaware of the other, both renewing.

Write down, per line: the tool, the annual cost, the number of seats paid for, and the person whose name is on the renewal. That last column is the one that makes the rest of the work possible, and it is usually the one nobody has.

Step 2: get a usage signal that is yours

This is where independence is won or lost. You need a signal that does not come from the vendor's dashboard, and there are more sources than most teams expect:

• Identity and single sign-on logs. If a tool is behind SSO, your identity provider knows who authenticated and when. That data is yours, it is already being collected, and it is the single highest-value source in this exercise.
• Network and proxy logs. Coarser, but they answer "is anyone reaching this domain at all" for tools outside SSO.
• Device and endpoint management. Installed versus licensed is a real gap and your MDM can tell you.
• Your own admin APIs where they exist. Where a vendor exposes last-sign-in through an API you query yourself, that is closer to independent than a report they generate and send you.
• The people. Twenty minutes with a team, asking what they open in a normal week, is data. It is also the only source that surfaces the second kind of waste — tools people do open and use at a fraction of what was bought.

Two disciplines make the difference between a number and an argument. Pick one window and hold it — 30 or 90 days, applied identically to every tool, so lines are comparable. And separate "never opened" from "opened but shallow" from the start. They have different owners, different fixes and different arithmetic, and a single "utilisation" percentage that blends them is unusable.

Step 3: attach a euro figure to each line

A percentage does not survive a board meeting. A euro figure traced to an invoice does.

For each line: annual cost, seats paid, seats with activity in your window, cost of the inactive seats, and — separately — the tier premium being paid for capability nobody uses. Then split the total into two columns, because they are two different kinds of money:

• Recoverable now. Idle seats, duplicate tools, over-licensed users sitting on a premium tier using only what the tier below includes, commitment terms that are negotiable inputs rather than fixed properties of the contract. This is one-time and near-certain.
• Untapped capability. Licences in daily use at a fraction of what they can do. This is recurring and larger, and it is not recovered by cancelling anything — it is recovered by people learning what they already own.

Most teams find the first column and stop. The first column is the cheaper half.

Which step can’t you do alone?

The third one, honestly — and specifically the decision at the end of it.

Steps one and two are mechanical. Any competent internal team can run them, and they should, whether or not they ever hire anyone. Step three splits: the arithmetic is mechanical, but deciding what to cancel is a judgment call about which team's workflow you are willing to change, and no dataset makes that call for you.

Three things a self-run exercise reliably cannot produce:

• A verdict between two overlapping tools, because that depends on which department's process you are prepared to break.
• Separation of a seat that is idle from a seat that is dormant-but-strategic — the one belonging to the person who runs the quarterly consolidation.
• Anyone actually using the tool you decide to keep. This is the step that converts the remaining spend into a return, and it is not a data problem at all.

There is also an internal-politics limit worth naming: the person who bought a tool is rarely the right person to report that nobody uses it. That is not a competence issue. It is why external audits exist in every other cost category.

What does week one of an audit produce?

The same three artifacts as above, which is why we publish the method rather than guard it. Week one of a scoped audit produces:

1. An inventory of the licences actually being paid for.
2. A real utilisation number, produced independently of the vendor whose renewal is at stake.
3. A hard € figure, each line traced to an invoice.

The first two are boring. They are also the two a script never produces, and the two the third one is worthless without.

If you want the honest comparison between running a script and running the full exercise, we wrote it up separately: what a Graph API script finds, and what it can't. And the public-sector evidence behind step two is in what two public audits prove about unused software licences.

Start with the smaller version this week

If three steps is too much to start, do the one-hour version: pull the last twelve months of software invoices, add them up, and write the total on a page. Then, for each of the five largest lines, write one sentence saying what the tool was bought to do and one saying what it is used for.

The gap between those two sentences is the second column above, and it is the one that is growing.

A vendor's usage report answers the vendor's question. If the only view you have of your own consumption comes from the company selling it to you, you do not have a measurement — you have a statement.