Cloud Private Offers: AWS Private Offers, CPPOs, Microsoft MPOs and Google MCPOs Explained

Hyperscaler GTM Playbook Hub & overview ↗

Cloud Alliances P1 – Overview A1 – Partner Programs A2 – Alliance Team A3 – Funding A4 – Tenancy Model

Co-Sell P2 – Overview B1 – AWS Co-Sell B2 – Microsoft Co-Sell B3 – Google Co-Sell B4 – Co-Sell Operations

Cloud Marketplace P3 – Overview C1 – Marketplace Listings ► C2 – Private Offers C3 – Marketplace Operations

Public marketplace listings handle the commodity end of the market. Private offers handle everything else – enterprise deals with negotiated pricing, custom terms, specific contract durations and, frequently, a channel partner in the middle. Understanding private offers, their multi-party variants and how they interact with commit-drawdown mechanics is the difference between marketplace as a niche billing channel and marketplace as the primary procurement route for large enterprise deals. This post covers the mechanics across all three platforms.

TL;DR

A cloud private offer is a customer-specific marketplace transaction with negotiated pricing, custom terms and a defined contract duration. It is the primary marketplace mechanism for enterprise deals that require negotiated commercial terms.
All three hyperscalers support both direct (ISV-to-customer) private offers and multi-party variants (ISV + channel partner + customer): AWS Private Offers and CPPOs (Channel Partner Private Offers); Microsoft Customer Private Offers and Multiparty Private Offers (MPOs); Google Cloud Private Offers and Marketplace Channel Private Offers (MCPOs).
AWS’s Express Private Offer, announced around AWS re:Invent 2025 (AWS launch post dated 30 November 2025), reduces friction for standard deals by generating private offers from seller-configured pricing rules. Eligible Microsoft MPO purchases and private offers made under resale authorisation can count towards a customer’s MACC; CSP Private Offers do not – their customer pricing and billing are handled by the CSP partner outside Marketplace, while Microsoft handles billing to the CSP partner and payment to the ISV.
Operational mechanics are similar across platforms but the specifics diverge enough that practitioner knowledge from one cloud translates imperfectly. Eligibility requirements for channel-partner variants (country availability, partner-program status) shift periodically.
The most common deal-loss failure mode is offer-expiry before customer acceptance. Configure expiration generously, monitor accepted-vs-pending state actively and treat the private-offer workflow as a sales-stage workflow, not a paperwork exercise.

Comparison at a Glance

Dimension	AWS	Microsoft	Google Cloud
Direct ISV-to-customer	AWS Private Offer; Express Private Offer	Customer Private Offer; CSP Private Offer (no MACC)	Google Cloud Private Offer
Multi-party variant	CPPO (Channel Partner Private Offer)	MPO (Multiparty Private Offer)	MCPO (Marketplace Channel Private Offer)
Pre-committed spend drawdown	EDP	MACC (only for Azure IP Co-Sell Eligible offers)	Eligible Google Cloud Minimum Commitment obligations; MCCP is a separate customer-credit program; eligible direct and authorised-reseller purchases share a cumulative 25% cap on the Minimum Commitment, with MCPO drawdown based on 100% of the final private-offer price (from 9 June 2025)
Marketplace fees	AWS: tiered by pre-tax contract value	Microsoft: 3% agency fee, halved to 1.5% for qualifying customer and multiparty private-offer renewals, charged to the private-offer originator – the ISV for ISV-originated offers, or the authorised resale partner for resale-enabled offers. The standard ISV-originated MPO example applies the fee to the ISV’s partner price	Google: tiered revenue share, subject to eligibility: 3% on standard offers; new-deal private offers at 3% below $1M TCV, 2% from $1M to below $10M and 1.5% at $10M or more; qualifying native renewals, channel shifts and migrations at 1.5% regardless of TCV
Country availability constraints	CPPO geo-restricted; check current eligibility	MPO available in 36 customer markets including Australia, Japan and South Africa; channel-partner tax profiles supported in 35 of those (Canada excluded); verify current eligibility in Partner Center	Channel offer geo-restricted; check current eligibility
2026 notable mechanic	Express Private Offer (re:Invent 2025)	Post-September-2025 unified Microsoft Marketplace	Q1 2026 Partner Network reset

Why Private Offers Exist

Public marketplace listings rarely match enterprise procurement reality. Public pricing is a single point on the pricing function; enterprise deals require negotiated tiers, volume discounts, contract durations beyond the listing’s defaults, payment schedules that match the customer’s procurement cycle and custom terms reflecting the specific commercial relationship. Private offers exist to bridge between the marketplace’s standardised contracting infrastructure and the enterprise customer’s specific deal requirements.

Mechanically, a private offer is a customer-specific marketplace transaction that overlays the public listing’s contract structure with negotiated parameters. Where eligible, marketplace private offers can route through marketplace acceptance and billing workflows and may count against the customer’s relevant cloud commitment, such as Microsoft MACC or Google Cloud Minimum Commitment obligations.

The structural value: private offers preserve the procurement-friction-reduction benefits of marketplace transactions (consolidated billing, lighter vendor onboarding, committed-spend drawdown) while accommodating the commercial reality of enterprise deals. This friction reduction applies to the transactional mechanics – billing infrastructure, contract execution, committed-spend drawdown. It does not eliminate the upstream legal process. In practice, a full enterprise sales cycle involves an NDA at the start of the engagement, a POC or trial agreement where the customer is putting data onto ISV systems for evaluation and an MSA or software licence and maintenance agreement negotiated directly between ISV and customer lawyers – potentially through multiple redline cycles. The private offer is typically created once these agreements are in place. Agreed product terms can be included in the offer through the marketplace’s supported contract mechanisms. The marketplace handles the commerce and acceptance of the offer; the bespoke legal terms are negotiated directly between the parties.

In mature ISV marketplace motions, private offers account for the substantial majority of marketplace transaction value. Public-listing transactions and click-to-subscribe motions still happen but typically serve self-service customer segments rather than enterprise pursuits. The detailed treatment of marketplace transaction motions is in Cloud Marketplace.

Channel Partner Transaction Models

Before examining the mechanics of CPPO and MPO, it is worth mapping the four fundamental ways an ISV can structure a channel-partner transaction. The commercial controls available to the ISV differ significantly across the four, and the choice has material implications for pricing integrity, partner economics and comp design.

Model 1: Customer pays ISV, ISV pays partner on the backend. The customer contracts directly with the ISV and pays the ISV’s invoice. The ISV separately pays the channel partner their agreed margin. The ISV has complete control over partner economics – payment amount, timing and conditions are all ISV-determined. No cloud marketplace involved, and no cloud committed spend (EDP / MACC / Google Cloud Minimum Commitment obligations) can be drawn down against the purchase.

Model 2: Customer pays channel partner, partner pays ISV their cut. The customer contracts with the channel partner and pays the partner’s invoice. The partner pays the ISV their agreed wholesale amount. The ISV cannot control what margin the partner takes – the ISV’s cut is whatever remains after the partner’s margin is applied. No cloud marketplace involved, and no cloud committed spend can be drawn down against the purchase.

Model 3: Standard cloud marketplace private offer. The customer transacts through the cloud marketplace, which bills the customer, deducts the marketplace fee and pays the net amount to the ISV. The ISV then makes a separate backend payment to the channel partner for their agreed share. The ISV controls the terms and amount of this backend payment. The marketplace fee is borne by the ISV. Committed spend drawdown (EDP / MACC / Google Cloud Minimum Commitment obligations) applies where the transaction is eligible.

Model 4: Multiparty private offer (CPPO / MPO / equivalent). The customer transacts through the cloud marketplace. The marketplace pays the ISV their partner price minus the marketplace fee, and pays the channel partner their markup directly and separately. The ISV cannot see the customer adjustment the channel partner applied, and therefore cannot see the channel partner’s final margin or the customer-facing price. Microsoft’s own documentation for ISVs confirms this for MPOs: the ISV has visibility only to its configured partner price and its own payout, while the channel partner separately sees the customer adjustment and the customer-facing price. The evidence for AWS is narrower – CPPO cancellation and billing-adjustment notifications to the ISV omit the refund amount to protect partner margin – consistent with the same practical outcome but not an equivalent documented guarantee that the ISV can never see the customer price through any AWS report or API. The marketplace fee applies only to the ISV’s partner price; the channel partner’s markup is paid fee-free.

The loss of pricing visibility in Model 4 mirrors the arrangement in Model 2: the ISV sets a wholesale price and the partner determines their own margin independently. This is not a flaw introduced by marketplace mechanics – it is how channel economics work whenever the partner is the customer’s commercial counterparty. CPPO and MPO bring that existing arrangement into marketplace infrastructure while preserving the partner’s commercial autonomy. For the ISV, the partner price set in the offer is therefore the only commercial lever available. Setting it too high leaves the partner with insufficient margin to be competitive; setting it too low compresses ISV economics unnecessarily.

Mature versus early-stage channel programs. ISVs with a mature channel program typically publish a list pricing document and agree a “discount off list” with each partner – for example, 35% off list as the partner’s guaranteed wholesale price, with deal protection (typically a tighter discount, say 5% off list, for any other partner quoting on the same registered deal) preventing a competing partner from undercutting within the deal protection window. The partner is then free to sell at any price between their wholesale cost (zero margin, extremely unlikely) and the full list price, with anticipated partner margins typically in the 20–35% range. In Model 4, the ISV sets the partner price at the agreed discount off list; the partner sets their customer-facing price to whatever margin they choose to take on the deal, and the ISV does not see the result.

ISVs early in their channel maturity may not yet have list pricing infrastructure. A simple agreed-percentage model (for example, “the partner gets 20% of whatever the deal closes at”) is workable in Models 1 and 3, where the ISV either invoices the customer directly (Model 1) or sees the marketplace transaction value (Model 3). It does not work in Model 2, where the ISV neither controls the customer-facing transaction nor has visibility into the price the partner quoted – the same pricing opacity that characterises Model 4. In Models 2 and 4, the absence of list pricing removes the only commercial reference point the ISV controls – the partner price becomes an arbitrary number rather than a principled discount off an established list.

AWS Private Offers

AWS Private Offers are the AWS-side mechanism for customer-specific marketplace transactions. The basic flow:

Offer creation. The ISV creates a private offer in AWS Marketplace Management Portal, specifying the customer (by AWS account ID), negotiated pricing structure, contract duration, payment schedule and any custom terms overlay.
Customer notification. The customer receives an email notification with a private-offer URL.
Customer acceptance. The customer accepts through the marketplace; the transaction creates.
Billing trigger. Billing begins per the agreed schedule. The transaction draws against the customer’s EDP commit where applicable.

Three notable AWS-specific features:

Flexible payment schedules. AWS Private Offers support instalment plans and negotiated payment schedules where available for the offer structure. The flexibility matters for customers whose procurement cycle doesn’t align with standard monthly or annual billing.

Express Private Offer. AWS introduced Express Private Offers in late 2025, with a 30 November 2025 launch post and re:Invent 2025 announcement context, as an automated mechanism that generates private offers from seller-configured pricing rules. Sellers configure rate cards and qualification criteria; buyers answer a short set of questions and receive a private offer within minutes when their requirements match the seller-configured rules. Reduces partner-side cycle time significantly for the subset of deals that fit the configured structures.

Offer expiration. AWS Private Offers have a defined expiration date set at offer creation. If the customer doesn’t accept before expiration, the offer becomes invalid and the ISV has to create a new one. Common deal-loss failure mode for ISVs that set expiration too tightly.

Detail on AWS-side co-sell mechanics that flow through private offers is in AWS Co-Sell.

AWS Channel Partner Private Offers (CPPO)

CPPO is AWS’s mechanism for channel-partner-routed marketplace transactions. The structure: the ISV creates a CPPO authorising a channel partner to resell the ISV’s product through marketplace; the channel partner sets the customer-facing price (typically with margin above the ISV’s wholesale price); the channel partner sends the offer to the customer; the customer accepts; AWS pays both the ISV (at wholesale) and the channel partner (at the margin).

Eligibility requirements at the time of this post’s last review:

The vendor must have an eligible AWS Marketplace listing and must authorise the channel partner to resell the product through a selling authorisation.
The channel partner must meet AWS Marketplace channel-partner seller requirements, including paid-seller registration, appropriate tax and disbursement setup, a required service-linked role and AWS approval.
Country availability: practitioners familiar with the program note that CPPO geographic availability has expanded progressively over time. Check current eligibility in the AWS Marketplace seller documentation before structuring a deal in a new geography.

Fee structure: the CPPO carries a 0.5% uplift on the standard private offer listing fee – so 3.5% for a SaaS transaction under $1M TCV, rather than the standard 3%. AWS applies the CPPO listing-fee uplift to the marketplace transaction fee structure and states that channel partners do not pay transaction fees through CPPO. AWS disburses payment to the channel partner and ISV based on the agreed pricing.

A worked example using the list price / discount off list frame: list price $100, agreed partner discount 35% off list, ISV wholesale price $65. The partner sells at $85 (taking roughly 23.5% margin on the selling price). AWS retains $2.28 (3.5% of $65). The ISV receives $62.72. The channel partner receives $20 fee-free. The ISV does not see the $85 customer price or the $20 partner margin. It is understood that AWS does not disclose the end customer price or expose the channel partner’s markup to the ISV; verify current disclosure mechanics in the AWS Marketplace channel-partner seller documentation. The ISV’s only visibility is their own wholesale price and the resulting payout after the fee deduction.

The margin/markup convention is commercially significant: “20% margin” can mean 20% of the selling price – in the example above the partner’s $20 is roughly 23.5% of the $85 they sold at, a figure the ISV is not ordinarily shown – or a 20% markup on the wholesale price, which produces different numbers again. Where the ISV operates a mature list pricing program, the partner discount off list is the agreed starting point and the partner’s margin is whatever they choose to take between that floor and the list price. Where the ISV operates a simple agreed-percentage model, the convention should be agreed explicitly in the partner agreement. Pricing structures should account for the full fee stack.

Attribution mechanics: partners report that closed CPPO transactions are attributed to both the ISV and the channel partner in AWS’s reporting. The precise reflection across partner-program tier counters and Specialisation renewal counters should be verified in current AWS Marketplace channel-partner documentation.

CPPO is the definitive mechanism for SI / MSP partners who want to bundle their services with the ISV’s product and transact through marketplace.

Microsoft Customer Private Offers and CSP Private Offers

Microsoft’s private-offer landscape includes two distinct mechanisms with meaningfully different mechanics:

Customer Private Offer (direct ISV-to-customer). The Microsoft equivalent of AWS Private Offers. The ISV creates the offer in Partner Center, specifies the customer (by billing account ID, not the customer’s tenant ID – a distinct identifier the publisher cannot look up; the customer retrieves it from the Azure portal under Cost Management + Billing, and must be an owner, contributor or signatory on that billing account to accept), negotiated pricing and custom terms. The customer accepts through Microsoft Marketplace; the transaction creates; billing flows through the marketplace; MACC drawdown applies for Azure IP Co-Sell Eligible offers.

The mechanics are similar to AWS Private Offers but with important differences. Azure IP Co-Sell Eligible status is the gate for MACC eligibility. Offers can be sold through Microsoft Marketplace without MACC eligibility, but only Azure IP Co-Sell Eligible offers decrement a customer’s MACC. Practitioners familiar with the program note that the Microsoft Customer Engagement Methodology (MCEM) stage is referenced in some workflow steps.

CSP Private Offer. A distinctly different mechanism from Customer Private Offers, and easy to misread as sitting entirely outside marketplace – it doesn’t. The customer-billing leg does: the CSP partner sets its own customer-facing price and invoices the customer directly, through Microsoft’s Cloud Solution Provider (CSP) channel. But the leg that pays the ISV is entirely inside marketplace, with Microsoft on both sides – when the CSP partner makes a sale, Microsoft bills the CSP partner and pays the software company based on the wholesale price, less the agency fee. Microsoft handles billing to the CSP partner and pays the ISV under its Marketplace payout policy; this changes the collection process, but it does not by itself guarantee payment or remove nonpayment exposure – Microsoft’s payout terms provide for recovering previously issued payouts in a nonpayment scenario. CSP Private Offers do not require the separate private-offer acceptance step used by Customer Private Offers and MPOs. The margin offered by the ISV is for the CSP partner; it is not the customer’s price. The CSP partner determines and invoices the customer-facing price separately.

CSP Private Offers do not draw down MACC, since the customer-billing leg sits outside marketplace. The CSP Private Offer mechanism is useful for ISVs whose channel motion runs primarily through CSP-tier resellers and whose customer base doesn’t prioritise MACC drawdown. For customers with active MACC commits, CSP Private Offers leave money on the table because the MACC drawdown isn’t available. Microsoft’s MPO and, more recently, resale enabled offer mechanisms are separate mechanisms for channel-routed deals that need to preserve MACC drawdown – both covered below.

Detail on the Microsoft-side co-sell mechanics that interact with private offers is in Microsoft Co-Sell.

Microsoft Multiparty Private Offers (MPO)

Multiparty Private Offers are Microsoft’s mechanism for channel-partner-routed marketplace transactions. They preserve MACC drawdown when the customer purchases a co-sell eligible solution. The mechanism is newer than the equivalent AWS CPPO and is fundamentally different from Microsoft’s CSP channel.

The mechanics: the ISV creates an offer specifying eligible channel partners, contract length and basic pricing parameters; the channel partner adds customer-specific details, margin and any custom terms; the channel partner sends the offer to the customer; the customer accepts through marketplace; Microsoft pays both the ISV (at wholesale) and the channel partner (at margin) in a single coordinated marketplace transaction.

The fee mechanics are worth stating precisely because they are commonly misunderstood. In Microsoft MPOs, Microsoft pays the channel partner with no agency fee and applies the marketplace agency fee to the software company based on the partner price.

A worked example using the list price / discount off list frame: list price $100, agreed partner discount 35% off list, ISV partner price $65. The partner sells at $85 (taking roughly 23.5% margin on the selling price). Microsoft retains $1.95 (3% of $65). The ISV receives $63.05. The channel partner receives $20 fee-free. The ISV does not see the $85 customer price or the $20 partner margin – Microsoft’s documentation for ISVs confirms that ISVs have visibility only to their configured partner price and their own payout; channel partners separately see the customer adjustment they configured and the customer-facing price, which the ISV cannot access. The ISV’s partner price is therefore the only commercial lever available in an MPO.

Note: the agency-fee rate applied by Microsoft should be verified in current Partner Center documentation before using it in deal modelling.

The margin/markup convention matters: “20% margin” as a percentage of the selling price produces different numbers from “20% markup” as a percentage of the wholesale price. In a mature channel program using list pricing, the partner discount off list (e.g. 35%) is the agreed starting point and the partner’s actual margin varies depending on what price they choose to sell at. In an early-stage channel program using a simple agreed percentage, the convention should be explicit in the partner agreement. For a side-by-side comparison with AWS CPPO fee mechanics, see the CPPO section above.

Compared with CSP Private Offers, MPOs route the transaction through Microsoft Marketplace and can draw against MACC when the customer purchases a co-sell eligible solution. The customer gets the procurement-friction-reduction benefits of marketplace plus the MACC drawdown they wanted; the ISV gets credit for a marketplace-routed deal; the channel partner gets margin without forcing the customer outside marketplace.

Resale enabled offer: a modifier, not a fourth motion. Microsoft also supports resale enabled offers, an authorisation that applies to private offers and multiparty private offers – but explicitly not to CSP Private Offers. Under a resale enabled offer, Microsoft pays the channel partner (not the ISV), and the channel partner then pays the software company outside marketplace, under whatever commercial agreement the two parties have – the reverse of the CSP payment flow, and different from a standard ISV-originated MPO. Resale authorisation can also support an MPO involving another reseller: in that case, Microsoft pays that reseller’s margin as well as paying the authorised resale partner, and the authorised partner pays the ISV under their external agreement. Microsoft still bills the customer directly, and MACC drawdown is preserved (100% when the solution is co-sell eligible); customer billing remains with Microsoft and qualifying purchases retain the MACC benefit. The authorisation is scoped to one offer, one channel partner and named customer markets, after which the partner sells to the customer without further ISV involvement in that specific transaction. Microsoft charges the Marketplace agency fee to the partner that originates the private offer. For a standard ISV-originated MPO, Microsoft charges the ISV on its partner price, as in the worked example above. For a resale-enabled offer originated by the authorised channel partner, Microsoft charges that partner. For resale-enabled deals, model Microsoft’s fee against the originating resale partner and model the ISV’s proceeds using the parties’ external commercial agreement.

Eligibility (at the time of this post’s last review) requires:

For MPO creation, the offer must be published to Microsoft Marketplace, be publicly transactable and be created for an eligible partner and customer. Azure IP Co-Sell Eligible status is required for the purchase to decrement MACC.
The channel partner must be enrolled in MAICPP, have a Microsoft Marketplace account in Partner Center and hold a completed Marketplace tax profile in an eligible country. Customer billing-account countries and channel-partner tax-profile countries should be checked separately in Partner Center. US tax profiles carry an additional requirement: resale certificates must be filed with Microsoft at least five business days before the first MPO sale. Non-US channel partners selling to US customers may be subject to withholding tax and may use tax treaty benefits where applicable. Other countries have their own tax profile requirements; verify in Partner Center before structuring a deal in a new market.
Country availability: MPO customer purchases are available in Australia, Austria, Belgium, Bulgaria, Canada, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Japan, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, South Africa, Spain, Sweden, United Kingdom and United States – 36 markets as of this post’s last review. Australia, Japan and South Africa were added on 15 July 2026, following the May 2026 expansion across 30 European markets. Microsoft has indicated further expansion is planned beyond these markets.
The customer list and the channel-partner list are not identical. Channel partners can hold a supported Marketplace tax profile in 35 of those markets: Canada is available for customer purchases but is not a supported tax-profile country for channel partners selling through MPO. An ISV planning a Canadian channel motion therefore needs a partner whose tax profile sits elsewhere. Channel partner tax profile requirements vary by market; verify current eligibility in Partner Center before structuring a deal in a new geography.

MPO is more demanding in practice than direct Customer Private Offers – the multi-party coordination adds steps to the offer-creation workflow – but the commercial reach is now significantly wider than its original US/UK/Canada scope. For ISVs with established channel motions on Microsoft, MPO is the mechanism through which channel-routed enterprise deals close.

Google Cloud Private Offers

Google Cloud Marketplace supports two private-offer mechanisms:

Direct ISV-to-customer private offers. For direct Google Cloud Marketplace private offers, the vendor creates a customer-specific offer for an eligible SaaS, VM or Kubernetes product. The customer accepts through Cloud Marketplace. Eligible Google Cloud Marketplace spend may count toward Minimum Commitment obligations under Google’s Commitment Drawdown Policy, while MCCP is a separate customer-credit program.

Marketplace Channel Private Offers (MCPOs). Google Cloud’s channel-mediated private-offer mechanism, formally named Marketplace Channel Private Offer (MCPO). The mechanics are structurally different from AWS CPPO and Microsoft MPO in ways that matter commercially, and the full picture is sufficiently complex that this section describes what is confirmed from primary documentation and is explicit about what requires direct verification with Google.

What is confirmed from primary documentation. The channel partner must hold an accepted status in Google’s channel partner program – historically requiring acceptance in the Google Cloud Partner Advantage program and authorisation in the Sell engagement model (the Google Cloud partner program structure before the Q1 2026 Partner Network reset – see Cloud Partner Programs and Specialisations for the current tier model). Partner Advantage was replaced by the Google Cloud Partner Network in Q1 2026; verify current channel-partner eligibility requirements directly with Google, as the program documentation reviewed does not yet reflect the updated path names. The Q1 2026 Partner Network restructure and its implications for ISVs are covered in Google Co-Sell. ISVs create private offer plans that define the discount available to channel partners; channel partners accept these plans and use them to create private offers for their customers. The customer does not see the reseller discount the channel partner receives from the ISV.

The billing model differs from AWS and Microsoft. In Google Cloud Marketplace Channel Private Offers, the channel partner maintains the customer relationship and owns billing, invoicing and revenue recognition, while the customer purchases the ISV solution through Google Cloud Marketplace via the chosen channel partner. This follows the Model 2 pattern (ISV sells to reseller at wholesale, reseller sells to customer at their own price) mediated through Google Marketplace, rather than the Model 4 arrangement of AWS CPPO and Microsoft MPO where the marketplace invoices the customer and splits the payment.

The agency model complicates this. It is understood that Google Cloud Marketplace operates an agency model alongside the traditional reseller model, under which Google acts as agent for the ISV, facilitating and processing the transaction. Practitioners familiar with the program note that the agency model applies when both the ISV and customer are in supported regions and the ISV has agreed to the current Marketplace Vendor Agreement; verify current applicability directly with Google. How the agency model interacts with reseller transactions is not addressed in the documentation reviewed; the two models co-exist and Cloud Marketplace selects between them based on regional and contractual criteria.

Committed spend drawdown. Starting 9 June 2025, qualifying software purchases through Google Cloud Marketplace Channel Private Offers result in 100% commit drawdown tied to the final private-offer price. This resolves previously uncertain territory and brings MCPOs closer to parity with AWS CPPO and Microsoft MPO on this dimension. The 25% cap that applies is not specific to the channel route: under Google’s published Commitment Drawdown Policy, eligible direct and authorised-reseller Marketplace purchases share a cumulative cap of 25% of the customer’s corresponding Minimum Commitment. That shared ceiling is a material consideration for customers with large Google Cloud Minimum Commitments. Check the customer’s governing agreement for the terms that apply to them.

The revenue share fee for MCPOs. Google Cloud’s Marketplace revenue-share model varies by deal type and size, subject to eligibility. Standard offers attract 3%. New-deal private offers attract 3% below $1M TCV, 2% from $1M to below $10M and 1.5% at $10M or more. Qualifying native renewals, channel shifts and migrations attract 1.5% regardless of TCV. AWS applies a 0.5 percentage point CPPO uplift to its applicable listing fee. Verify the applicable Google rate and compare equivalent deal structures before modelling deal economics.

Given this complexity, treat the Google Cloud channel partner reseller model as requiring direct verification before structuring channel agreements, pricing or partner program commitments. The AWS CPPO and Microsoft MPO sections above describe verified mechanics; the Google reseller model is meaningfully different in architecture and should not be assumed to follow the same commercial patterns.

Practitioners familiar with the program note that Google Cloud’s private-offer tooling is lighter than AWS’s or Microsoft’s, consistent with the broader pattern in Google Co-Sell that Google Cloud’s partner-side tooling is less developed than the other two. More of the workflow happens through direct AE / CE coordination rather than through the partner portal. The trade-off: lower workflow overhead, but more of the operational discipline lives with the ISV team rather than being enforced by the tooling.

When to Use Which

For ISVs where hyperscaler alliances are a strategic priority, marketplace usage should not be a deal-by-deal decision. The default should be marketplace-routed, backed by policy and comp design that make direct deals the exception requiring senior approval. The reasons are covered in the Marketplace Deal Routing and Comp Design section of Cloud Marketplace Listings: treating marketplace vs direct as a per-deal choice gives ISV AEs a structural incentive to route direct, and the pattern compounds over time.

The question this section addresses is which marketplace mechanism to use, given that marketplace is the baseline. Four questions resolve most cases:

1. Does the customer have committed cloud spend? If yes, the mechanism matters: MACC / EDP / Google Cloud Minimum Commitment drawdown is the procurement-friction-reduction lever and not all mechanisms preserve it. For Microsoft specifically, eligible Customer Private Offers and MPOs, including those made under resale authorisation, can contribute to MACC (100% when the solution is co-sell eligible); CSP Private Offer does not. For Google Cloud, eligible Google Cloud Marketplace spend may count toward Minimum Commitment obligations whether the purchase is direct or routed through a Google-authorised reseller, with both sharing a cumulative 25% cap on that commitment; MCPO drawdown is based on 100% of the final private-offer price (from 9 June 2025).

2. Is a channel partner involved in the customer relationship? If yes, the multi-party variant (CPPO / MPO / MCPO) is the appropriate mechanism – it preserves the channel relationship and the partner’s margin through marketplace. Without a channel partner, the direct ISV-to-customer private offer is the appropriate mechanism.

3. Who owns the customer relationship? If the ISV directly owns the relationship, direct private offer is the natural fit. If a channel partner owns the relationship, the channel-mediated variant is appropriate. Where ownership is genuinely shared (ISV sells the product, channel partner delivers implementation services), the multi-party variant typically works.

4. What’s the deal size and operational complexity tolerance? Direct private offers carry lighter operational overhead than multi-party variants. For smaller deals or deals with simple terms, direct private offer is the right choice. For larger or more complex deals, the multi-party variant’s overhead is justified by the channel-partner economics and MACC / EDP drawdown preservation.

Non-marketplace alternatives – direct invoicing or, for Microsoft, CSP-routed deals that don’t draw MACC – should be documented exceptions rather than a normal operating mode. Where a deal routes direct, the reason should be recorded: customer explicitly declined marketplace, geography not yet supported, deal structure doesn’t fit available mechanisms. Tracking the aggregate of exceptions is a useful diagnostic; a high exception rate over time points to comp design and internal policy gaps, not customer preference.

Operational Mechanics

The operational flow common to all platforms (with platform-specific variation):

Pre-offer legal groundwork. For enterprise deals negotiated on the ISV’s own terms, the private offer normally follows completion of the direct legal groundwork. This typically involves an NDA at the start of the sales engagement; a POC or trial agreement if the customer is putting data onto ISV systems for evaluation; and an MSA or software licence and maintenance agreement negotiated directly between ISV and customer lawyers. This last step often involves multiple redline cycles and legal mediation calls that can span weeks or months. The marketplace infrastructure is not suited to hosting this negotiation – it is designed for acceptance of agreed terms, not iterative redlining. Offer creation usually begins once the MSA is executed. That is a sequencing choice: the published workflows allow drafts to be prepared earlier and do not identify a general requirement for a separately executed ISV–customer agreement before offer creation.

Offer creation. The ISV (or, for multi-party variants, the ISV plus the channel partner) creates the offer in the platform’s marketplace seller portal, specifying customer, pricing, terms, duration, expiration and payment schedule.
Internal approval. Most ISVs operate an internal deal-desk approval flow before sending offers to customers. The approval checks pricing against discount policies, terms against legal-approved templates, payment schedules against finance preferences.
Customer notification. The customer receives notification (typically email) with the offer URL.
Customer acceptance. The customer accepts through the marketplace UI; private offers on AWS, Microsoft and Google Cloud Marketplace are click-to-accept.
Billing trigger. Billing begins per the agreed schedule. Multi-party variants involve coordinated billing across both the ISV and the channel partner.
Payout cycle. Each marketplace pays the seller (and channel partner for multi-party variants) on a defined cycle. Timing varies by platform and transaction type; see Cloud Marketplace Operations for each platform’s payout cycle.
Reconciliation. The seller’s finance and RevOps teams reconcile marketplace transaction records to ISV-side CRM and ERP. Multi-party transactions add reconciliation complexity for the channel-partner-attributed share.

The operational depth required scales with transaction volume. ISVs running 1–5 private offers per quarter can manage manually; ISVs running 50+ private offers per quarter typically need Cloud GTM Platform tooling to automate offer creation, approval-flow routing and reconciliation. Detail on operational scaling is in Cloud Marketplace Operations.

Legal and Contracting Considerations

Marketplace private offers operate through a layered contract structure: the customer’s agreements with the hyperscaler, including the applicable marketplace terms, govern marketplace access, purchasing and billing; the applicable product terms may be the ISV’s own terms or a marketplace standard contract, with deal-specific amendments where supported, and are accepted through the marketplace’s purchase flow; the private offer carries the deal’s negotiated pricing and commercial parameters within what each platform permits. The private offer does not confer a general right to override the hyperscaler’s own terms.

EULA / Standard Contract Overrides. Private-offer contract overlays vary by marketplace. AWS and Google both support custom EULAs for private offers and Microsoft supports an uploaded contract PDF. Google also requires private offers to stay within approved Cloud Marketplace offerings and the Marketplace Vendor Agreement. The standard enterprise workflow: the ISV and customer negotiate the MSA directly and outside the marketplace, through whatever redline cycles the lawyers require. Once executed, agreed product terms can be included in the private offer through the marketplace’s supported contract mechanisms. A separate supplemental agreement may also sit alongside the transaction; its relationship to the offer’s product terms depends on the agreements concerned. The marketplace records acceptance of the terms included in the offer; it does not host the negotiation. An ISV that attempts to use the private offer itself as the vehicle for contract negotiation will find the infrastructure unwieldy – it is designed for acceptance, not redlining.

Partner T&Cs in multi-party offers. For CPPO / MPO / channel-partner offers, the channel partner’s own terms-and-conditions may overlay or supplement the ISV’s. The multi-party contract structure has to be clear about which terms govern which aspects of the deal.

Sales tax / VAT / GST handling. Each marketplace handles a portion of customer-side tax obligations but coverage varies by jurisdiction. The seller’s finance team needs to map which jurisdictions are marketplace-handled and which require seller-side tax registration. Detail in Cloud Marketplace Listings under multi-currency / tax.

Signature requirements. Private offers on AWS, Microsoft and Google Cloud Marketplace are click-to-accept: the customer accepts the private offer in the marketplace UI, and the marketplace records acceptance of the terms included in the offer. The documented private-offer workflows capture agreed terms rather than providing a shared redlining editor. Where terms are negotiated separately, include the agreed terms through the marketplace’s supported contract mechanisms before customer acceptance. An ISV may also want a signed agreement alongside the click-through event – either a signed MSA executed before the private offer is created, or a signed quote that references the MSA and the marketplace transaction – to create a deliberate paper trail. The marketplace transaction remains the commercial vehicle; the relationship between any such agreement and the offer’s product terms depends on the agreements concerned.

Indemnities and liability caps. The marketplace’s default contract terms include indemnity and liability provisions that the ISV’s custom contract may want to modify. Legal review is necessary at the standard-contract definition stage; the per-deal review then becomes lighter because the standard contract has already been vetted.

Common Pitfalls

Patterns that recur in private-offer motions:

Pricing that doesn’t account for marketplace fees. The 3% baseline fee reduces the ISV’s net realisation. Pricing structures designed without accounting for the fee stack produce gross-margin surprises. A related misconception in multi-party deals: the ISV assumes the channel partner is sharing the marketplace fee. In practice the fee applies only to the ISV’s wholesale price; the channel partner’s markup above that price is paid fee-free by the marketplace. The full marketplace fee sits with the ISV regardless of whether a channel partner is involved.
Offers that expire before customer acceptance. A recurring deal-loss pattern. Customers move slower than ISVs expect; offer expiration set tightly produces missed deals that have to be re-offered (and sometimes re-approved internally). Default to generous expiration; tighten only with reason. When setting expiry, think backwards from the customer’s procurement clock – if their budget cycle closes at month-end, an offer expiring mid-month forces a missed cycle rather than a rushed decision.
Missing flexible payment schedule. Enterprise customers often have specific payment-cycle preferences (annual upfront, quarterly, milestone-based). Standard monthly billing structures lose deals where the customer’s procurement cycle requires something different. AWS Private Offers and Microsoft / Google equivalents all support flexible schedules; use them.
Channel partner not eligible for the jurisdiction. CPPO and MPO have country-availability restrictions that have expanded over time but remain limited in some geographies. Check eligibility before structuring the deal.
CSP Private Offer used where MPO or a resale enabled offer would preserve MACC. Microsoft-specific. Customers with active MACC drawdown preference lose access to that benefit through CSP Private Offers. Use MPO or a resale enabled offer instead where eligibility allows.
Internal approval flow not designed for marketplace velocity. Marketplace deals close faster than direct-invoiced equivalents. ISV internal deal-desk approval flows designed for the slower direct-invoicing rhythm become the bottleneck for marketplace closing speed.
Reconciliation skipped for multi-party transactions. Multi-party transactions are harder to reconcile (channel-partner-attributed share, multi-cycle payouts, partner-side reporting). ISVs that skip the reconciliation discipline find their alliance comp credit and partner-program metrics drift from the platform’s reporting over time.

What This Looks Like in Practice

A composite example, drawn from patterns across multiple real situations: a data-platform ISV with $35M ARR closed its first complex multi-party deal in early 2026. The transaction involved a financial-services customer with a $1.2M annual contract and was routed through an SI partner that handled implementation services and customer-side change management.

The deal mechanics: the ISV created an MPO on Microsoft Marketplace specifying the SI as the authorised channel partner. The SI added their customer adjustment (producing roughly 15% margin on their selling price relative to the ISV’s partner price), customer-specific configuration details and a payment schedule aligned to the customer’s quarterly procurement cycle. Side-letter on indemnity caps signed in parallel with the marketplace acceptance. The customer accepted in marketplace; MACC drew down; Microsoft paid the ISV and the SI on separate parallel disbursement cycles.

Operational complexity from the MPO structure compared to the direct private-offer alternative: roughly 3x. The reconciliation step alone took the marketplace ops manager three days at month-end of the first quarter the deal billed in, against an hour or so for direct-private-offer reconciliations. By the third deal of similar structure, the team had built playbook and automation that brought MPO reconciliation overhead closer to 1.5x – still heavier, but tolerable.

The lesson: multi-party private-offer mechanics become manageable at scale with investment in playbooks. The first MPO deal looks like a major operational lift; the third looks routine. Invest in the playbook deliberately rather than treating each multi-party deal as one-off.

A benefit that registered less visibly at the time: the $1.2M MPO transaction, together with two similar deals closed over the following quarters, contributed significantly to the ISV’s Microsoft marketplace revenue metrics. The accumulated marketplace volume contributed meaningfully to the performance dimension of their Solutions Partner capability score – helping secure the designation renewal and unlocking higher-priority co-sell queue access, richer partner funding eligibility and specialisation options they hadn’t previously qualified for. The operational overhead of the first three MPO deals was real; the partner-program acceleration it bought was more durable than any single deal outcome.

Where to Go Next

Within this pillar:

Cloud Marketplace Listings – the listing types and validation processes that gate private-offer eligibility.
Cloud Marketplace Operations – the back-office stack that supports private-offer reconciliation and payout at scale.
Cloud Marketplace – the broader pillar this post sits under.

Per-cloud co-sell mechanics (where private offers operationalise co-sell):

AWS Co-Sell – AWS Private Offers in the co-sell context including the SaaS Co-Sell Benefit on private-offer-routed SaaS deals.
Microsoft Co-Sell – Microsoft Customer Private Offers, MPOs and the MACC drawdown dynamics.
Google Co-Sell – Google Cloud private-offer mechanics and the more AE-mediated motion.

The full series glossary is at Glossary.

Sources

AWS

AWS Marketplace – Private offers overview (Verified June 2026)
AWS Marketplace – Channel partner private offers (Verified June 2026)
AWS Marketplace – Express private offers configuration (Verified June 2026)
AWS Marketplace – Listing fees (Verified June 2026)
AWS What’s New – Express Private Offers, 30 November 2025 (Verified June 2026)
AWS Marketplace – Channel partner private offer features (Verified June 2026)

Microsoft

Microsoft Learn – Overview of channel-led sales through Microsoft Marketplace – comparison of multiparty, CSP and resale enabled offers: who Microsoft pays, who bills the customer, MACC retirement and agency-fee allocation (Verified September 2026)
Microsoft Learn – Resale enabled offers overview – the secondary-reseller MPO variant, where Microsoft pays both the additional reseller’s margin and the authorised resale partner (Verified September 2026)
Microsoft Learn – Resale enabled offers FAQ – pricing and fee sections distinguishing externally agreed wholesale terms from Partner Center pricing, and the resale partner’s transaction fee (Verified September 2026)
Microsoft Learn – Agency fee discount for renewals – 50% agency-fee discount on qualifying customer and multiparty private-offer renewals (Verified September 2026)
Microsoft Learn – Payout schedules and processes – MCA/CSP transaction eligibility on customer payment and provisions for recovering previously issued payouts on nonpayment (Verified September 2026)
Microsoft Learn – MACC frequently asked questions – offer eligibility, Azure-portal completion and active-commitment-term requirements for MACC drawdown (Verified September 2026)
Microsoft Learn – Transacting in the commercial marketplace (Verified June 2026)
Microsoft Learn – Multiparty private offers overview (Verified July 2026)
Microsoft Learn – Multiparty private offers for ISVs (Verified June 2026)
Microsoft Learn – Multiparty private offers for channel partners (Verified June 2026)
Microsoft Learn – ISV to CSP reseller private offers (Verified June 2026)

Google Cloud

Google Cloud Marketplace – Private offer plans for resellers (Verified June 2026)
Google Cloud Marketplace – Create private offers for customers (resellers) (Verified June 2026)
Google Cloud Marketplace – Commitment drawdown rates (Verified September 2026)
Google Cloud Blog – Upgrades to Google Cloud Marketplace for partners, 2025 (Verified June 2026)
Google Cloud Blog – Announcing Google Cloud Marketplace private offers (Verified June 2026)
Google Cloud – Marketplace revenue-share schedule – tiered revenue-share rates and eligibility conditions for standard offers, new-deal private offers and qualifying native renewals, channel shifts and migrations (Verified 7 September 2026)

Last reviewed: 2026-09-28. Vendor-specific clusters in this series are reviewed twice yearly after the major hyperscaler conferences plus mid-cycle for major program or marketplace changes. Major changes between reviews are flagged in the Updates section below.

Updates

Updated 28 September 2026: Rewrote the Microsoft channel-motions coverage: CSP private offers, in which Microsoft bills the CSP partner and pays the ISV while the partner prices and bills the customer; resale authorisation, including the secondary-reseller variant; and how each differs from standard multiparty private offers in payout recipients and fee treatment. Corrected the Customer Private Offer flow, which targets the customer’s billing account ID rather than a tenant ID. Revised the signature-requirements guidance to describe the documented acceptance process and removed unverified claims about click-through acceptance and signed supplements. Clarified that executing an agreement before offer creation is usual practice rather than a marketplace requirement, and that Google supports custom EULAs on private offers. Corrected Google’s drawdown commitment and fee schedule, added Microsoft’s reduced fee on qualifying renewals and replaced an unsupported payout interval with a pointer to Cloud Marketplace Operations. Also made several smaller clarifications. Factual corrections were checked against the cited sources and independently reviewed.

Updated 24 July 2026: Microsoft Marketplace multiparty private offers expanded to Australia, Japan and South Africa on 15 July 2026, taking customer availability to 36 markets. The country availability detail has been updated accordingly. It now also records that the channel-partner tax-profile list is one market shorter than the customer list – Canada supports customer purchases but not channel-partner selling.

Updated 6 July 2026: Corrected the MPO worked example, which was priced in GBP rather than the series’ standard USD – figures unchanged, currency symbol only. Also corrected two Microsoft program-mechanics details in the composite example: Solutions Partner designations are earned through capability-score points rather than a tier ladder, and PAL (Partner Admin Link) is an attribution mechanism rather than a funding program.

© Chris Buckel / flashdba. Part of the Hyperscaler GTM Playbook. If you quote or reproduce this content – in writing or as material for AI systems – please attribute it to Chris Buckel / flashdba.com and link to the source. Legal information and terms: flashdba.com/about/legal/.