Commercial and channel
SKU
Stock Keeping Unit
SKU, Stock Keeping Unit, is the specific product or subscription plan identifier used throughout Microsoft's licensing systems, Microsoft 365 admin center, Entra ID, and the Microsoft Graph API among them, to distinguish one purchasable offering from another, Microsoft 365 E3 from E5, Business Standard from Business Premium, an Enterprise Mobility + Security add-on from the base plan it augments.
Why SKU matters in a Microsoft estate
SKU matters because Microsoft estate decisions often have a commercial owner as well as a technical owner. Clear cost, licence, and partner language helps teams prove value, reclaim waste, and agree the next action before spend becomes harder to challenge.
How SKU shows up in practice
It is the unit that licence assignment, billing, and usage reporting are actually built around at a technical level. Each SKU bundles a defined set of service plans, the individual capabilities like Exchange Online, Teams, or SharePoint that together make up what a plan actually delivers. Understanding that a SKU is a bundle rather than an atomic unit matters in practice because two different SKUs can overlap substantially in the service plans they include, which is exactly how organisations end up with licence duplication, a user assigned both a standalone Teams licence and a Microsoft 365 SKU that already includes Teams, without anyone having deliberately decided to pay for the same capability twice.
Microsoft's SKU catalogue has grown large and, in places, genuinely confusing over time, with historical naming inconsistencies, such as SKUs whose display name and underlying string identifier used in PowerShell or Graph queries do not obviously match, and near-identical-sounding plans that differ in subtle but licensing-relevant ways. That makes working directly from SKU identifiers rather than marketing names the more reliable approach for any script or tool doing licence analysis at scale.
This SKU-level granularity is precisely where licence reclaim and cost optimisation work happens in practice: identifying which specific SKU a specific inactive user still holds, recognising when a user's actual usage pattern, judged by which service plans within their assigned SKU they demonstrably use, would be fully covered by a lower-cost SKU, and spotting SKU-level duplication across a tenant are all queries that operate at the SKU and service-plan level rather than at the coarser subscription or product-family level a billing invoice typically presents. That is why tooling built for licence optimisation needs to work with SKU and service plan data directly through Graph or PowerShell rather than relying on the admin center's summary views alone to catch waste that only becomes visible once you are looking at what is actually assigned and actually used at that level of detail.