ServiceNow Software Entitlement Explained

What a Software Entitlement Is

A software entitlement is a license that grants the right to use a software product. The entitlement specifies which product can be used, how many users or instances are licensed, what features are included, and when the license expires. Software entitlements must be matched against actual usage to ensure compliance with licensing agreements. Over-usage exposes organisations to audit findings and additional charges. Under-utilisation represents wasted licensing investment.

Entitlements can represent different licensing models: named user licenses where specific users are licensed, concurrent user licenses where a certain number of simultaneous users can use the software, or site licenses where everyone within an organisation can use the software. Some entitlements include support, maintenance, or update rights. Others are perpetual, while others require annual renewal.

Where Software Entitlements Live in ServiceNow

Software entitlements are tracked in the Software Asset Management application. The underlying table is the Software Entitlement table, alm_license. Each entitlement record includes the product name, license count or concurrent user limit, license type, start and expiration dates, and the cost. Software Asset Management reconciliation compares installed and discovered software against the available entitlements.

The Software Licence Management feature identifies software installed across the infrastructure through discovery, then matches installed software against purchased entitlements. When discovered software does not have an entitlement, the system flags this as unlicensed software. When an entitlement is nearly exhausted, the system alerts administrators so they can purchase additional licenses before running out.

Entitlement records can be linked to cost centres or business units so that license costs can be allocated appropriately. Some organisations track software entitlements to support showback or chargeback models where departments are charged for the software they use.

A Worked Example: Microsoft Office Entitlement

Suppose an organisation has a Microsoft Office entitlement for 500 named users. The entitlement specifies that 500 specific employees are licensed to use Office. Software Asset Management discovers Office installations and identifies which users have Office installed. If 520 unique users have Office installed, the organisation is 20 users over licence.

The organisation has options: purchase 20 additional licences to cover the over-usage, identify 20 users who can have Office removed and use a web alternative instead, or add those 20 users to an existing enterprise agreement. Discovery and entitlement tracking makes this situation visible, allowing the organisation to manage licensing proactively.

Entitlement expiration dates trigger alerts when a license approaches renewal. The organisation can then decide whether to renew, adjust usage to reduce license needs, or migrate to a different product. Without entitlement tracking, organisations might unknowingly allow licenses to lapse or continue paying for unused licenses.

Common Misunderstandings About Software Entitlements

A frequent misunderstanding is thinking that software entitlements must be managed manually by reviewing invoices and spreadsheets. While some input is necessary, Software Asset Management automates the matching of discovered installations and usage to entitlements. Automation reduces the effort required and improves accuracy.

Another confusion is assuming that if software is not discovered, the organisation does not have a license compliance problem. In reality, unlicensed software is a compliance risk regardless of whether it has been discovered. Discovery processes should be comprehensive enough to find all software in use, and organisations should have procedures for ensuring that any discovered software has appropriate entitlements.

Some organisations incorrectly assume that open-source software does not need to be tracked. While some open-source licenses do not require payment, they do have obligations regarding documentation and source code availability. Tracking open-source software and its licenses is part of comprehensive software management.

Managing Entitlements and Usage Compliance

Effective software entitlement management starts with having accurate, current entitlement records. Organisations should maintain a central repository of all software contracts and ensure that this information is reflected in the entitlement tracking system. When new software is purchased, the entitlement should be recorded promptly.

Regular reconciliation between discovered software and entitlements helps identify gaps and oversights. When discovered software does not match entitlements, investigation is needed to understand whether the software is licensed, whether the license is documented elsewhere, or whether compliance action is needed.

Cost analysis using entitlement data helps organisations understand software spending and identify opportunities to reduce costs. If certain software is rarely used, replacing it with an alternative or reducing the number of licenses might save money. If software is heavily used but licensed through a model that charges per user, switching to a site license might be cost-effective.

What an entitlement record has to prove

A software entitlement record is only useful if it can answer a hard question under pressure: does the organization hold the right to run this product, in this way, for this many people or devices, on the date in question? Many records fail that test. They hold a product name, a count and an expiry date, and they omit the terms that decide whether the count means anything. A license for a fixed number of named users says nothing about installations on shared devices, and a subscription row says nothing about whether the renewal was signed. The record should therefore be built backwards from the evidence an audit or a true-up would demand, not forwards from the fields the tool happens to offer.

For a software asset lead, the practical goal is an entitlement record that a finance colleague and a vendor’s account team would both read the same way. If the record needs a conversation to be understood, it will be wrong the first time it is used.

License metrics and what each one counts

The license metric is the unit the vendor charges against. Getting it wrong can be the most expensive error in software asset work, because the count is correct for the wrong unit. The table covers the common families of metric and the mismatch each one invites.

Read the table as a warning about the record, not only the product. Each mismatch is a field the record usually does not hold, which is why the evidence column matters more than the count.

Building entitlement evidence in the order an auditor would ask

An entitlement that exists only as a number in a tool cannot be defended. The steps below build the evidence trail in the sequence a reviewer typically follows, so that gaps show up at the point of entry rather than during a dispute.

1. Store the contract or order document for each entitlement, and record where the original copy is kept.
2. Record the license metric exactly as the document states it, including any definitions the vendor gives for the unit.
3. Record the quantity, the start date, the end date and any notice period that affects renewal.
4. Record the scope: which legal entity, which business units, and which environments the entitlement covers.
5. Link the entitlement to the software product record and the cost center that pays for it, so allocation and usage can be compared.
6. Note any rights that change the count, such as the right to run an earlier version or to move a license between devices, with the document section that grants them.

Step six is the one often left out, and it can change the answer. A right to run an earlier version can make an apparent shortfall disappear, but only if the record shows that the right exists.

Where the record and the estate drift apart

Entitlements go out of date in predictable ways. The first is renewal: a subscription lapses or renews at a different count, and the record keeps the old figure. The second is consolidation: an organization moves to a new contract and the old entitlements are left open. The third is scope creep: a product bought for one division is installed across the group, and the record still reflects the original purchase. Each of these produces a comparison that looks wrong, and the temptation is to correct the usage data when the entitlement is what needs updating.

A regular reconciliation, run against the contract calendar rather than the usage data alone, catches many of these. Tying renewal dates to the review cycle lets drift be caught while there is still time to act, and the software asset lifecycle controls guidance covers the decisions from request through acquisition and review.

When a shortfall is not really a shortfall

A gap between installations and entitlements is not always a compliance problem. Some installations are on non-production hosts that the contract excludes from the count, some are inactive for a long period, and some are duplicates of the same installation recorded twice under different names. Each of those needs a documented reason before the gap is closed. Closing a gap by purchasing more licenses without investigating it spends money that may not be needed, and it leaves the discovery problem in place to produce the same gap next year.

Equally, a surplus is not automatically a saving. Licenses that are paid for and unused may be needed for a planned project, a disaster recovery arrangement or a contractual minimum. Before reducing a count at renewal, confirm with the vendor’s terms and the internal plan that the surplus is genuinely idle.

Keeping the record useful between audits

Entitlement records are most valuable when someone uses them before a renewal or a purchase, not during a dispute. A short review each quarter, focused on entitlements that renew within the next period, gives the procurement and finance teams time to decide. The vendor reviews guidance covers whether a supplier is meeting the agreed operating need, which is a natural point to ask whether the license count still matches the way the product is used.

Questions about software entitlements

Should an entitlement be recorded for free software?

Record the terms, even where there is no charge. Free products can still carry obligations on use, attribution or distribution, and an audit may ask for evidence that those terms were reviewed.

Who is accountable for the record, day to day?

The software asset lead should own the record, with procurement responsible for supplying the contract and finance responsible for the cost allocation. The asset lifecycle management guidance covers ownership across the asset lifecycle. Ownership that is split three ways tends to produce records that nobody updates.

What evidence do I need for a concurrent license?

Session records over a representative period, kept with a note of the period chosen and why. A single snapshot taken on a quiet day will understate the peak, and the vendor is unlikely to accept it as proof.

Can entitlements be imported from a spreadsheet?

Yes, provided the import carries every field in the evidence list above. A spreadsheet that holds only the product, the count and the expiry date will recreate the problem the record was meant to solve.