A subscription doesn't have a renewal date the way a contract does. It has an ongoing billing cycle that just continues until someone actively cancels it. Treating that structural difference correctly is what keeps a subscription's cost, license count, and cancellation status trustworthy over time, instead of borrowing logic built for a fixed-term agreement.
Subscriptions are a genuinely distinct commitment type in Zluri, separate from Contracts (fixed start and end dates) and Perpetuals (one-time purchases with no expiry). A subscription bills on a recurring cadence: monthly, quarterly, or annually, without a hard end date.
That structure changes what its lifecycle centers on. A contract builds toward a single renewal decision. A subscription centers on an ongoing state that continues by default until it's actively cancelled.
This piece covers the specific mechanics built around that distinction: how cost gets amortized over a recurring cycle, what happens when multiple license entities are active at once, and how quantity stays synced with what a vendor reports without manual reconciliation. It's one layer of Zluri's broader spend model, mapped end to end in how Zluri handles SaaS spend management.
Setting Up a Subscription
Creating a subscription starts by identifying the application it applies to. You can also add a new application inline, or mark it as a non-app line item if it doesn't correspond to a tracked application at all.
From there, the basics: subscription name, the vendor, a required primary owner with optional finance and IT owners, and a start date. An Auto-Renews checkbox controls whether the subscription renews itself automatically ahead of expiry, and a Payment Term setting ties into the cost-amortization logic covered next.
Spreading Cost Across a Recurring Cycle
Because a subscription bills repeatedly rather than once, how its total cost gets spread across time is a real decision, not an afterthought. Cost Amortisation offers several distinct models:
- Monthly spreads cost evenly across every period
- Yearly attributes the full cost to the starting month specifically
- Financial Year attributes it to the FY's own starting month
- Payment Term follows whatever recurring frequency the subscription actually bills on
- Quarter attributes cost once per quarter
- Start Date attributes everything to the initial date
Getting this setting right is what keeps a monthly cost report meaningful. The wrong amortization choice makes a subscription's cost look artificially lumped into one period, instead of reflecting how it actually gets billed over time.
When More Than One License Entity Is Active at Once
A subscription's license terms don't always stay static. A plan change or a mid-cycle upgrade can leave more than one license entity technically active at the same moment.
License Assignment Precedence resolves which one actually governs in that state, using one of two rules: Start Date(the entity that began earlier takes precedence) or Amount (the cheaper entity wins).
This matters for a specific reason. Without an explicit tiebreaker, a subscription with overlapping license terms would have no defined answer for which cost and quantity figure is the current, authoritative one.
Building the License Detail Itself
Beneath the subscription's basic setup, license details capture an optional base price (for subscriptions charged a flat rate covering a set number of licenses), currency, and any setup fees or discounts.
Then come the individual license line items, each carrying: license type (seat-based or quantity-based), name, cost per license, quantity (splittable across multiple license types within the same subscription), an auto-adjust toggle covered below, optional discounts, an optional license term, and an automatically calculated cost per term.
An Apply Cost setting lets the costing method be chosen directly: pro-rata against actual usage duration, or a flat per-month, per-quarter, or per-year calculation regardless of exact days used within that period.
Keeping Quantity Synced Automatically
A subscription's license count can shift on the vendor's own side. An admin adds seats directly through the vendor's console rather than through Zluri, and the tracked record is suddenly wrong.
Auto Adjust exists specifically for this. When it's on, license quantity automatically tracks whatever the connected integration's API actually reports, moving both up and down as needed.
Turning it off means quantity fluctuations on the vendor's side go uncaptured automatically. Manual adjustment becomes the only path to keeping the record accurate, which is worth knowing before assuming a subscription's tracked quantity will always self-correct. This synced quantity is also what the license optimization layer works from; waste detection against a stale count flags the wrong things.
Editing and Status Tracking
A subscription's status shows directly in its name display: Active or Cancelled, an at-a-glance read on whether a given line item still represents live, ongoing billing.
Editing happens through the subscription's own Edit control. Individual licenses inside it can be added, modified, or removed independently, without rebuilding the whole subscription record for a single license-level change. Payment method is similarly editable per subscription, through its own Add Payment Method control, without touching the subscription's core setup.
Why Treating Subscriptions as Genuinely Different Matters
The reason for this distinct handling, rather than folding subscriptions into the contract model, is that the underlying risk profile is different.
A contract's biggest risk moment is a discrete renewal decision on a known date; that decision and the reminder machinery around it are covered in how Zluri handles renewal management. A subscription's biggest risk is quieter and more continuous: a plan nobody's actively reviewing just keeps billing indefinitely until someone remembers to cancel it. And a license count drifting out of sync with actual need doesn't announce itself the way a contract's expiration date does.
Auto-adjust, precedence rules for overlapping entities, and amortization choices tuned to a recurring cycle all exist for the same purpose: keeping that quieter risk from accumulating unnoticed, the way it would if a subscription were just tracked as a contract with no fixed end date.
Frequently Asked Questions
Does a subscription in Zluri ever get a renewal reminder the same way a contract does?
Subscriptions don't have the discrete renewal-date structure a contract has, since they continue on a recurring cycle rather than expiring on a fixed date. Reminder logic tied to a defined end date applies most directly to contracts. A subscription's ongoing status is tracked through its Active or Cancelled state instead.
What happens if a subscription's license quantity changes on the vendor's side without anyone updating Zluri directly?
If Auto Adjust is turned on, Zluri automatically syncs the tracked quantity to match whatever the connected integration reports, in either direction. If it's off, that change won't be captured automatically, and the quantity will need to be updated manually to stay accurate.
Why would a subscription have two license entities active at the same time?
This typically happens during a plan change or mid-cycle upgrade, where the old and new terms briefly overlap. License Assignment Precedence resolves which one actually governs during that overlap, based on whichever started earlier or whichever costs less, depending on which precedence rule is configured.
Can I change just one license within a subscription without editing the whole record?
Yes. Individual licenses within a subscription can be modified or deleted independently through their own controls, without rebuilding or fully re-editing the subscription's overall setup.
.svg)
