Common ServiceNow Software Asset Management Professional Mistakes and How to Avoid Them

Why Software Asset Management Professional programs go wrong quietly

Software Asset Management Professional brings discovery data, normalised software models, entitlement records and reconciliation results together in one place. That is also why its mistakes are hard to see. Each part of the chain can look complete on its own while the compliance position it produces is wrong, and the error only surfaces when a publisher audit letter arrives or a renewal quote does not match what the records predicted. The mistakes below are grouped by the stage of the chain where they are introduced, with the symptom a team sees, the damage it does and the prevention that belongs in the process rather than in a one-off cleanup.

Mistake: treating discovery coverage as complete

Reconciliation can only count installations that discovery or an imported inventory has reported. Estates often have devices that no source reaches: laptops that rarely connect to the corporate network, servers in a segment the discovery schedule does not include, virtual machines created outside the standard build, and software consumed as a subscription with no local installation at all. The symptom is a compliance report that looks healthy for every product while the service desk keeps finding software the report does not know about. The prevention is a coverage measure that compares the devices discovery has seen against the devices the hardware records and the directory say exist, reviewed before any licence position is presented. Gaps are listed with an owner and a date, not assumed away.

Mistake: loading entitlements without the terms that govern them

An entitlement record that holds a quantity and a purchase date is not an entitlement. Publishers license by device, by named user, by processor or core, by concurrent use and by subscription period, and the same product can carry different rights under different agreements. Programs that load the quantity and leave the metric, the maintenance dates, the upgrade and downgrade rights and the geographic or affiliate restrictions blank will reconcile against a number that does not describe what the organisation may actually run. The damage appears as a confident over-statement of headroom, followed by a shortfall nobody expected. Prevention is a minimum field set for every entitlement, with the agreement document or order confirmation attached, and a rule that an entitlement with missing terms is excluded from the published position until the terms are found.

Mistake: leaving the normalisation backlog to grow

Discovery reports software under the names the installers wrote, and the platform normalises those names to publisher, product, version and edition so that installations can be matched to entitlements. Software the content service does not recognise lands in a backlog that someone has to classify by hand. Teams that never work the backlog end up with a growing share of installations that count against nothing, and a compliance report that silently ignores them. The symptom is a reconciliation that looks stable while the unrecognised count climbs. Prevention is a weekly review of the backlog, starting with the publishers that carry audit risk, and a record of each manual classification so the next person does not repeat the research.

Mistake: counting every installation as licensable

Not every installation consumes a licence. Development and test copies, disaster recovery instances, secondary use on a second device for the same user and installations covered by a virtualisation or passive failover right are all treated differently by different publishers. A program that counts all of them will over-buy at renewal and may still be challenged in an audit for the installations that should have been counted differently. The reverse mistake is to exclude an instance because the team believes it is covered when the agreement says otherwise. Prevention is to record, per product and per agreement, which installation types are exempt and under what condition, and to capture the environment and purpose of a device in the records so the counting rule can be applied by the platform rather than by memory.

Mistake: reconciling once and calling the program done

A compliance position is a snapshot. Installations change daily, users join and leave, agreements renew and publishers change their terms. Programs that run one reconciliation for a project milestone and present the result as the licence position are reporting history within weeks. The symptom is a dashboard that nobody trusts because it never moves, or that moves only when someone remembers to run it. Prevention is a fixed reconciliation cadence per publisher tier, with the result reviewed by a named person who can explain each movement since the last run and sign off that the position can be shown to procurement and finance.

Mistake: running the program inside IT alone

Software asset records are only as good as the purchase, renewal and leaver information that feeds them, and most of that information is held by procurement, finance and human resources. When a purchase is made without the entitlement being recorded, or a renewal is signed on the strength of a quote rather than the reconciled position, the records drift from reality without anyone in IT having done anything wrong. The symptom is an entitlement record that does not match the invoice when the auditor compares them. Prevention is a documented path by which every software purchase and renewal creates or updates an entitlement before payment is approved, and a leaver process that triggers licence reclamation rather than leaving seats assigned to accounts that no longer exist.

Mistake: reclaiming licences without a policy

Usage data makes it tempting to harvest licences from devices where a product has not been opened for a while. Done without rules, this produces re-installation requests within days, irritated users and a reclamation figure that cannot be trusted because the same seat is counted as saved more than once. Prevention is a reclamation policy agreed with the business: the inactivity period per product, the notice the user receives, the exceptions for roles with seasonal use, and the way a reclaimed seat is recorded so that savings are counted once. The platform can automate the workflow, but the rules have to exist before it is switched on.

Mistake: measuring the program only by savings

Savings are the easiest number to show a sponsor and the most misleading one to manage by. A program judged on savings alone will reclaim aggressively, defer purchases that are needed and under-report shortfalls that would spoil the figure. The compliance position, the coverage of the estate, the age of the entitlement evidence and the time it takes to answer an audit request are the measures that show whether the program is protecting the organisation. Report savings alongside them, not instead of them, and make the compliance position the first line of any summary that reaches the sponsor.

Mistakes that look like success until the first audit

Software asset programs often do not fail on the day they go live. They fail later, when a vendor sends an audit letter or a renewal arrives at a figure nobody expected, and the records turn out to have been wrong for a year. The mistakes below are the ones that recur often in practice. Each has a visible symptom, an effect on the business and a prevention step that can be built into the process before go-live.

The duplicate model problem in more detail

Duplicate product models are a mistake that often corrupts the first report. Discovery tends to report the product name as the installer wrote it, and different teams enter the purchased name from the invoice. The two never match exactly, so the platform treats them as separate products. The effect is subtle: the purchased product shows zero installations, the discovered product shows a large count, and both figures look plausible on their own. The prevention is a naming rule agreed before loading, and a review of every product whose installed count is zero but whose purchased count is not. That review should happen before any figure goes to a renewal discussion.

A procedure for catching mistakes before the audit does

1. Pick the products with the largest purchased spend and check their entitlement records against the agreements, field by field, including the metric and the reassignment rule.
2. List every product model that shares a vendor name with another, and confirm that each installation maps to the product it actually belongs to.
3. Compare usage figures for the same products from two collection methods, and investigate any product where the gap is larger than your team can explain.
4. Check that every active subscription has an owner who has confirmed the product is still needed in the last review cycle.
5. Run a test reconciliation for one product as if an audit letter had arrived, and time how long it takes to produce the installation evidence.
6. Record the outcome of each check in the governance log, with the person who signed it off.

Why the reassignment rule matters more than the count

A quantity on its own says very little. Two agreements for the same number of seats can have different rights: one may allow a seat to move to a different person when the original user leaves, and another may tie the seat to a single named individual for the life of the term. A program that records only the number will report reclaimable licenses that cannot in fact be reclaimed. Capture the rule with the quantity, and when the rule is unclear, put the product in the open-question list and get the answer from the vendor’s written terms rather than from the account manager’s summary. The audit trail evidence article covers what an audit record needs in order to show who confirmed a change and why.

Frequently asked questions about avoidable errors

Is it a mistake to exclude a product from the first scope?

No, provided the exclusion is recorded and the reason is written down. The mistake is leaving products out without anyone knowing they were excluded, because the gap then appears in an audit rather than in a planning meeting.

How do we tell whether a usage figure is trustworthy?

Ask how it was collected, how often, and whether a second method agrees for a sample of devices. A usage figure with no stated collection method should be treated as an estimate, however precise it looks in a dashboard.

Should we correct the records before or after an audit letter arrives?

Before, always. Corrections made after a letter arrives look like an attempt to change the evidence, even when they are honest, and they weaken the position of the organization in the audit discussion.

What is the cheapest mistake to fix?

A naming duplicate caught at loading time. The same error found during an audit can cost a negotiation, a settlement and a rebuilt report, so the review effort is always worth spending early.

Next step

Checking the largest products often reveals whether the errors are isolated or systemic. The testing and acceptance checklist for this module can be used to confirm the corrected records.