The MPSA is an evergreen, transactional agreement built around purchasing accounts and pooled points. Here is how the structure works, where it beats an Enterprise Agreement, and what you need in place before you sign anything.
The Microsoft Products and Services Agreement is available in most parts of the world, and it introduced a structural idea that still shapes how organisations buy from Microsoft: the purchasing account, a buying entity inside your organisation that you set up to order and manage products and services by registering it to an agreement.
A note on currency. This article was first published in 2017 and revised in 2019. Microsoft’s purchasing programmes have changed a great deal since, and the Microsoft Customer Agreement and the Cloud Solution Provider programme now cover much of the ground the MPSA was built for. The structural logic below still explains how transactional volume licensing works, but confirm current MPSA availability and terms with Microsoft or your licensing partner before you plan around it.
The MPSA is a transactional licensing agreement for commercial, academic and government organisations. It is an evergreen agreement, signed by a legal entity, designed for organisations with 250 or more users or devices, and it consolidates Microsoft cloud services, on-premises software and Software Assurance under one contract.
Microsoft’s own description is the clearest statement of who it suits: it works best for organisations that want to license on-premises software, cloud services, or both as needed, with no organisation-wide commitment, under a single non-expiring agreement.
That last phrase is the whole point. An Enterprise Agreement asks you to commit organisation-wide and then holds you to it for three years. The MPSA does not. You buy what you need, when you need it, and the agreement itself never expires.
If you reach 500 users, the Enterprise Agreement starts to offer benefits the MPSA does not — and the MPSA continues to offer flexibility the EA does not. At that size the choice is a genuine trade-off rather than an obvious answer, and it turns on how predictable your demand actually is.
Everything that makes the MPSA adaptable comes from how you structure your purchasing accounts. They sit under the agreement, and they let you sub-divide the organisation by department, region, country or any other line that matches how you actually buy.
Each purchase earns points. Points determine your price level, banded A through D, and levels are assessed per product pool. Points from purchasing accounts of the same type pool together across the organisation, so a decentralised buying structure does not have to cost you the discount that centralised buying would have earned.
Two details are worth getting right, because they are commonly stated the wrong way round:
The practical consequence is that you can cover the whole organisation under one agreement, structured however you like, and still be assessed pool by pool. Understanding which pool a purchase lands in is therefore a pricing decision, not an administrative one.
When you set up a purchasing account you can link more than one purchasing partner to it. Every licence and subscription bought under the agreement counts towards your total points allocation regardless of which partner sold it.
That is unusually customer-friendly. You can put the same requirement to several partners, buy from whoever comes back best, and lose nothing in accumulated volume by splitting the business. The MPSA was designed to involve less paperwork than the programmes it replaced, and this is the part of that design that most directly benefits the buyer.
The MPSA is a purchasing mechanism. It optimises how you buy. It does nothing at all about whether you should be buying in the first place, and that is where most of the recoverable money sits.
Microsoft licensing runs on a range of metrics — per core, per server, per device, per user, subscriptions and management licences — and the hard part is rarely the desktop. It is the server room, where core and processor licensing meets clustering and virtualisation, and where an assumption made two years ago quietly becomes an audit finding.
CerteroX SAM is built for exactly that reconciliation:
Do that work first and the agreement question gets easier, because you are choosing a purchasing structure to fit a demand profile you can actually evidence. Do it afterwards and you will find out what you needed by being told.
To see a Microsoft position computed from metered usage rather than reconstructed from purchase orders, book a demo.
Other posts covering the same ground.
An Oracle Unlimited Licence Agreement is only unlimited within its clauses. What certification actually asks of you, where toxic consumption creeps in, and why the measurement work has to start at the beginning of the term rather than the last six months.
Microsoft's August 2025 Product Terms changes: Extended Term standardised across programmes, Exchange and Skype for Business Server Subscription Editions, the Exchange and Windows 10 ESU programmes, and the Dynamics 365 F&O enforcement dates.
Renew, rescope or exit — an Oracle ULA gives you three routes and a narrow window to choose between them. The questions to settle first, and a six-point health check to see how ready you actually are.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.