Every SPLA report rests on a licensing model chosen for each product: the Subscriber Access License, the SAL, or processor based licensing. Picking the wrong model does not just cost money. It distorts what you report, which is the thing an audit measures. Understanding when each model applies, and how each is counted, is the foundation of accurate SPLA reporting and a cleaner audit.
The two models in plain terms
A SAL is a per user license. You count it by the number of unique users who are authorized to access the licensed software in a month, regardless of how often each one logs in. Processor licensing, sometimes called core based licensing for the relevant products, is counted by the physical hardware that runs the software, by processors or cores, rather than by the people using it. The two models answer different questions. SAL asks how many people. Processor asks how much hardware.
When each model fits
The choice is not always free. The Services Provider Use Rights, the SPUR, sets out which products can be licensed which way, and for some products one model is the only option. Where both are available, the economics depend on the shape of your service. A workload with a small, defined set of users on powerful hardware often costs less under SAL. A workload with a very large or anonymous user base, where counting individuals is impractical, often costs less under processor licensing and removes the need to track every user. The right model is the one that both fits the SPUR and reflects how your service actually runs.
A simple way to think about it
- Few, named users on strong hardware tends to favor SAL
- Many or anonymous users tends to favor processor licensing
- Some products restrict you to one model regardless of preference, so the SPUR comes first
- Public facing workloads where you cannot enumerate users usually require processor licensing
A worked comparison
The figures below are indicative and chosen only to show how the models diverge, not to quote any real price.
| Workload | SAL basis | Processor basis |
|---|---|---|
| 20 named users, dual processor host | 20 SALs | 2 processors |
| Public portal, thousands of users | impractical to count | processors on the host |
| What the audit measures | unique authorized users | physical processors or cores |
Indicative comparison of how the two models are counted, not a quoted price.
Why the choice shapes your audit
An audit verifies the model you reported against the consumption it measures. Two failure modes follow from a mismatched model. The first is under reporting, which is a compliance risk: if you license a public workload by SAL and cannot enumerate the users, the audit may recount it on a processor basis and find a gap. The second is over reporting, which wastes margin: licensing a small named workload by processor when SAL would have been cheaper means you have been paying more than the service required, month after month. Both are corrected by mapping each product to the right model before the audit does it for you.
Mapping discipline is the defense
The structural defense in SPLA is reporting discipline, and model selection is part of it. For every reported block, you should be able to show which model applies, why it applies under the SPUR, the count that supports it, and the customer and product version it maps to. That mapping is what turns a reported number into a defensible one. When the model, the count, and the evidence line up, the audit has little room to recharacterize your position.
Model choice also interacts with how you measure consumption in the first place. For the counting mechanics that sit underneath both models, see calculating SPLA consumption accurately. For how a misreported count becomes a penalty and how that penalty is built, see how SPLA penalties are calculated.
The next step
Choosing and documenting the right model for each product is the quiet work that prevents both compliance gaps and wasted margin. The SPLA Audit Defense Guide sets out how each model is counted, how the SPUR governs the choice, and how to map your estate so an audit confirms your position rather than rebuilds it. Download the guide and check your model choices before your next report.
Count the right way.
The SPLA Audit Defense Guide sets out how each model is counted, how the SPUR governs the choice, and how to map your estate so an audit confirms your position.
Download the SPLA Audit Defense GuideWhen the numbers start to look serious, our SPLA reporting discipline service puts the monthly evidence in order before an auditor ever asks.