CPOR, DIPOR with a bit of DIOR - Microsoft Cloud usage attributions for Partners - EXPLAINED

As a valued Microsoft Partner you most likely noticed, that there are several types of options (CPOR, CUA, DPOR, MBS, PAL and PRACR) to get recognized and rewarded for your impact in the Microsoft ecosystem.
Given their different purpose, you should always choose the option which suits your business needs best and represent the impact recognition you want to drive most.
This article intends to provide clarity on the best possible usage for your scenario, so you are backed by a data driven approach.

 

Let´s quickly summarize all of those insights the overview table shows above:

• CPOR / CUA / DPOR / PAL:  Those KPIs are needed when you want to answer “Who influenced or delivered Azure consumption in the customer tenant?”
• PRACR : This KPI answers “How does a Partner report consumption that has been created by an end customer, but in the partner Azure tenant. ”
• MBS: answers “How much total sales did a partner create for a solution no matter in which tenant it will be deployed, while Microsoft is responsible for collecting the payments.”

As always, those are just the high level comparisons and it is highly recommended to scroll further down to understand the details of the differentiation of each KPI, so that finally the best possible informed decision can be made.
Let’s dive right into it.

 

CPOR - Claiming Partner of Record

What it is

CPOR is a claims‑based model where one or more partners can claim servicing ownership of a Modern Work or Dynamics 365 subscription/workload via Partner Center.

Why CPOR exists

• Reduces dependency on customer actions
• Compared to DPOR, it gives the power of reporting to the partner

Key characteristics

• One partner per workload/subscription
• Claim‑based, not permission‑based
• Separate from Azure infrastructure attribution

Read more: How to claim CPOR

 

CUA - Customer Usage Attribution

What it is
CUA attributes Azure consumption to a Systems Integrations partner based on deployment‑level, using an Infrastructure-as-Code approach. It requires that the Partner creates a unique GUID for each solution per customer which should get tracked. This GUID has to be properly registered via Partner Center. Lastly, this GUID needs to be injected in the customers Azure Tenant via the deployment ARM/Terraform Script for the partner solution to successfully close the correct reporting cycle. This method is beneficial to influence the Microsoft internal statistics a Partner drives, but has not impact on his Software Designations he might want to achieve. Besides this, it counts towards Co-Sell visibility and other incentives like e.g. Azure Credits.

Key characteristics

• Scenarios where Azure resources are deployed through an Infrastructure-as-Code approach in the end-customer Azure tenant.
• Individual end customer usage tracking

Why and when is CUA preferred

• High granularity
• Durable attribution
• Strong reporting quality for ACR and Microsoft’s internal analytics that highlight partner impact on an end customers Azure environment

CUA should NOT be used for

• Azure Virtual Machine offers à Instead use the regular Marketplace Azure Virtual Machine offer option
• Offers that make use of Azure Kubernetes Services, VM Scale Sets or Azure Batch, since it does not correctly measure the impact.

Read more: Azure customer usage attribution

 

DPOR -Digital Partner of Record

What it is
DPOR associates one servicing partner to an Azure / Modern Work / Dynamics365 subscription.

Key points

• The power of control is on the customer side, since only the customer can change the ID on the subscription level, necessary for the correct DPOR association.
• Initially created for Enterprise Agreement (EA) contracts, but now also available with Microsoft Customer agreement (MCA) contracts
• Needs to be re-entered when workloads are moving from an EA to a MCA contract.

Read more: Link to a Partner ID

MBS (Marketplace Billed Sales)

What it is

Marketplace Billed Sales (MBS) is the value of partner solutions that customers purchase and are invoiced for directly by Microsoft through the Microsoft commercial marketplace.

Key characteristics

• The solution is sold through Microsoft Marketplace and with that, the Partner does not need to go through the procurement vendor onboarding process
• The customer receives one Microsoft invoice which contributes to a lean procurement process for them
• Applies to SaaS, virtual machines, managed applications, and other transactable partner offers
• Depending on the offer, the hosting location can change. Either the partner Tenant (SaaS), or the customers tenant (Non-SaaS).  Read more about the different offer types here: Azure Marketplace offer types
• Indicates a real commercial adoption, not just a listing on a publicly accessible marketplace
• For partners starting their commercial marketplace journey, it marks important milestones to achieve the status of IP Co-Sell eligibility. Once achieved, their purchasing end-customers can retire the whole amount of Azure consumption from their MACC. This creates a Win-Win for both involved parties (the partner and the end-customer), later down the road.
• Leveraging MBS the right way, unlocks more benefits for the partner described in the Marketplace Rewards (like Azure Credits, Go-to-market support, Signature Event attendance like BUILD or IGNITE, and many more). Read more about this here: Marketplace Rewards
• Shaping the pricing of the offers in the Marketplace is essential, in order to gain the best possible values for the next stage in the Marketplace rewards journey.

Read more: Your Microsoft Marketplace benefits

PAL - Partner Admin Link

What it is
PAL is an automated Azure‑native attribution mechanism that links a partner’s MPN ID to Azure resources in the customer Azure tenant, where the partner is delivering and operating services.

PAL tracks partner’s influence on Azure consumption, based on permissions and scope (subscription, resource group, resource) in the customers tenant.
To enable the automatic tracking, the partner needs to have an account or service principal in the end customers tenant. That identity needs to be associated with the partners MPN-ID.
Lastly, this identity needs to get assigned RBAC permissions on Subscription, resource group or resource level at the end customers tenant in order to get the automatism kicking off and tracking the right impact.
It works across Microsoft Customer Agreement (MCA), Web Direct, and EA contracts.

Key characteristics

• No manual reporting
• Durable (survives EA → MCA transition)
• Recommended default for system integration partners delivering services in customer tenants
• Power of control is on the end customer. His collaboration is required in order to correctly set up the process end to end.

Read more:

• Link to a Partner ID by Using a PAL
• Link a partner ID to your account that’s used to manage customers

PRACR - Partner Reported Azure Consumed Revenue

What it is
PRACR is a KPI where partners report Azure consumption on behalf of a customer for workloads which run in the partners Azure tenant, but utilized by an end customer.

Why it exists
Standard Azure Consumed Revenue (ACR) is tied to a customer and as such, only sees consumption in customer tenants.
Many SaaS ISVs run their solutions entirely in their own tenant, which would otherwise make that Azure usage invisible to be deducted from the real end-customers Microsoft Azure consumption commitment (MACC) and also to Microsoft sales and incentives.
PRACR is the solution for that commercial and reporting issue.

Key characteristics

• Partner reported and manually collected, monthly reported (currently not auto‑detected)
• Applies to SaaS offer which are hosted in the Partner Azure tenant
• IP Co‑Sell benefit

What PRACR is NOT

• A billing mechanism
• A customer‑tenant attribution
• Used for SI/consulting services

Read more: Partner Reported Azure Consumed Revenue