Software Asset and Licence Compliance Management: Could You Answer a Publisher Audit Letter in One Week?

Why licence compliance is defensive spending with a clear payback

The letter arrives on a Tuesday and it is polite. A publisher would like to conduct a licensing review under the audit clause of an agreement signed in 2016. You have 30 or 45 days to produce deployment data. Somewhere in the estate there is a VMware cluster where a database was installed on one host for a proof of concept, and vMotion has since moved it around freely, and the licensing position for that publisher may now be calculated across every host the workload could ever have run on. Nobody in the room knows the answer, and the people who signed the agreement have left.

This is the shape of the risk. It is not that organisations pirate software. It is that the licensing metrics are complicated, they are contract specific, and infrastructure changes daily while entitlements sit in a PDF folder. Oracle counts processors with a core factor table. Microsoft SQL Server per core licensing carries minimum core counts per virtual machine. IBM sub capacity licensing requires the ILMT tooling to be deployed and reporting. SAP has a documented digital access model for indirect use. Java and virtualisation licensing both changed materially in recent years, which caught organisations whose estates had not moved at all. Every one of those is a rule your infrastructure team has never read.

What Flexera, Snow, ServiceNow and USU actually leave you doing

These are serious enterprise products and if you have a large estate you probably already run one. Flexera One and Snow both bring deep publisher content libraries and strong normalisation of raw discovery data, which is genuinely hard work you should not repeat. ServiceNow Software Asset Management is the obvious choice if your configuration management database already lives there. USU is well established, particularly across European enterprises.

The gap is on the entitlement side and it is structural rather than a product flaw. These systems encode the publisher's general rules. Your position is decided by your contracts: a legacy agreement with grandfathered metrics, an unlimited licence agreement with a certification date, affiliate definitions that determine whether an acquired subsidiary is covered, migration and downgrade rights negotiated in a renewal, development and test exclusions, territory restrictions. Getting that into any of these tools is a manual interpretation exercise performed by a consultant, and when the contract is ambiguous the tool records somebody's opinion as if it were data. The second gap is virtualisation topology. Whether a cluster boundary limits your exposure depends on your architecture, your controls and, frankly, on an argument you may have to make. Content packs give you a generic answer. And the third is cost: these platforms are priced for large enterprises and the total including implementation and the consultants who interpret your contracts is often comparable to building exactly what you need.

Problem 1: your entitlements live in PDFs and nobody has read them all

The purchase orders are in the finance system. The agreements are in a legal repository or a shared drive. The amendments are attached to emails. Support renewals are in the procurement tool. To answer what you own for one publisher, someone assembles a story from four systems and hopes nothing is missing, which is why organisations under audit routinely discover entitlements they had forgotten they bought.

What a build does: an entitlement register where every entitlement is a structured record with publisher, product, metric, quantity, effective and expiry dates, the specific contract clause it derives from, and the restrictions that apply. Document extraction gives you a first pass at converting contracts and order forms into candidate entitlements, and a human confirms each one, because the interpretation is the value. The register is versioned, so when a renewal changes a metric you can still reconstruct what you were entitled to during any past period. That last property is what makes an audit defensible rather than a negotiation from memory.

Problem 2: discovery tools disagree and virtualisation makes it worse

Intune sees managed endpoints. Your configuration manager sees domain joined servers. Tanium or Lansweeper sees more but names things differently. vCenter knows the cluster topology. The cloud accounts have their own inventory and their own tags, applied inconsistently. Each tool counts a different population, and none of them knows that the two hosts added to a cluster last month just changed a licensing position.

A build normalises all of it into one asset model with an explicit source of truth per attribute and a reconciliation queue for conflicts. Crucially it holds topology: hosts, clusters, the boundaries you enforce, and the history of which workloads ran where. For publishers whose metrics depend on the potential for a workload to move, history is the argument, and if you cannot produce it you concede the maximum. Cloud adds its own model, since bring your own licence rules, dedicated host requirements and instance sizing all change the calculation.

Problem 3: the metric calculators are contract specific and you cannot configure them

A licensable position is a computation and it differs per publisher and per agreement: processor counts with core factors, per user with definitions of an authorised user, per employee metrics that ignore deployment entirely, sub capacity counts that only apply if the required measurement tooling is deployed and reporting continuously.

What a build does: implement calculators as versioned, testable rules with the inputs and the reasoning recorded alongside the output. The output is not a number, it is a number with a derivation showing which assets were included, which entitlements were consumed, which rule version applied and which assumptions were made. When you disagree with an auditor, the conversation is about a specific assumption rather than about whether your tool is right. The same design lets you model an alternative interpretation side by side, which is exactly what you need when preparing a negotiating position.

Problem 4: drift happens daily, reporting happens quarterly

Someone adds two hosts to a cluster. A team spins up database instances for a load test. A subsidiary is acquired and its estate joins the domain. Each of those can move an effective licence position overnight, and in most organisations it is discovered at the next annual review, by which time it is a year of exposure rather than a conversation with an engineer.

A build treats drift as an event. Positions recalculate on a schedule and on change, and the alerts go to a named owner with the specific cause: this cluster grew, this instance count rose, this user population changed. Set thresholds by publisher risk rather than uniformly, because two extra endpoints on a common product is noise and one new virtual machine in a database cluster may not be. This is the feature that converts software asset management from an audit response function into a continuous control, and it is where the money is actually saved.

Problem 5: the audit response itself is a project every time

When the letter arrives, most organisations spend weeks assembling deployment extracts, reconstructing entitlements, and arguing internally about interpretation before they have said a word to the publisher. That preparation cost is often larger than people admit, and it recurs.

A build should produce an audit pack on demand: the position per product with its derivation, the entitlement evidence with source documents attached, deployment data with the discovery method and date, the topology history, and a documented list of assumptions. Snapshot it immutably, because your position at the audit date is the artefact that matters and it must not shift while the audit runs. Organisations that can produce that in days rather than weeks negotiate differently, and it shows in the settlement.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering the entitlement register, deployment ingestion with virtualisation topology, and calculated positions for your highest risk publishers runs $70,000 to $150,000 and ships in 12 to 18 weeks. Adding drift alerting, historical snapshots, the audit evidence pack, scenario modelling for renewals and coverage of the remaining publishers brings the total to $200,000 to $480,000 across 8 to 14 months.

What pushes cost up: the number of publishers you genuinely need modelled, since each metric family is real work. Cloud estate, because bring your own licence rules and dedicated host requirements add a second topology model. Multiple discovery tools with poor overlap. Acquisitions, where the entitlement history of the acquired entity is frequently incomplete and affiliate definitions decide whether you are covered at all. And contract volume, because converting a decade of agreements into structured entitlements is the largest single line in most of these projects.

What keeps cost down: doing one publisher end to end first, usually the one whose audit would hurt most. It proves the model, and the second publisher costs a fraction of the first.

Build versus buy, and when buying is right

Buy if you are under about 500 employees with a straightforward stack of cloud subscriptions and a couple of on premises products. A contract folder, a discovery tool and a disciplined spreadsheet are proportionate and a build would be theatre. Buy Flexera or Snow if you need broad publisher coverage across thousands of titles quickly and your estate is conventional, since rebuilding their normalisation content would be foolish.

Build when two or more apply. Your exposure is concentrated in a small number of publishers whose metrics are contract specific, which is the usual pattern. You have a virtualised or cloud estate where topology decides the position and generic content packs give you the worst case answer by default. You have grown by acquisition and hold multiple contract lineages. You have been audited and found the preparation cost unacceptable. Or you have priced a packaged platform and found the licence plus implementation plus contract interpretation consultancy is in the same range as owning something built around your actual agreements.

How to choose a developer

Ask them to explain how they would calculate a position for a database product running on a virtual cluster. A developer who has done this asks about cluster boundaries, host history, vMotion configuration and which contractual interpretation you are relying on. One who says they will count installations has not met an auditor.

Ask how they would represent an entitlement whose metric changed at a renewal, and insist on versioned effective dated records. Reconstructing a past position is the whole point.

Ask what they would put in the audit pack and whether positions are snapshotted immutably. If positions can be recomputed and silently change during an audit, the tool is a liability rather than a defence.

Ask who owns the code and settle it in writing before kickoff. You should hold the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. A system whose purpose is reducing dependence on a publisher's version of the truth should not create a new dependence on a vendor's version of your data.