Temporal Accounting Model

The xAssets SAM engine uses temporal accounting. Every event — a software install, a license purchase, an allocation — is recorded as a dated transaction. When something changes, the engine posts a reversal rather than deleting the original record. This produces a complete audit trail and lets you reconstruct the licensing position for any past date.

This page describes the model. The rest of the chapter and the operational chapters refer back to these terms.

Three Kinds of Transaction

Every entry in the licensing ledger is one of three kinds:

These three kinds form a complete ledger: consumption is the demand side, license evidence is the supply side, and grants are the allocations between them.

Apply Date Versus Calculation Period

Two dates matter, and they are not the same thing.

Apply Date is the date the event actually happened:

• A consumption's apply date is the asset's date in service.
• A grant's apply date is the license's purchase date — or the consumption's apply date if the consumption came later.
• A reversal's apply date is the date of the change that triggered it.

Calculation Period is the window of time you are recalculating:

• It tells the engine which transactions to delete and rebuild.
• It does not change the apply date of new transactions.

The most common confusion is filtering reports by calculation period and missing transactions whose apply date falls outside it. If a server has been in service since 2023 and you calculate only February 2026, the consumption was posted with apply date 2023 and is still there — even though "February" is what you calculated.

Recalculation Deletes Forward

When you choose a start date in the Calculate Software Licensing dialog, the engine deletes every transaction whose apply date is on or after that start date, then rebuilds them. This is intentional and is what makes the position consistent.

Important: Choosing an early start date is destructive — it removes existing transactions and reposts them. The Calculate dialog warns about this. In production, recalculate from the start of the open period only, unless you are deliberately rebuilding history.

Why Transactions Persist

Once posted, a transaction is never silently deleted. If something changes — a license is disposed, an asset is decommissioned, a department transfer triggers a reallocation — the engine posts a reversal rather than removing the original. A reversal is a transaction with a negative metric.

This persistence has two practical consequences:

1. Historical reports are stable. A licensing position you generated and exported in October is reproducible — recalculating today does not erase the October-period view.
2. Counts can look high. A product with 10 installs that has churned through 50 machines over the year may show 50 consumption transactions and 40 reversals. The active count is 10.

What This Means in Practice

• The position is temporal end-to-end. Reports are not "current state" — they are queried for a specific period. Two users running reports with different end dates each get the correct position as of their date. Behind the scenes the engine stores per-period data so this works without recomputation, but the user-facing model is simple: pick a period, see the position as of that period.
• The historical position is preserved. Recalculating from today's date forward is safe. Recalculating from a year ago will rewrite history.
• The system can answer "what did we own on date X?" because every transaction carries an apply date and is preserved through reversals rather than deletion. The per-period storage carries values for every period the engine has processed.

Related Reading

• Consumption, Grant, and Reversal — the same ideas with worked examples
• Recalculation Behavior — operational guidance on when and how to recalculate