Software License Compliance Problems: The 7 That Surface in an Audit, and How to Avoid Them

Why does the compliance project become a discovery tool rebuild?

The common scope failure is spending the budget on the half you already have. Discovery is tangible: an inventory of installations by host, produced in a day, and easy to demonstrate. So the project gets written as better discovery, or as replacing the discovery platform, and the entitlement side gets a line item at the end that never gets built.

The reason is that discovery answers a question people can picture, which is what is installed. Entitlement answers what is permitted, and that lives in contractual prose across twenty years of agreements, ordering documents, amendments and true ups. Nobody can picture it, so nobody scopes it, and the compliance position stays as the difference between a number you have and a number nobody has computed.

The fix is to keep the commercial tool for discovery and normalisation and put the budget into entitlement and calculation. Flexera and Snow carry product recognition and normalisation libraries representing years of unglamorous catalogue work with no competitive value to you, so rebuilding that is money burned. Structure entitlements for your three to five highest risk agreements, build the calculation for the metrics those agreements actually use, and make the position reproducible at a point in time. That is a materially smaller project than a platform, and it is the part carrying the exposure.

What goes wrong when you turn twenty years of contracts into entitlement records?

This is the highest value work in the category and the place projects stall, because the source material is worse than anyone remembers. Master agreements sit in a contract system while the ordering documents holding the actual quantities are attachments in a shared drive, a procurement mailbox and sometimes a former colleague's archived account.

Four failures recur. Quantities appear on ordering documents without the metric, because the metric was defined in a product use rights document that was current at the time and has since been revised several times, so the number alone is meaningless. Amendments and true ups modify quantities without restating them, so the current entitlement is a sum across documents rather than a value you can read anywhere. Migration and upgrade rights carry entitlement forward from products you no longer run, and those rights are frequently the difference between compliant and exposed. And a meaningful proportion of the older documents exist only as scanned images.

The approach that works is two passes with a human in the second. Automated document extraction produces draft records with products, quantities, metrics and dates, then somebody with licensing knowledge confirms every one against the source page, and every record keeps a link back to that page so it can be verified later. Reject any proposal offering a fully automated pipeline. A wrong entitlement nobody checked is worse than no entitlement record, because it produces a position you will act on with false confidence, and wrong in your favour is the dangerous direction since you will never go looking for it.

Why do discovery and infrastructure integrations break after launch?

They break because a licensable unit is not an installation, and the data needed to bridge them comes from systems that change without telling you. Licensing counts physical cores with a vendor core factor applied, named users with minimums per processor, concurrent sessions, devices, employees including contractors, or processor value units. Translating from installations to any of those needs physical socket and core counts underneath a virtual machine, whether hyperthreading is enabled, cluster membership, and which environments are development or test and therefore covered by different rights.

The specific break is silent incompleteness. A new cluster is built and is not in the configuration management database. A host is added to a resource pool and nothing in the licensing view notices. An agent stops reporting on forty servers and the position quietly improves, which is the worst possible failure because it looks like good news.

Two fixes. Where the underlying physical data is unavailable, the correct behaviour is to raise an exception rather than to assume a value, and that exception list should be a first class output because unknown hosts are exactly where audit findings come from. And reconcile the host population against your virtualisation platform and directory on a schedule, alarming on coverage drops rather than on position changes. A compliance figure that improved because data disappeared is the number most likely to be believed and least likely to be true.

What happens when point in time reproducibility is not built in?

You lose the ability to answer the question an audit actually asks, which is about a period rather than about today. If your tooling shows only current state, then a vendor asking about a date two years ago gets a reconstruction rather than a record, and a reconstruction is exactly what an auditor is trained to take apart.

The same gap hurts you internally. When you correct an error in an entitlement record or a calculation rule, you need to show what changed and when, otherwise every prior position becomes suspect and your own counsel cannot rely on any of it. Teams that discover this late end up defending their tooling instead of their position.

Treat the system as an evidence store rather than a reporting tool. Store the discovery inputs, the rules version and the computed result together so any historic position regenerates exactly, keep records append only with no silent edits, and maintain a visible trail from each computed number back to the discovery record and the contract page behind it. That property is the whole difference between a position your counsel will send to a vendor and a spreadsheet that gets dismantled in the first response. It also changes the negotiation, because a vendor who sees a reproducible position with evidence behind each line engages differently from one who sees an estimate.

Should you build custom or configure what you already own?

Configure if your estate is predominantly per user subscriptions with straightforward metrics and no significant core based licensing on premise. Snow, Certero or the software asset management module in ServiceNow will handle that shape competently. ServiceNow in particular is the sensible choice if you already run it and your configuration data is accurate, since it inherits both the strengths and the weaknesses of your configuration management database.

The hybrid is what we recommend for large estates, and we give that advice consistently. Keep the commercial tool for discovery, normalisation and the recognition catalogue. Build the entitlement model and the calculation engine for your three to five highest risk agreements, because those are the ones where a generic reading of a vendor's published policy is dangerous and where your negotiated terms differ from it. Their calculation engines encode a generic interpretation, and when your agreement contains bespoke terms the resulting position is wrong in one direction or the other.

Build the wider picture when you have had an audit letter from any major vendor in the last three years, when licensing decisions are being made implicitly by infrastructure changes nobody reviews, or when renewal negotiations start from the vendor's numbers because you cannot produce your own with confidence. A useful test costs nothing: take your single highest risk agreement and try to assemble its entitlement record from source documents. However long that takes is your real audit response time.

How do hidden costs get into the quote?

Five drivers, unusual compared with other categories and all knowable in advance.

• Contract volume and condition. An organisation whose ordering documents are scanned images from the 2000s faces a materially larger discovery effort than one with a tidy repository. Sample twenty documents before scoping.
• Metric count. Each distinct metric is its own calculation with its own edge cases, so supporting six metrics is not marginally more work than supporting two.
• Virtualisation uniformity. A single platform across the estate is one model. A mix inherited from acquisitions is several.
• Configuration data quality. A licensing calculation inherits every inaccuracy underneath it, and cleaning that up is frequently a prerequisite project rather than part of this one.
• Licensing expertise. Somebody who understands the agreements has to sit in design sessions, and that person is usually scarce and already busy.

The cost that surprises people is legal time. Your licensing counsel needs to define the interpretations the software encodes, because those interpretations carry weight and are not an engineering decision. Price that as a workstream with named people rather than as a review meeting at the end.

What separates a build that works from one that fails here?

The builds that work move the check before the change. Evaluating a proposed cluster expansion or an affinity rule change so it returns a licensing impact alongside a capacity impact is the single highest value feature in the category, because it stops exposure being created rather than reporting it afterwards. Cluster boundaries and resource pool membership are licensing controls whether or not anybody treats them that way, and putting that check into the change process is cheap compared with what it prevents.

The second differentiator is computing contested positions both ways. Where live migration is enabled, several major vendors take the position that licensing must cover every host a workload could run on rather than the hosts it did run on. Whether that applies to your specific agreement is a contractual question for your counsel and it is frequently disputed. Your model needs both numbers, because one is your internal risk view and the other is what the vendor will claim, and a system that computes only one gives you false comfort in whichever direction it was built.

When choosing a developer, ask how they would compute a position for a database product in a cluster with live migration enabled. If they do not immediately ask which vendor and which agreement, they will encode one interpretation and hand you a number with unearned confidence. Ask how a position from eighteen months ago is reproduced, what happens to hosts with missing physical core data, and what they will do with contracts that exist only as images. Then settle repository, cloud account and data ownership before kickoff, because these artefacts encode interpretations of your contracts and cannot sit behind a supplier relationship.