When a vendor asks you to prove your licence count
It usually arrives as a polite email from an account manager, or from a team you have never dealt with, asking you to confirm how many users, installations or devices you have on a product. Sometimes the word audit is used. More often it is called a licence review, an entitlement check, or a true-up. Whatever it is called, the same thing is being asked: tell us what you are actually running, so we can compare it against what you bought.
The request is not an accusation and it is rarely a trap. It is a contractual right the vendor negotiated when you signed, and in most cases it ends with everyone agreeing the numbers match. It becomes expensive in a predictable way: the buyer does not know their own count, so the vendor's number becomes the only number in the room, and the gap is settled at list price under time pressure a few weeks before a renewal.
Everything below is about avoiding that specific shape. The work is mostly counting, and the leverage comes almost entirely from counting first.
Read the audit clause before you read the request
The email tells you what the vendor wants. The contract tells you what they are entitled to, and the two are frequently not the same. Before answering anything, find the agreement and read the audit or verification clause, which in most enterprise software contracts sets out some combination of the following.
- Notice. Many clauses require written notice a set number of days ahead, and limit how often verification can be requested, commonly to once in any twelve-month period.
- Scope. What may be examined: deployment records and self-reported counts, or system access, or an on-site inspection. A clause that permits a self-declaration does not oblige you to install a discovery agent.
- Who performs it. The vendor's own licensing team, or an appointed third party. If a third party is named, there is usually a confidentiality obligation attached.
- Disruption and cost. Most clauses say verification must not unreasonably interfere with normal business, and that the vendor bears the cost unless a shortfall above a stated threshold is found.
- Settlement terms. What happens if you are over: back-dated fees, list price rather than your negotiated rate, and sometimes a support or maintenance uplift on the shortfall.
None of this is exotic and none of it is hostile. It is simply the boundary of the exercise, and knowing it changes the conversation from an open-ended request into a defined one. If your agreement is silent on audits altogether, which happens with self-serve and smaller subscriptions, then what you have received is a sales enquiry with an official tone, and it can be answered on your own timetable.
Count your own numbers before you send any
The single most valuable hour in this process is the one you spend producing your own count before you reply. Not because you plan to argue, but because a number you have derived yourself is a number you can defend, and a number you cannot produce is one you will end up accepting.
For most modern software the count comes from three places, and you want all three because they disagree.
- The vendor's own admin console. Almost every subscription product will tell you how many seats are assigned and how many are provisioned. Export it with a date on it.
- Your identity provider or directory. Who actually has access, including the accounts of people who left, service accounts, and contractors.
- Your purchase record. What you actually bought: the order form, the quantity on the last invoice, and any amendments since. This is your entitlement, and it is the number the vendor will compare against.
Write the three numbers side by side. If they agree, you have a five-minute reply to send. If they do not, the difference is the whole conversation, and you now know about it before the vendor does.
Where the numbers usually disagree
Genuine over-deployment happens, but a surprising share of apparent shortfalls turn out to be definitional. It is worth checking these before conceding anything.
- Deactivated but not deleted. A suspended or deactivated user often still occupies an assigned seat in the console. Removing them is the fix, and doing it before you report is legitimate housekeeping, not evasion.
- Duplicate identities. The same person with a personal login, a single sign-on identity and a legacy account from a migration counts as three users in a naive export.
- Service and integration accounts. Some agreements exempt non-human accounts, some explicitly count them. This is a contract question, not a technical one.
- Named user against concurrent user. Two different licensing units with wildly different counts. Make sure both sides are measuring the same one.
- Devices against people. A licence sold per device is not satisfied by counting employees, and a licence sold per person is not breached by someone using two laptops.
- Test, staging and disaster recovery installations. Many agreements price these differently or exclude them, and many discovery reports include them by default.
- Editions and features. Being over on the premium tier while under on the standard one is a mix problem, not a volume problem, and it has a cheaper answer.
Each of these is a normal, arguable point. None of them requires a specialist. What they require is that you have looked, because the report you are sent will not have made these distinctions for you.
What to send, and what to leave out
Answer the question that was asked, in writing, with the date the count was taken and the method used to take it. Precision here works in your favour: a reply that says how the number was produced is much harder to replace with a different number later.
Three habits are worth keeping. Route everything through one named person, so the vendor is not collecting inconsistent answers from four teams. Keep the exchange in email rather than on calls, so what was agreed is recorded. And send the specific data requested rather than a broader export, because a full directory dump invites questions about products that were never part of the request.
If the request goes beyond the clause you read at the start, say so plainly and reasonably. Asking for the notice the contract requires, or declining an on-site inspection where the agreement provides for self-declaration, is not obstruction. It is the agreement working as written.
If you really are over
Sometimes the count is simply higher than the entitlement. That is a commercial problem with a commercial answer, and it is worth remembering that the vendor's preferred outcome is almost never a penalty. It is a larger contract.
Two things determine what it costs you. The first is whether you can reduce the count before settlement: seats reclaimed from leavers and duplicates are seats you do not have to buy, and reclaiming them is usually the fastest money in the exercise. The second is timing. A shortfall settled as a standalone invoice is priced as a shortfall. The same shortfall folded into a renewal or an expansion is priced as a deal, because the vendor is now selling rather than collecting.
That is the argument to make explicitly: bring the true-up and the renewal into one conversation, ask for the additional quantity at your existing negotiated rate rather than list, and treat back-dated fees as a line to be discussed rather than a fixed amount. The wider tactics are in our guide to negotiating a SaaS renewal, and they apply here with more force than usual, because you are both buying and settling at the same table.
If the shortfall is large, take advice before agreeing figures. The point of counting early is that you get to decide whether it is large while there is still time to act.
Make the next one routine
An audit is only stressful when the answer has to be assembled from scratch. The organisations that find these requests boring are not the ones with better tooling. They are the ones where the entitlement was written down at purchase and checked occasionally since.
The minimum useful record per product is small: what you bought, how it is counted, what you are running now, and where the contract lives. Concretely, that means the licence type, the purchased quantity, the unit that quantity is measured in, the date you last checked the deployed count, and a link or attachment to the signed agreement. Our guide to the fields a software register actually needs covers the wider set, but those five are the ones an audit asks for.
Then check it on a cadence rather than on demand. A quarterly comparison of assigned seats against purchased seats, for the handful of products where the count can move without anyone buying anything, is enough to catch drift while it is still cheap to correct. If you have never done this at all, our guide on how to run a SaaS audit is the wider version of the same exercise, done for your benefit rather than a vendor's.
The distinction matters more than it sounds. A self-audit finds unused seats you can remove and money you can save. A vendor audit finds extra seats you have to buy. They look at the same data, and the only difference is who did the counting first.
The standing position
If you take one thing from this: know your own numbers, keep the contract findable, and never let the first count of your estate be one performed by the party who benefits from it being high.
StackTrackr keeps the licence type, the seat count, the renewal date and the signed agreement on one record per product, so the answer to a verification request is a page you already have rather than a project you have to run. You can see how it works or start a free trial.