Recalculation Behavior

When you recalculate, the engine deletes transactions from the start date forward and rebuilds them. This page goes deeper on the behavior, the operational implications, and the patterns that keep historical reporting stable.

What Gets Deleted

A recalculation starting at date X deletes every transaction with ApplyDate >= X. That includes:

• Consumptions for assets whose service date is on or after X (or had changes affecting the current consumption)
• License evidence records dated on or after X
• Grants whose apply date is on or after X
• Reversals dated on or after X

After deletion, the engine rebuilds based on current state of assets, licenses, and rules.

What Stays

Transactions with ApplyDate < X are untouched. This means:

• Consumptions posted in earlier periods stay
• Grants from earlier periods stay
• Historical reports for periods before X reproduce identically

This is what makes "recalculate the current period only" a safe operational pattern.

A Worked Example

Starting state at end of March:

Now you recalculate from March 1 (Start Date = 01-Mar):

1. Delete: All transactions with apply date ≥ Mar 1 — that is the SQL03 consumption + grant, and the SQL01 reversal.
2. Re-post: The engine looks at current state and re-posts what should exist for March:
   • SQL03 still in service → consumption + grant get re-posted with apply date = SQL03's service date (which is in March, so the new transactions appear in March)
   • SQL01 still disposed (the disposal happened in March, before the recalculation Start Date does not move it) → reversal re-posted

End state: identical to before, but the March transactions are technically new (different transaction IDs).

This is a no-op recalculation — nothing changed in the underlying data, so the rebuild produces the same result.

Now imagine you also imported a new license on March 25 (after the original end-of-March calculation but before this recalculation). When you recalculate from March 1:

• The new license's evidence transaction is posted with apply date Mar 25
• Grants for any consumptions that the new license can cover are added
• The position for March now includes the new license

This is the expected behavior — recalculating the current period picks up the new license's contribution.

Same-Period Delete vs Different-Period Reverse

Changes processed within the same period that originally posted a grant cause that grant to be deleted outright (because recalculation starts by deleting everything from the start date forward). Changes processed in a later period post reversals instead, preserving the historical position.

Example A — same-period change, grant deleted:

Example B — different-period change, reversal posted:

This is why the recommended operational pattern is to recalculate the current open period only. Routine recalculation produces stable historical reports because reversals are used for cross-period changes; full historical recalculation rewrites everything via deletion and rebuild, which is sometimes what you want but should be a deliberate choice.

When Recalculation Changes Historical Numbers

Three scenarios where recalculation visibly changes the past:

1. You set a Start Date in the past. Going back to last year's start date will delete a year of transactions and rebuild them. Any data quality fixes, license corrections, or rule changes you have made in the meantime will affect how the past is rebuilt.

2. You change the calculation rules and recalculate. The new rules apply to whatever period you recalculate. Historical periods recalculated under new rules may produce different allocations than before.

3. You change a catalog entry's License Type. Consumptions are re-metered with the new type. A product previously per-computer becomes per-core, and the consumption counts for cores instead of devices.

In all three cases, the recalculation is doing exactly what you asked. The implication is just to be aware before doing it.

The Safe Pattern

For routine operations:

Start Date: first of current month (or current quarter)
End Date:   today

This recalculates the open period only. Historical periods stay stable. Reports you generated yesterday still reproduce.

For rule changes (see Customizing the Calculation: Testing Rule Changes):

Start Date: first of current month
End Date:   today

Same pattern. The new rules apply going forward; history is preserved.

When You Genuinely Need to Recalculate History

For each, document the event so future audits know what happened. The transaction-level audit trail is preserved (every transaction has an apply date), but the rationale for any recalculation event lives outside the transaction data.

Frequency of Recalculation

Scheduled nightly is the most common production pattern. See Operations: Scheduling and Monitoring for setting that up.

Related Reading

• Running the Calculation — the dialog and the operational defaults
• Concepts: Temporal Accounting — the underlying ledger model
• Customizing the Calculation: Testing Rule Changes