Defending unreported SAL counts

Published March 1, 2026Updated May 28, 2026Track HosterReading 9 minutesLevel Practical

When a SPLA auditor says you under reported Subscriber Access Licenses, the claimed count is an argument built from incomplete data, not a settled fact. The defense is to reconstruct the true SAL base for each disputed month and show, with evidence, what should and should not be counted.

The Subscriber Access License, or SAL, is the unit at the center of most SPLA audits. You report a SAL for each user with access to the licensed software in a month. When an auditor concludes you under reported, it produces a count of the SALs it believes you missed, multiplies it by the price file rate, and adds the uplift. That claimed count looks definitive on the page. In practice it is assembled from data that rarely tells the whole story, and reconstructing the true base is where a large part of the exposure usually disappears.

This article is about defending the count itself: where auditors over count, how to rebuild the real SAL base month by month, and what evidence carries the argument. For the wider mechanics, start with how SPLA penalties are calculated.

Why the claimed count is usually high

An auditor builds the under reported count from the records it can see, and those records are seldom complete or unambiguous. Authentication logs capture activity that is not always a licensable user. Customer environments blur together when multi tenant boundaries are not documented. The same access can be counted twice when a user appears in more than one system. Each of these tends to push the count up, not down, and the opening position reflects that bias.

The auditor counts what it can see. The defense counts what is actually licensable.

None of this means the auditor is acting unfairly. It means the auditor is working from partial data and resolving doubt in the vendor's favor. The remedy is not to argue in the abstract but to supply the missing evidence that resolves the doubt the other way, month by month.

Where over counting happens

Most inflated SAL counts come from a familiar set of causes. Knowing them tells you where to look first in your own data.

  • Authentication events treated as licensable users when they were service accounts, test identities, or duplicates
  • Users counted across multiple tenants because multi tenant boundaries were not documented
  • Access that a customer covered under its own license being attributed to your SPLA reporting
  • Dev and test environments counted as production access
  • Inactive or disabled accounts left in the count for months after they stopped being used

Each cause is an evidentiary question, not a matter of opinion. If you can show that a given identity was a service account, or that a block of users sat inside one customer's tenant under that customer's own license, those SALs come out of the count, and the back fee and uplift fall with them.

Reconstruct the base month by month

Because SPLA is reported monthly and audited across a 36 month lookback, the defense has to be built the same way: one month at a time. A defensible reconstruction follows a clear sequence.

1
Pull the source of truthGather sealed daily authentication counts and access records for each disputed month, not a single end of period snapshot.
2
Map users to customersTie every access block to a named customer and tenant, so SALs covered by a customer's own license are separated out.
3
Strip non licensable accessRemove service accounts, duplicates, dev and test identities, and disabled users that were never licensable.
4
Map product versionsConfirm which product and version each user actually accessed, since the rate and rights differ by version.
5
Compare and documentSet your reconstructed monthly count against the auditor's and document the basis for every difference.

The output is a month by month position you can defend line by line, with each removed SAL backed by a record. That is a fundamentally stronger footing than disputing the total in aggregate, which an auditor can wave away.

What the reconstruction can change

An indicative comparison shows the effect of reconstructing rather than conceding. The figures are illustrative only.

Disputed monthAuditor claimed SALReconstructed SALBasis for the difference
Month A520410Service accounts and duplicates removed
Month B610430Access covered by customer's own license
Month C480400Dev and test identities excluded

Across a full lookback, differences like these compound in your favor exactly as the auditor's over count compounds against you. Reducing the base reduces the back fee at the price file rate and the uplift on top of it, because both are calculated from the count.

Evidence is the whole argument

Defending a SAL count is not about rhetoric. It is about producing records that withstand a Big Four auditor's scrutiny: sealed daily authentication counts, customer mapping for each reported block, product and version mapping, and documented multi tenant boundaries. Where you have that evidence, the count moves. Where you do not, the gap stays. This is why reporting discipline pays off long before any audit begins, and why reconstructing it well during an audit is the core of the defense.

A buyer side advisor builds that reconstruction with you, pulls the evidence for each disputed month, and challenges the count where the records support it. Our guarantee applies: we reduce your exposure or we reimburse our service fee, and with gainshare you pay only from verified savings. For the full method, download the SPLA audit defense guide.

If an auditor is already asking questions, our SPLA reporting discipline team hardens your monthly reports so the lookback holds.

The claimed count is an argument. We rebuild the real one.

Download the SPLA audit defense guide for the month by month method to reconstruct your SAL base, map customers and versions, and strip out access that was never licensable.

Download the SPLA Audit Defense Guide
Get a Quote · Book a Strategy Call · The Audit Brief · About · Pricing · Blog · Contact · Privacy · Terms · New York · London Not affiliated with Microsoft Corporation. Independent buyer side advisory only.