Zoomed Image
USA
800 691 9120
UK
01225 704844

Consumption, Grant, and Reversal

Software Asset Management Guide
Concepts

Consumption, Grant, and Reversal

The three kinds of transaction in the SAM engine are introduced in Temporal Accounting Model. This page works through them with concrete examples.

Consumption (Transaction Type 11)

A consumption is created the first time the engine sees a product as installed on an asset. It records:

  • Asset — the computer, server, or SQL instance the software is on
  • Product — the catalog entry the software was recognized as
  • Apply Date — the asset's date in service
  • Metric — what the consumption costs in license terms (1 right, n cores, n processors, depending on the product's license type)
Server SQL4 (in service Oct 15) discovered with SQL Server 2017 Standard installed
→ Consumption posted: Asset=SQL4, Product=SQL2017Standard, ApplyDate=Oct 15, CPUCores=4

A consumption is posted once and persists until the install ends. It does not move when you recalculate — only the apply date and the asset's facts at that date matter.

Key point: A consumption's apply date is the asset's date in service, not the calculation period. Discovering a long-running server today posts a consumption dated to when that server first entered service.

Multiple Consumptions for One Asset

An asset can have many consumptions — one per product installed. A laptop running Windows 10, Microsoft 365, and Adobe Acrobat has three consumptions.

A SQL Server host with two SQL instances on it has consumptions from both instances. Each instance is a separate asset linked to the host, and each can carry consumption independently.

Free Products

Products marked as free (e.g., SQL Server Developer Edition, Microsoft Express editions, free utilities) generate consumptions but never grants. They appear in install counts but not in entitlement or compliance reports.

License Evidence (Transaction Type 12)

A license evidence transaction records the capacity of a license. It is posted when the license is created or imported, and it is the source of truth for "how many seats do we have?" calculations.

Microsoft 365 Apps for Business — 50 seats — purchased Aug 1
→ License Evidence posted: License=L123, Product=M365B, ApplyDate=Aug 1, Rights=50

The capacity is taken from the license record at the moment the calculation runs. If you import a license today with 50 seats and a purchase date last year, the evidence transaction is dated last year.

Grant (Transaction Type 13)

A grant is created when the engine matches a license to a consumption. It records:

  • Asset — which install the grant covers
  • Product — the consumed product
  • License — the license providing the coverage
  • Apply Date — the later of the consumption's apply date and the license's purchase date
  • Metric — the units of capacity used (1 right per user, 1 core per core, etc.)
Consumption: SQL4 needs 4 cores from Oct 15
License: SQL Server 2017 Standard 4-core license, purchased Sep 1
→ Grant posted: Asset=SQL4, License=L456, Product=SQL2017Standard, ApplyDate=Oct 15, CPUCores=4

If the license is purchased after the consumption, the grant is dated to the license purchase date — the engine cannot grant rights before the license existed.

One Consumption, Many Grants

Multiple licenses can cover a single consumption. A 32-core server can be covered by two 16-core licenses, posted as two separate grants against the same asset, product, and consumption period:

Server: 32 cores
License A: 16 cores (purchased 2024) → Grant: CPUCores=16
License B: 16 cores (purchased 2025) → Grant: CPUCores=16
Total coverage: 32 cores ✓

Reversal (Negative Transaction)

When something changes that invalidates a previous transaction, a reversal is posted as a new transaction with a negative metric — not by deleting the original.

Change Reversal Posted
License disposed Negative grants for everything that license covered
Asset decommissioned Negative consumptions for everything installed on it
Software uninstalled Negative consumption with apply date = uninstall date
Reallocation under affinity changes Negative grant for the old allocation, positive grant for the new one

A complete history of any allocation looks like this:

Oct 15  Grant posted     Rights = 1
Nov 1   Reversal posted  Rights = -1
        ── net = 0, but two records remain in the audit trail

Same-Period Versus Different-Period Recalculation

The behavior depends on whether you recalculate the same period that originally posted the transaction.

Same period (no reversal): If you recalculate the same period that originally posted a grant and the result is different, the original grant is deleted outright (because recalculation starts by deleting everything from the start date forward).

Different period (reversal posted): If something changes after the period closed and the change is processed in a later recalculation, the original grant is left in place and a reversal is posted in the period the change happened. This preserves the historical position.

This is why historical compliance reports are stable when you only ever recalculate the open period.

Reading the Transactions

Day-to-day, you do not need to inspect the raw transaction ledger — the Licensing Position and Licenses queries surface the relevant numbers, and the per-asset Software tab and per-license Allocations tab show the per-record detail.

For audit work or deep investigation, an xAssets administrator can build a query against the SoftwareTransaction table filtered by asset, product, or license to surface the underlying ledger entries. Save such a query under the License menu as "Software Transaction History" so it can be reused without rebuilding it each time.