A recent thread on our Forum opened a discussion around what constitutes a proof of license entitlement. This article explores that discussion in more detail, providing practical tips for recording entitlements in your SAM system in order to generate Effective License Positions (ELPs) and be able to respond confidently & calmly to audit requests.
A license entitlement is the result of an executed contract between your organisation and the software publisher. It provides you with an entitlement to use the product as per the terms listed in the license agreement at point of purchase. In short, the entitlement grants you the right to use a certain quantity of the product, in a certain way, for a certain length of time.
For the purposes of this article we’ll set aside the nuances of the license agreement – elements such as geographic location, minimum quantities, transfer restrictions, license reassignment rights, and so on. All these need to be considered but this article is concerned with how you prove that you own, for example, 100 SQL Server core licenses.
Proof of Entitlement can reside in the following:
None of the above are foolproof. Publisher portals can rarely be relied on, physical media can be counterfeit, serial numbers could be from an illegal key generator (keygen), reseller invoicing may be imperfect, OEM stickers may be forged. For example, in the recent Quest vs Nike case, Quest alleged that Nike used pirated keys, possibly from a keygen.
As such, you need to assess the quality of the entitlement you are relying on to establish the facts of your ELP under internal or external audit conditions. It’s useful, therefore, to think about what an auditor would see as acceptable proof of entitlement.
If you’ve been through an audit you may well have encountered the initial impasse of “I’ll show you mine if you show me yours” – certainly in my experience, publishers and their auditors are often reluctant to state what they believe you’re entitled to run. Why? Well, the burden of proof from a contractual perspective often sits with the licensee. Behind the scenes however, the real issue is that publishers themselves have incomplete, unreliable, and inaccurate records of your entitlement. For example, the MLS provided by Microsoft (their view of your proof of entitlement) isn’t updated to take account of license transfers. Microsoft will provide a license transfer document on receipt of the required paperwork and that is your sole proof of the transfer. Easily lost or forgotten – by both parties.
For this reason, the best approach is to build certainty, and the way you do that is to establish a chain of evidence built from multiple sources. The next section of this article looks at how do that.
Despite potential inaccuracies, as a starting point you should request your entitlement information from the publisher or gather it from their self-service portal. This can be a time-consuming exercise, particularly for long-held entitlements, as they’ll be spread over multiple volume license buying programmes, company entities, and so on. Once you’ve done this, however, you have a reasonable baseline entitlement. In practical terms you may decide to stop at that point, particularly if your usage is significantly less than your entitlement. Remember, auditors will have an incomplete record because they’re relying on the same publisher-supplied data as you.
In my experience, the quality of vendor records varies. I would arbitrarily rank them (in order of completeness and accuracy) as follows, but this is only a subset of publishers – the ones I’ve had to prove entitlement for.
Please follow up in the comments with your own experiences.
Your next step should be look at invoice records, if you have them. As Kylie Fowler from ITAM Intelligence stated in the forum thread:
“An invoice is a legal document and the law and accounting practices mean that if an invoice has been issued it has almost certainly been paid for… …a credit note may have been issued, but this is rare, and to be honest, in a dispute in an audit, the onus would always be on the publisher to prove the credit note existed, not you to prove it doesn’t – it’s impossible to prove a negative.”
Kylie also stated under audit conditions
“a report showing the date of purchase, invoice number, what was purchased etc. was sufficient evidence to prove that we had bought the license with the accompanying support & maintenance”
In practical terms what this means is that you should keep invoices for as long as you use the software. You should also check invoices on receipt to confirm quantities, product descriptions and stock keeping units (SKUs) accurately reflect what you’ve purchased. Also confirm that the license has been allocated to you correctly by the reseller.
Equally important is that you also accurately record this information in your SAM tool. It is very easy to get this wrong – for example Microsoft core licenses sold as two packs, or mistaking a Device CAL for a User CAL. As part of your agreement with your reseller it may be worth establishing a minimum standard for invoice quality. For publishers with SKUs ensure that the reseller includes the publisher SKU on the invoice. This provides a significant improvement in certainty of proof. Your Procurement or Accounts Payable team can help with this.
Physical records include media, boxes, certificates, serial numbers, and product keys. Historically this was the primary source of proof of entitlement, and still is for some vendors, particularly if your organisation doesn’t purchase via volume license programmes. I’m sure many of you will have filing cabinets full of tattered boxes with fading license certificates. Given the rise of counterfeiting, and the ease of acquiring counterfeit goods, physical records are a poor source of proof of entitlement. We don’t have the expertise to confirm a serial number is valid, or that “hologrammed” physical media is indeed genuine. Even so, for some publishers, this is all you will have, and for there to be confidence in the entitlement you should cross reference the physical record with a copy invoice or PO number. Write it on the box, or on the media.
We are now heading into the long tail of sources of proof. Serial numbers, product keys, an entry in a spreadsheet, an assertion from a product owner or users that a license is owned, that sort of thing. If you’ve got here because you’re still scrabbling around to find entitlement to resolve a shortfall, consider whether it may be simpler and more cost-effective to purchase new licenses. Entitlement not in publisher portals, or without invoice or purchase order records, will be difficult to rely on under audit conditions. There may be considerable effort in finding it and getting it accepted by the publisher, time that could be spent on delivering value elsewhere. It’s a question of assessing the risk and balancing it against discovery or repurchase costs.
Once you’ve gathered your entitlement sources it’s time to reconcile them and add them to your SAM system. Your aim should be to include as much reference information as possible about the entitlement. Build a chain of evidence from Purchase Order through to Price Paid as follows:
The invoice should reference the PO, and you should also confirm that the SKU matches the both the Product Description on the invoice and in the publisher’s catalogue. Whilst beyond the scope of this article you should also record the license agreement & product use rights in force at the point of purchase and add the media to your Definitive Software Library. Ideally, scan the evidence chain and attach it to the license record in your SAM tool.
This will save days of work down the line when you receive an audit request. Every link in the evidence chain adds credence to your proof of entitlement. With confidence in your entitlement you can react quickly to audit requests, appearing professional to both your internal stakeholders and the auditors.