Be Mindful of Historical Usage When Licensing Microsoft Products Under SPLA

The Services Provider License Agreement (SPLA) is Microsoft’s preferred licensing option for businesses wanting to use Microsoft products in support of hosted software solutions made available to end users over the Internet. For many companies, SPLA is a good fit, in that it incorporates a monthly reporting mechanism, rather than an up-front license purchase, and allows hosting providers to float their usage up or down as demand for the hosted solutions increases or decreases.

However, SPLA also carries risks, notably including the risk of monetary exposure arising from audits. Microsoft’s licensing rules can be confusing and counter-intuitive, and in the event of an audit, licensing errors typically are magnified due to the fact that SPLA gives Microsoft the right to extract payment of historically unreported amounts at higher than list prices for the products in question. As a result, an error that may have a $5,000 price tag at monthly rates can result in a compliance payment of $250,000 or more in the event of an audit that incorporates a 36-month look-back period.

In response, many business take a pro-active approach to becoming experts on applicable licensing rules and ensuring that they implement processes and procedures that allow them to accurately measure and report on their monthly usage under SPLA. That step certainly is critical. However, what many businesses fail to do – and are surprised to learn that their agreements with Microsoft require them to do – is keep records of their historical usage.

Microsoft’s current-form Business and Services Agreement states:

Customer must keep accurate and complete records relating to all use and distribution of Products by Customer and its Affiliates.

Therefore, Microsoft has a right under that master agreement – which underlies most SPLAs – to expect companies to be able to demonstrate what their historical usage levels have been during the term of an audit. However, of equal importance is the fact that data regarding historical usage often is the only thing that will prevent Microsoft’s auditors from making incorrect assumptions about what those historical usage levels have been. Absent that data, the auditors will use other information – such as server creation dates or customer contract dates – to calculate how long unreported usage has lasted. In some cases, that information may lead to substantially accurate results, but in many cases it does not.

Our recommendation to our clients is not only to gather sufficient data on a monthly basis to allow a complete and accurate calculation of current usage, but to save those data, along with summary reporting that reflects those calculations, in a repository that can be accessed in the event of an audit. If errors have been made throughout an audit period, then the company can make a decision about whether it makes sense to disclose the existence of the repository during the audit. However, when the auditors have made mistakes or poor assumptions, those data may mean the difference between a zero-gap audit and a crippling settlement payment.