Three numbers should describe every software license an organization holds: what you're contracted to pay for, what's actually been assigned to someone, and what's genuinely being used. In most organizations those three numbers don't match, and nobody notices until a renewal negotiation forces the question. Zluri's license management model exists to keep all three visible and reconciled continuously, not just at renewal time.
Software license management sounds like a simple bookkeeping task until you actually try to keep it accurate. A license purchased for 100 seats might have 85 assigned, of which 60 are actually being used. The gap between those three numbers (purchased, assigned, used) is where money and risk both quietly accumulate.
Zluri treats this as a continuous reconciliation problem rather than a periodic audit. That means tracking exactly what kind of commitment each license represents, keeping cost and actual spend as two separate, comparable figures, and running an ongoing optimization layer that finds the gap between assignment and usage before it turns into a renewal surprise. Licenses are one layer of Zluri's broader spend model; the full map of how they connect to transactions, commitments, and renewals is in how Zluri handles SaaS spend management.
The Four Views Into a License Commitment
Zluri organizes license data into a four-tab hub rather than one undifferentiated list, and each tab serves a genuinely different purpose:
- Licenses: The overview layer. It shows only the currently active license entities for a given commitment, along with the summary KPIs and authorization-status color coding covered below.
- Subscriptions: Commitments that bill on a recurring cycle (monthly, quarterly, or annually) without a hard end date. Their "renewal" is closer to an ongoing continuation than a discrete event. Covered in depth in how Zluri handles subscription management.
- Contracts: Commitments with a fixed start and end date that come up for a defined renewal decision. Covered in depth in how Zluri handles contract management.
- Perpetuals: One-time purchases with no expiry at all.
Treating subscriptions, contracts, and perpetuals as interchangeable is a common source of bad renewal timing: a reminder firing for a subscription that was never going to have a fixed end date, or a perpetual purchase getting flagged for a renewal review it doesn't need. Getting this distinction right at the data model level is what keeps every downstream reminder and report relevant rather than noisy.
Two Fundamentally Different License Types
Underneath any of those tabs, a license itself is one of two types:
- Seat-based: Priced per user or employee, and assignable to a specific individual.
- Quantity-based: Priced against a usage metric the vendor defines (emails sent, messages processed) rather than a headcount.
This distinction matters enormously for optimization. Usage calculation, and everything built on top of it (unused and underused detection in particular), is based on individual user activity, which by definition doesn't apply to a quantity-based license.
A metric-based license can still be tracked for cost and renewal purposes. But it will never show up in a per-user waste report, because there's no individual user activity to measure it against.
The Licenses Tab in Detail
Most license data arrives automatically through direct application integrations, with manual entry available to fill in anything an integration can't supply. Zluri's License Mapper handles most of the connective work, auto-mapping licenses to their associated users and teams directly, with anything left unmapped available for an admin to assign by hand.
The Licenses tab opens with five summary figures worth knowing at a glance:
- Total contracts across the organization
- Total applications those contracts cover
- Cumulative contract value
- The annualized cost attributed to the current fiscal year
- How many renewals fall due in the current month
Editing the cost per license is a direct action from any license's detail view. And every license carries the same authorization-status color coding used elsewhere in the platform:
- Green: Managed
- Black: Needs Review
- Blue: Unmanaged
- Red: Restricted
This gives financial data the same governance context as everywhere else in the system, rather than treating cost as siloed from access status.
How Subscriptions and Contracts Feed License Accuracy
A license record is only as accurate as the commitment underneath it, and the mechanics that keep those commitments current live in their own dedicated layers.
For subscriptions, three settings do the heavy lifting: cost amortization (how a recurring cost spreads across time, so monthly reporting stays meaningful), license assignment precedence (which license entity governs when a plan change leaves two active at once), and Auto Adjust, which keeps license quantity automatically synced with whatever an integration reports, up or down, rather than requiring manual reconciliation every time the vendor's own count shifts. The full mechanics are in how Zluri handles subscription management.
Contracts carry more structural detail (agreement types, document checklists, and a bulk PDF upload pipeline where AI-parsed drafts only go live after human review), all covered in how Zluri handles contract management. Two contract mechanics matter directly for license accuracy, and they're worth knowing here:
- True Ups get tracked as their own distinct agreement type for licenses or services added after the original agreement was signed. They're exactly the kind of mid-term change that gets lost by the time a renewal conversation happens a year later. Without a distinct record of them, nobody can easily reconstruct how or when a license count actually grew over the contract's life.
- When additional licenses get detected through an API mid-term, Zluri creates a new, dated group rather than silently changing a quantity in place. That preserves a timestamped history of exactly how a contract's license count grew, which is a real audit trail for a renewal negotiation rather than a single, unexplainable current number.
One further improvement in multi-tier handling: individual line items can now carry their own duration, so two license entries with the same name but different terms or quantities no longer need to be awkwardly split into differently-named records.
Perpetuals get their own distinct tracking specifically because they don't behave like either: no expiry date, a one-time payment (defaulting to a single payment term), and no recurring renewal decision at all. Keeping these separate from the rest of the license inventory is what prevents a one-time purchase from generating an irrelevant renewal reminder years after it was bought and fully paid for.
Cost and Spend: Two Numbers on Purpose
One of the more consequential distinctions in Zluri's license model is that Cost and Spend are tracked as genuinely separate figures rather than collapsed into one.
- Cost is a projection derived from the contract's own terms: rate multiplied by active licenses, recalculated automatically as license counts change mid-term.
- Spend is what's actually been billed, pulled directly from connected financial transactions.
When those two numbers diverge (a contract projecting $360 a month based on 120 active users while the actual recorded transaction shows something different), that gap is itself the useful signal. It's evidence that a license count changed without a corresponding invoice update, or that billing simply doesn't match the contracted rate.
Treating this as a diagnostic to investigate, rather than an error to quietly reconcile away, is what catches billing discrepancies before they compound over a full contract term. The transaction reconciliation that makes the Spend figure trustworthy in the first place (recognition states, mapping rules, currency handling) is covered in how Zluri handles SaaS spend management.
Staying Ahead of Renewal Dates
Every license and contract event runs on a structured notification system (renewal warnings, payment-due sequences, monthly digests, and cancel-by sequences, each routed to the specific accountable owner rather than an undifferentiated list), covered in full in how Zluri handles renewal management.
One alert is license-specific and worth calling out here: a license-utilization alert fires the moment a contract crosses 80% usage, surfacing the need for a capacity decision before it becomes an emergency purchase at whatever price the vendor names.
Finding the Waste: The Four Optimization Categories
Beyond tracking what's contracted and what's been billed, Zluri runs a continuous layer specifically looking for licenses that are technically valid but shouldn't be:
- Unassigned: Licenses sitting on nobody.
- Undeprovisioned: Licenses still attached to users marked inactive in SSO.
- Unused: Licenses assigned to users with zero activity across a configurable window (30, 60, or 90 days).
- Underused: Licenses assigned to users below a configurable usage threshold (30%, 40%, or 50%).
Together, these four categories make up what Zluri calls Optimizable Licenses, and three related figures quantify the actual financial picture:
- Potential Savings: The count of optimizable licenses multiplied by their monthly cost.
- Estimated Wastage: Optimizable licenses from the prior month that were flagged but never actually unassigned.
- Realized Savings: An annualized figure covering licenses that were both flagged and actually reclaimed.
Keeping wastage and realized savings as distinct numbers matters specifically because conflating them overstates how much has actually been saved versus how much theoretically could be.
Acting on What Gets Found
Flagging waste is only useful if something actually happens next. Three mechanisms handle the follow-through:
Optimization Playbooks run configurable actions against each category: automated where a direct integration supports it, manual tasks routed to an owner where it doesn't. Playbook frequency controls how often the cycle repeats.
Request to Forego is the more distinctive piece, a deliberately consent-first alternative to unilateral revocation. Rather than immediately pulling an unused license, Zluri:
- Prompts the employee directly to confirm whether they still need the license.
- Escalates through a configured number of reminders for non-responders.
- Auto-executes the revocation playbook only once that window fully closes.
- Applies a cooldown period afterward, preventing the same person from being immediately re-prompted in the next cycle.
This exists specifically to avoid the common failure mode of automated license reclamation: IT silently revoking something an employee was quietly still relying on.
Continuous Optimization runs this entire cycle on a defined schedule rather than requiring manual review each time. It periodically flags optimizable licenses, forecasts future license needs, and compares contracted cost against actual usage without a person having to trigger it.
Deciding Who Shouldn't Be Optimized At All
Not every flagged license should actually be touched, and Optimization Inclusion exists to carve out exceptions without disabling optimization organization-wide. A given user can be:
- Excluded from just the Unused category
- Excluded from just Undeprovisioned
- Excluded from all optimization entirely
- Left on the default Included state
Each of these can be set at the scope of one specific application or globally across every license that user holds. Conflicts resolve on a clear rule: whichever level was changed most recently wins, and that decision then reflects consistently at both scopes rather than the two silently disagreeing.
Exclusions only affect future optimization runs, not already-completed savings calculations or reminders already in motion. Excluding someone partway through a Request to Forego cycle doesn't retroactively cancel a reminder that already went out.
The Math Behind "Unused" and "Underused"
Every optimization flag ultimately rests on a usage score, and Zluri calculates this differently for applications and for individual users.
An Application Usage Score combines three factors, each weighted by its relative importance to the final score:
- Average activity volume per user per month
- The average number of distinct days per month any user is active
- The percentage of the organization's total users who actually use the app at all
A User Usage Score works similarly at the individual level, combining:
- The person's current-month activity count and distinct active days
- The three-month trailing average of both
Current engagement gets weighed against a longer baseline rather than a single month judged in isolation.
Zluri doesn't publish the specific weighting percentages behind either score, and it's worth treating both as a multi-factor weighted model rather than assuming or citing exact figures that aren't disclosed. The model's structure, not a precise formula, is what matters for understanding why a given license got flagged.
Why All of This Has to Work Together
None of these pieces alone solves software license management. Tracking contract types precisely without an optimization layer just means knowing exactly what you're paying for without knowing whether it's still needed. Finding waste without a consent-first remediation path just means IT quietly revoking things and generating support tickets from confused employees. And optimization without a Cost-versus-Spend distinction underneath it means acting on projected numbers that might not match what's actually being billed at all.
Getting license spend genuinely under control requires all of these working from the same underlying data at once, not any single piece running well in isolation.
Frequently Asked Questions
Can a quantity-based license ever show up in an "unused" or "underused" report?
No. Usage calculation is based on individual user activity, and quantity-based licenses are priced against a metric like emails or messages sent rather than assigned to a specific person, so there's no individual activity to measure against that threshold. Quantity-based licenses can still be tracked for cost and renewal purposes, just not for per-user waste.
Why would Cost and Spend show different figures for the exact same contract?
Cost is a projection calculated from the contract's own terms, recalculated as license counts change through the term. Spend is what's actually been billed, pulled from real transaction data. They diverge when a license count changes without a corresponding invoice update, or when actual billing doesn't precisely match the contracted rate, and that gap is itself useful information rather than something to explain away before looking at it.
Does Request to Forego mean a flagged license never actually gets reclaimed automatically?
It can still end in automatic revocation, but only after the employee's been given a chance to respond through a configured number of reminders. If nobody responds within that window, the pre-configured revocation playbook fires automatically. The difference from a purely automated model is the consent step built into the middle of the process, not the absence of automation altogether.
If I exclude a user from optimization partway through a Request to Forego cycle, does that cancel reminders already sent?
No. Exclusion only affects future optimization runs. Reminders and notifications already in motion for that user continue on their existing schedule, and any pending automated action tied to a reminder sequence that started before the exclusion was set will still complete as configured.
.svg)
