Zoomed Image
USA
800 691 9120
UK
01225 704844

Capacity Enforcement and Deficit

Software Asset Management Guide
Allocation

Capacity Enforcement and Deficit

Every license has a capacity (Seats). The engine enforces it strictly — once a license is full, the engine moves to the next-best license. When all licenses are full and consumptions remain uncovered, those consumptions are in deficit.

How Capacity Is Enforced

For each license, the engine tracks running utilization as it allocates. When the next allocation would exceed the license's Seats, the engine skips and moves to the next-best license for that consumption. There is no over-allocation — the engine will never grant more than the license allows.

The metric for capacity matches the license type:

License Type Seats Counts Each Grant Uses
Per User Number of users 1
Per Computer Number of computers 1
Per Core Total cores of capacity Asset's CPUCores
Per Processor Total processors Asset's PhysicalProcessors

What Happens When Capacity Runs Out

For a product with more demand than supply:

  1. The engine processes consumptions in affinity order (highest score first).
  2. For each consumption, the engine looks for enough capacity across the candidate licenses to cover the consumption fully.
  3. If enough capacity is available, grants are posted — possibly split across more than one license.
  4. If the available capacity is not enough to cover the full consumption, the engine posts no grants for that consumption. It stays entirely in deficit.

Allocations are all-or-nothing per consumption. A 32-core server cannot be partly licensed — the engine either covers all 32 cores or covers none. The same applies to a per-user consumption: the user is either fully covered or not at all.

This is intentional. Partial coverage is not compliance, and the position should reflect that bluntly.

Because allocations are evaluated in affinity order, the consumptions that miss out when capacity is tight are typically those with the weakest affinity to any available license — not random. To control which consumptions get covered when capacity is tight, the levers are direct assignment (forces specific machines to specific licenses) or rule customization (changes which consumptions score higher).

Reading Outstanding Requirement

On the Licensing Position, the Outstanding Requirement column shows the unmet demand per product, in metric units:

Product Required Allocated Outstanding
Microsoft 365 50 users 50 users 0
Adobe Acrobat Pro 20 devices 15 devices 5
SQL Server Standard 32 cores 32 cores 0
Visual Studio Pro 10 users 8 users 2

A non-zero Outstanding Requirement is a deficit. It needs remediation: either buy more licenses or remove the install from machines you do not need to license.

Worked Example: License Pool Spillover

When you have multiple licenses for the same product with different scoping, the engine fills the affinity-matched ones first and spills over to the unmatched ones for any remaining demand:

Product: Visual Studio 2010
Consumptions:
  - SQL4   (London / IT)
  - DEV3   (London / IT)
  - DONNA  (Bath / Accounts)

Licenses:
  - License A: 2 seats, scoped to London / IT
  - License B: 3 seats, no scoping (Default Location, Default Department)

Allocation:
  - SQL4   → License A (London/IT match, +affinity)
  - DEV3   → License A (London/IT match, +affinity) — License A now full
  - DONNA  → License B (no London match available, spills over)

Result: All three covered. License A fully utilised (2 of 2). License B partly utilised (1 of 3).

This is the typical pattern when an organisation has both site-specific volume purchases and a general-purpose pool. The engine allocates the targeted licenses first to the matching consumptions and uses the general pool for the rest.

Bumping: When New Direct Assignments Push Out Existing Grants

When a license is at capacity and you add a direct assignment, an existing grant may be bumped to make room. The bumped consumption falls back to affinity-based allocation against any remaining licenses. If no other license can cover it, the bumped consumption goes into deficit.

This is a side effect of capacity enforcement — the engine cannot honor a new direct assignment without freeing the capacity, and direct assignments take precedence.

The implication: adding direct assignments to a fully-utilized license is a zero-sum operation. You are not adding capacity — you are reallocating existing capacity to favor specific machines.

Capacity vs Demand Reports

For planning ahead, the diagnostic queries on License Dashboard → Licensing Calculation Steps include:

  • Software Products with Consumptions but no Licenses — products you have installs of but no licenses for at all (immediate concern)
  • All Software Licenses — for sanity-checking that capacity numbers look reasonable

For running deficit reports:

  • The Licensing Position itself shows current deficit per product
  • The Detail Report (see Compliance Reports) lists which specific machines are uncovered

Reducing Deficit

Two ways to close a deficit:

  1. Buy more capacity. Purchase additional licenses for the deficient product, import or enter them, recalculate.
  2. Reduce consumption. Identify machines that have the product but do not need it. Uninstall the software. On the next calculation, those consumptions disappear and the deficit narrows.

For SaaS subscriptions where the vendor controls who has access, the second path is "remove user assignments in the vendor portal" — then re-sync user assignments into xAssets.

Capacity and Recalculation

Capacity is checked at allocation time, using the license's Seats value at that moment. If you change a license's Seats and recalculate:

  • More seats than before → more capacity available, possibly closing deficits
  • Fewer seats than before → less capacity, possibly creating deficits where there were none

For a license whose Seats are reduced below current allocations, the engine reverses the over-allocated grants on the next calculation. This reflects the new entitlement.