We use cookies on our website to analyze website usage and to help secure the website against misuse. Advertising and functional cookies are not used in our site or our web application products.
By clicking “Accept Essential Cookies Only”, you consent to us placing these cookies.
xAssets Development Labs have created a new way to calculate and store Software Asset Management licensing compliance using the same principles which are used in double entry accounting. This is a fundamental architectural shift that solves problems SAM professionals have struggled with for decades.
The system uses advanced matching algorithms to match consumptions against rights, and each are calculated according to license-to-rights expansion rules. Each consumption, each right, and each association all produce accounting transactions which are posted into a book/ledger. Then our query engine utilises their calculations to gather SAM data and compliance data for reports and queries.
Each calculation phase is treated like an accounting period. Changes to the previous period are not permitted because it is closed, so any adjustments due are posted into this period as "catch-up" transactions at the start of the currently open period or calculation. If a consumption or right in a closed period needs to be modified, it is credited out of the old period and debited into the new period with a double entry, just like you would in accounts. This means that your old calculation still returns the same values, and you can track what's changed between the old and new systems.
So you can true-up your SAM at any point in time, apply corrections, and know that the record at that point in time or at any other point in time, can always be retrieved.
Software Asset Management engines typically rely on snapshot-based systems that record license compliance at a single point in time. This introduces blind spots, especially in modern IT environments where visibility of continous compliance is very important, not only to your vendors, but increasingly, compliance and disclosure of compliance is also creeping into agreements with enterprise customers.
A Temporal SAM engine performs time-aware software license compliance calculations and records each step as a transaction. Rather than analyzing assets and entitlements at a single moment, it records changes over time. This includes changes in asset lifecycles, license and contract expiry dates, IMAC changes, user allocations, installations, purchases, assignments, and license rules.
xAssets' new Temporal SAM engine will be released in Q1 2026.
Snapshot based SAM systems:
Temporal SAM engines retain the timeline of all events including installs, removals, assignments, purchases, and rule changes. The result is a continuous transactional audit trail. This results in:
The xAssets implementation models every license and asset transaction with temporal changes at a granularity suitable for corporate audit and reporting. Key innovations include:
xAssets also supports multiple calculation books, these work similarly to accounting books, where you can have different views of the same time period. An internal book can be maintained for internal use, allowing you to model license usage and check compliance at any point in time. When you need to share compliance data with a vendor, for example, during a true-up or audit— the internal book can be copied into a separate "true-up" or "published" book. This published view preserves all calculations and derivations, but presents the data as it stood at that specific point in time, giving vendors a fixed, point in time snapshot of your license position.
Multiple calculation books also allows modelling, so for advanced SAM modelling, you can leave the default rules, assignments and associations in place, but use new settings and new formulae to calculate your SAM position trying different methods.
xAssets provides a configurable license to consumption affinity model with point-scoring rules, and the model is designed to scale for large enterprises.
The xAssets license matching algorithms use deep learning, multiple iterations and intelligent modelling to cover all the following scenarios:
There can be considerable complexity in the calculation of SAM compliance.
Some software titles can be licensed by either core-based licensing or per-server licenses where it might make sense to license the computers with many cores with a per-server license and the computers with fewer cores to per-core licensing.
Some software titles are obviously covered by suites, some software titles can only be used in certain platforms, some software can only be licensed in certain departments, locations, or cost centres, and sometimes software is purchased for specific devices or individuals.
Per-user licensing is becoming more common and there is a continual shift towards SAAS, IAAS, hybrid and other licensing models where cloud based resources are being adopted.
The xAssets calculate engine is deeply configurable, and uses an assignment then weighted affinity model to find the best licenses for each asset to produce the best overall outcome. Then it posts the assignments into the transaction ledger to record the SAM activity in a temporal way.
Organizations need to maintain continuous compliance, especially now this is required by vendors, customers, and many cybersecurity assessments demand it. Traditional snapshot SAM tools are not designed for this complexity. A Temporal SAM engine provides:
Now let's jump into a technical deep-dive to help you understand how the model works:
Understanding the transaction model is key to understanding why temporal SAM is different. The engine uses three core transaction types:
| Transaction Type | Purpose | Key Fields |
|---|---|---|
| Consumption | Records that software is installed on an asset | AssetID, ProductID, ApplyDate (asset's service date) |
| License | Records license capacity available | ProductID, SoftwareLicenseID, Rights/Cores/Processors |
| Grant | Records license allocation to a consumption | AssetID, ProductID, SoftwareLicenseID, ApplyDate |
This is of fundamental importance to Auditors. There are two different concepts of "when":
A consumption for an asset that started service on October 15th will have ApplyDate = October 15th, regardless of when you run the calculation. This is what makes the system truly temporal rather than just "versioned snapshots."
If the consumption is known to have appeared in a closed period, we don't rewrite closed periods, we post the adjustment at the start of the first open period and keep the "DesiredApplyDate" field on the record. This means we can report full consumption coverage without needing to reopen closed periods - because just like in accounting, you never want to change a closed period.
When a license is disposed or a consuming asset is retired, the engine doesn't delete historical grants, instead it posts a reversal transaction with a negative Rights value:
Oct 15: Consumption created (ApplyDate = Oct 15, Rights = 1)
Oct 15: Grant created (ApplyDate = Oct 15, Rights = 1)
Nov 1: License disposed → Reversal posted (ApplyDate = Nov 1, Rights = -1)
Result: SUM(Rights) = 0, COUNT(*) = 2 (grant + reversal)
You can see the complete audit trail. Query "Show October compliance"—the grant existed. Query "Show November compliance"—the reversal cancelled it.
When multiple licenses could cover a consumption, how does the engine decide which one to use? xAssets employs a sophisticated weighted affinity scoring system that evaluates every license-consumption pair across multiple dimensions.
The affinity model is completely configurable by customers.
Each potential match accumulates points from applicable rules. The license with the highest total score wins:
| Affinity Rule | Exact Match | Hierarchy Match |
|---|---|---|
| Department | +3,000 points | +1,500 points (child within parent) |
| Location | +800 points | +400 points (child within parent) |
| Cost Centre | +300 points | +200 points (child within parent) |
| Custodian | +1,000 points | — |
| Core Preference | +1,000 points | — |
Consider a consumption on the JOEBLOGGS PC:
Two licenses are available:
License A (with custodian match): Bath / Accounts Payable / JOEBLOGGS Hambly
Department exact match: +3,000
Location exact match: +800
Cost Centre exact match: +300
Custodian match: +1,000
─────────────────────────────────
Total: 5,100 points
License B (no custodian): Bath / Accounts Payable / (no custodian)
Department exact match: +3,000
Location exact match: +800
Cost Centre exact match: +300
─────────────────────────────────
Total: 4,100 points
Result: License A wins (5,100 > 4,100). The custodian match breaks what would otherwise be a tie.
The engine distinguishes between requirements and affinity:
This distinction matters for compliance: the engine won't accidentally allocate a "London-only" license to Bath assets even if they're in deficit. But if multiple London licenses exist, affinity determines which one is used.
For products licensed by either cores or per-server (like SQL Server), the engine applies optimization:
This prevents wasteful allocations—you don't want to use a processor license covering unlimited cores on a 4-core server when a 4-core license would suffice. Conversely, you don't want to use a 128 core license on one large server when a single server license can covers it, and that 128 core license could cover 32 x 4-core servers.
Many enterprise licenses include rights to use older versions. A Visual Basic 6 license, for example, may cover VB5 and VB4 installations through downgrade rights. The temporal engine tracks this explicitly:
This allows tracking of where license capacity is being used including when it crosses product boundaries.
In enterprise environments, a single consumption may be covered by multiple licenses. Consider this M&A scenario:
Scenario: 32-core SQL Server acquired through merger
Timeline:
- 2023: Company A purchases 16-core SQL license
- 2024: Company A acquires Company B (which has a 32-core SQL server)
- 2024: Company A purchases additional 16-core license to cover deficit
Result in transaction ledger:
- Grant #1: 16 cores from 2023 license (ApplyDate = 2024, when server entered inventory)
- Grant #2: 16 cores from 2024 license (ApplyDate = 2024)
- Total coverage: 32 cores across 2 grants for 1 consumption
Some snapshot systems struggle with this concept. They would show either "covered" or "not covered." The temporal engine shows the complete picture: which licenses contribute, when they were applied, and the historical evolution of coverage.
Products marked as free (SQL Server Developer Edition, Visual Studio Community, Express editions) are handled specially:
This is how the temporal engine handles a realistic scenario:
Timeline:
─────────────────────────────────────────────────────────────────
Oct 1: JOEBLOGGS PC put in service (Bath/Accounts)
Oct 1: SQLACCT4 server put in service (London/IT, 4 cores)
Oct 15: 3-core SQL license purchased (London scope)
Nov 1: JOEBLOGGS PC moves Bath → London
Nov 15: Run compliance report for various dates
Transactions Created:
─────────────────────────────────────────────────────────────────
Type | Asset | ApplyDate | Rights | Notes
Consumption | JOEBLOGGS | Oct 1 | 1 | Software installed
Consumption | SQLACCT4 | Oct 1 | 4 | 4-core server
Grant | SQLACCT4 | Oct 15 | 3 | License purchased (partial)
Deficit | SQLACCT4 | Oct 15 | 1 | 4 cores needed, 3 available
Grant | JOEBLOGGS | Nov 1 | 1 | Location now in scope
Query Results:
─────────────────────────────────────────────────────────────────
"Show compliance on Oct 10":
- SQLACCT4: Not covered (license doesn't exist yet)
- JOEBLOGGS: Not covered (in Bath, outside London scope)
"Show compliance on Oct 20":
- SQLACCT4: Partially covered (3 of 4 cores)
- JOEBLOGGS: Not covered (still in Bath)
"Show compliance on Nov 10":
- SQLACCT4: Partially covered (3 of 4 cores)
- JOEBLOGGS: Covered (moved to London on Nov 1)
Each query returns the compliance position for that point in time, calculated from the transaction ledger as opposed to using archived snapshots.
We cannot be sure we are only vendor who holds this innovation but it appears that most SAM tools today are built on snapshot-based models and lack any transactional basis outside of accumulating source records and treating them as intermediate transactions.
Temporal SAM engines is a definite technological advancement in software asset management. By shifting from snapshots to timelines, organizations gain more accuracy, flexibility, and defensibility in managing software compliance yet are still able to use snapshots for reporting to software vendors.
Free instances are free forever and can show demo data or your data.
