Understanding the Microsoft Licensing Statement

Microsoft

Understanding the Microsoft Licensing Statement

(This article was updated on 4 June 2025.)

The Microsoft Licensing Statement (MLS) is a critical document for managing Microsoft software assets, but it’s poorly understood. MLSs are vital for gaining full visibility of your Microsoft Volume License purchase history, and can be requested via your reseller, typically for a fee of around $30. Ensuring this document is accurate and up to date is essential to compliance.

Built on data about customer purchases through volume licensing programs, an MLS is Microsoft’s version of the truth at audit time. An MLS is not to be the total picture, since it excludes OEM software, such as Windows acquired with new PCs, as well as purchases through retailers. These gaps can be filled only with good customer purchasing records.

Navigating the MLS

The MLS is a spreadsheet with a series of tabs.

• The Organisation Summary lists the customer’s subsidiaries, acquisitions, and other business entities. All Microsoft volume software purchased by these entities should be listed in the MLS.
• The License Summary shows the quantity of licenses the customer has purchased, by product and version. It also shows license entitlements gained through upgrades and SA. It’s confusing for many customers, so we’ll look at it in more detail below.
• The Transaction Summary summarises how many volume licenses of each product version the customer organisation has purchased.
• The License Agreements tab lists all of the agreements the customer signed, with the name of the business entity that signed the agreement, agreement numbers, stop and start dates, and the entity’s location.
• The MPSA tab provides a separate summary of any Microsoft Product and Services Agreement (MPSA) purchases not reflected within the Transaction Data tab. This tab will be empty if no MPSA is found.
• The Transaction Data tab is raw data showing each license purchase. Its many columns include the entity that purchased the license, the agreement it was purchased through, the quantity of licenses purchased, the type of license—License and SA, SA alone, Standard (license-only purchases), subscriptions, etc.— the reseller through which it was purchased, and the country of use. It’s the second-most consulted tab and essential for anyone needing precise details about a customer’s purchase history.
• The FAQ and Glossary explains terms used in the MLS.
• The Pivot Data tab contains data used in the License Summary.

Exploring the License Summary

Use the License Summary to develop an Effective License Position (ELP). This compares the customer’s inventory data with Microsoft’s licensing data to determine which products are over (or under) licensed.

This example from a customer’s MLS (MLS dated 2020) shows a customer’s Project Professional licenses. The customer has 40 licenses for version 2019 Professional as seen in the Effective License Quantity column. This row also  shows that 20 of these licenses have current Software Assurance (SA), expiring in 12-24 months. Some or all of these may be deployed as an earlier version (e.g., Project 2010), but active SA entitles the customer to the latest version of Microsoft Project.

When reviewing the earlier versions of Project, you will notice that the Project 2013 row reflects 20 ‘Upgrade License Quantity’. We can deduce from this information that those 20 licenses had Software Assurance, which was not renewed, and therefore, the licenses continued to reside at the 2013 level.

Comparing the License Summary to a customer’s deployment data is not straightforward, since the License Summary shows license entitlements, not deployments. A customer’s inventory data may show 1,000 copies of Office 2016, while the MLS shows 1,000 licenses for Office 2019. Because the customer has SA on Office, its 2016 licenses were upgraded to Office 2019 the moment that product was released. But the customer is still compliant: 2019 version licenses cover the 2016 version deployments via Office’s built-in downgrade rights.

Confusion may also arise with Microsoft 365 purchases.

Typically, these are broken down into their individual 365 components, causing confusion because they’re not displayed alongside the non-365 equivalent software. You may find yourself wondering why you have zero Microsoft Office licenses and then, discover these listed separately under a different product pool for 365 within the License Summary.

Missing Data

Some licenses may appear as upgrades only, without accompanying licenses. Typically, this means that Microsoft has no record of the license purchases, only of SA. Since SA can only be purchased at the time a license is purchased, and it must be continuous throughout, where are those original licenses?

That generally requires combing through the Transaction Data tab or customer purchasing records to uncover the original licenses. Here are some of the common causes of this issue:

• Incorrectly processing an SA renewal for software NOT originally purchased with SA
• Purchasing an SA renewal on software with expired SA. In some cases, a Microsoft amendment may allow a grace period for renewal, and this will not typically be reflected in the MLS.
• Product transitions (eg Windows Server Per Processor transitioning to Per Core) resulting in the software purchase history not being correctly linked in the MLS.
• Bundles renewed as individual components, resulting in software purchase history not being correctly linked (eg Pro desktop).
• Acquisitions that have not been reflected within the MLS.

Exploring the Transaction Data Tab

The Transaction Data tab reflects each individual transaction made. It’s very useful for querying the data within the License Summary tab. If you are importing your MLS into a SAM tool, it’s this transaction data that’s imported. Therefore, it’s vital you can understand and pick apart the data displayed within this table.

To ensure the transaction data is easily digestible, I recommend first navigating to the final column in the table (“Included in License Summary”). Then, filter/remove all licenses NOT included in the License summary. This removes anything not considered a valid license, such as expired subscription licenses, disk kits, etc.

From here, you can utilise the product family columns and locate the products you need to query. Sorting by transaction date can help you track back a “Software Assurance” purchase to the original “License/Software Assurance pack”. By examining the agreement start and end dates, you can follow the licenses through their journey across each renewal. This helps you build a picture of the purchasing history.

Conclusion

The Microsoft License Statement is an important document for managing your Microsoft Software Assets. Given the MLS is Microsoft’s “source of truth”, it can help protect you in audit scenarios and help you optimise your licensing environment.

Customers should regularly request a copy of their MLS and use this to check for errors within Microsoft’s records, whilst also, addressing any possible licensing risks. Any concessions agreed by Microsoft should be clearly visible within the MLS document to prevent future issues. Most importantly, the MLS should accurately reflect what you believe to be your license purchase history. Review/challenge (in advance of an audit) anything that stands out as potentially incorrect.

Use the MLS to assess any potential optimisation opportunities. For example, identifying a surplus of potentially unused licenses can allow for better rightsising and reduce your maintenance bill. You might also locate legacy licenses you weren’t aware of. These may free up newer licenses not being utilised with downgrade rights for coverage.

Can’t find what you’re looking for?