Google Cloud Marketplace: What a Listing Changes, and What It Does Not

A software company spends six weeks preparing a Google Cloud Marketplace listing, clears the review, goes live, and waits. Three months later the listing has carried two transactions, both from customers the sales team had already been working for a quarter, and the internal argument is about whether marketplaces work rather than about what a listing was ever going to do.

The argument is avoidable. The answer sits in Google's own partner documentation, in the section almost nobody quotes. A marketplace listing changes how a deal is transacted. It does not change whether the deal exists. Read the eligibility rules closely and Google is blunter about it than any of the agencies selling listing services, because one of the conditions of being listed at all is a sales motion that already works.

What a listing actually is

The buyer-facing description is a catalogue. Google's own marketplace page presents it as a place to find, deploy and manage software that runs on or integrates with Google Cloud, and the discovery framing is what most of the coverage picks up. Google Cloud Marketplace and GCP Marketplace name the same storefront, and the abbreviated form is the one that tends to turn up in procurement threads and internal licence workflows rather than in Google's own documentation.

The seller-facing reality is narrower and more useful. A listing puts your product inside a purchasing flow the customer's finance and procurement functions have already approved. The purchase lands on an existing Google Cloud bill, under an agreement the customer already signed, through an approval path their procurement team already walked for a different vendor. That is a real advantage and it is an advantage about paperwork.

Google states the strongest version of it on the marketplace page itself: qualifying purchases of third-party Cloud Marketplace solutions can draw down on your Google Cloud commitments. A customer who has contractually promised a volume of spend to Google, and who is behind on that promise, can buy your product with money that is already committed and already spent from their point of view. For a buyer in that position the internal cost of saying yes falls sharply, and it falls for reasons that have nothing to do with your product.

Notice what has and has not moved. The buyer still had to want the product, still had to find you, and still had to reach the point of asking for a price. What the listing removed was the part after that.

The eligibility bar is a hosting test, not a quality test

The requirement most teams do not expect is that Google Cloud Marketplace is not open to B2B software in general. Google's requirements page for partners, last updated 11 August 2026, states that a seller must verify to Google Cloud through an approval process during onboarding that it hosts its software product primarily on Google Cloud, and it then sets out nine approved hosting patterns: fully hosted on Google Cloud, compute or data plane on Google Cloud, storage and backup, migration tooling whose only destination is Google Cloud, agent data analysis, datasets hosted and delivered through Google Cloud, deployment on Google Distributed Cloud, and two patterns for AI agents registered through Gemini Enterprise.

The same page closes its product requirements with a sentence worth reading twice: your listing must result in meaningful Google Cloud consumption by the customer procuring or using the solution.

That single line explains the whole programme. The marketplace is not a distribution favour Google does for software companies. It is a consumption channel, and a listing earns its place by moving cloud usage. A product that runs on another cloud, or on your own infrastructure, is not a marginal case to be argued; it is outside the stated pattern set.

The rest of the bar is ordinary and still worth planning for. The organisation must join and maintain good standing in the Google Cloud Partner Network, must be incorporated in one of the supported regions, and must hold a vendor account and payment profile in good standing. The product must be production-ready rather than alpha or beta, must carry no known vulnerabilities or malicious code, and must offer the same capabilities and features as any version sold outside the marketplace, which quietly forecloses the tactic of listing a cut-down edition to test the water. Changes that affect compliance with any of this oblige the seller to notify Google and resubmit the product for re-review and re-approval, so the listing is a maintained state rather than a completed project.

What Google requires before it will list a product

• ✓Yes: The product is hosted primarily on Google Cloud, verified through an onboarding approval process against nine named patterns
• ✓Yes: The listing results in meaningful Google Cloud consumption by the customer procuring or using it
• ✓Yes: The organisation has joined and maintains good standing in the Google Cloud Partner Network
• ✓Yes: The organisation is incorporated in a supported region and holds a vendor account and payment profile in good standing
• ✓Yes: The product is production-ready rather than alpha or beta
• ✓Yes: The business is enterprise-ready, which Google's page defines as a professional online presence, a defined sales motion, customer support and strong security practices
• ✓Yes: The marketplace edition carries the same capabilities and features as the version sold outside it
• ✕No: Listing a reduced edition to test demand before committing

Two transaction models, and the one that decides who your customer is buying from

Google's transaction models page states that Cloud Marketplace supports the following two transaction models, and which one applies is decided per transaction rather than chosen once.

Under the agency model, Google acts as an agent for you as you offer your product, facilitating and processing the transaction while you remain the Merchant of Record. The customer receives two invoices, one for marketplace products offered by independent software vendors and one for first-party Google products and Google Cloud usage. Under the Merchant of Record model, Google acts as the Merchant of Record and sells your product to your customers directly.

The routing is automatic. Where a transaction meets the agency model requirements, the marketplace uses the agency model; otherwise it uses the Merchant of Record model. Those requirements are that both you and the customer are in a region the marketplace supports for the agency model, that your organisation has agreed to the current version of the Marketplace Vendor Agreement, and that both parties have verified their identity to Google where asked. Sellers can confirm which model applied by checking the transaction_model field in their Customer Insights reports.

This matters more than its placement in the documentation suggests. Merchant of Record is the question of who is legally selling, which reaches contracting, tax treatment, refunds and the name the customer sees on the invoice. A team that assumes it holds the customer commercial relationship, and then discovers the model flipped because a customer sat in an unsupported region, has found out at the wrong moment. The live note on route to market against go-to-market makes the general version of the point: listing on a platform puts the platform in part of the transaction and often part of the relationship, and that is a route decision rather than a marketing one.

Agency modelYou are the Merchant of Record

• Google facilitates and processes the transaction as your agent
• You remain the seller of record for the transaction
• The customer receives two invoices, one for ISV products and one for Google's own
• Requires both parties in a supported agency region
• Requires the current Marketplace Vendor Agreement and identity verification where requested

Merchant of Record modelGoogle is the Merchant of Record

• Google sells your product to your customers directly
• Applied to any transaction that does not meet the agency requirements
• Selection happens per transaction, not per vendor
• Customers are told during purchase which model is being used
• Confirmed afterwards in the transaction_model field of Customer Insights reports

The revenue share is a position, not a rate card

The commercial terms are easy to read past. Google's requirements page states that Google offers a standard revenue share for products sold through Cloud Marketplace that meet all of the listed requirements and pass a business case review during Google's internal product validation process, and that where a product does not meet the requirements or does not pass that review, and the seller still wants to proceed, Google might offer an adjusted revenue share.

Two things follow for anyone modelling this. Those requirements are necessary and not sufficient, because a business case review sits behind them and it is Google's judgement rather than a checklist. And a seller who clears the bar and a seller who is admitted by exception are not on the same terms, so a rate quoted by a peer or by a listing agency describes their negotiation and not yours. That page states the terms qualitatively and does not attach a number to either share, which is a fact about the page rather than about the programme: the number lives in the Marketplace Vendor Agreement the seller signs, and it is the document to read before the listing is scoped.

What the listing does not change

The requirement list contains its own answer to the demand question, in the definition of enterprise-ready. Google asks for a professional online presence, a defined sales motion, customer support and adherence to strong security best practices. A defined sales motion is a precondition of listing. Google is not offering to supply one.

This is the same failure our own partner writing keeps arriving at from other directions. The note on partner enablement names expecting the partner to generate demand as one of the ordinary failure modes of a channel programme, because most partners respond to demand rather than create it. The note on market development funds makes the matching point about money: partner marketing spend is slow, indirect and reaches a market through somebody else's brand, and funding it as a substitute for demand needed this quarter is the mistake it is most often used to make. A marketplace listing is the same instrument again, in a third costume. It is procurement infrastructure. It shortens the path from decision to signature and does nothing to the path from stranger to decision.

The catalogue itself is a weak discovery surface for a specific reason. Buyers browsing a cloud marketplace are mostly there having already chosen a category and often a vendor, arriving to transact. A listing is found by people looking for it, which makes it excellent at capturing demand that exists under your name and poor at creating any.

1. Step 1The buyer does not know you exist

   Nothing about a listing addresses this. Outbound, content, events and partners are the instruments that do, and the listing is invisible until one of them has worked.

2. Step 2The buyer evaluates and decides

   Product, references and the sales conversation carry this. A listing contributes only the reassurance that procurement will be straightforward.

3. Step 3The buyer has to buy it

   This is the step the listing changes. Existing agreement, existing invoice, an approval path procurement has already walked, and committed spend that can be drawn down.

4. Step 4The deal is transacted and reported

   The transaction model decides who is Merchant of Record, what the customer is invoiced for, and which contract the sale sits under.

Deciding whether to list

The decision is more tractable than the volume of guidance around it suggests, because the first two questions are factual rather than strategic. Does the product sit inside one of the nine hosting patterns, and will its use produce meaningful Google Cloud consumption. A no to either ends the conversation, and finding that out on the first afternoon is worth more than any subsequent analysis.

Past that gate the useful question is whether your buyers hold cloud commitments they are struggling to consume. Where they do, a listing removes a genuine obstacle and can shorten a late-stage deal materially. Where they do not, the listing is a procurement convenience with a revenue share attached, and the effort of building and maintaining it is competing against everything else that quarter.

The same reasoning applies to the pipeline the listing is expected to serve. A channel that shortens closes is worth having and it is not worth confusing with a channel that produces conversations, which is the distinction sorting channels by how fast they answer is built around. And where the marketplace becomes a route your partners transact through rather than one your own team uses, the ownership questions arrive immediately: our note on deal registration covers who owns a contested opportunity and what a written policy has to settle before the first dispute rather than during it.

The short version

Google Cloud Marketplace is a transaction surface. It puts a purchase inside an agreement the customer already holds, on a bill they already receive, and it lets qualifying purchases draw down commitments they have already made to Google. That is a real and sometimes decisive advantage at the end of a deal.

Eligibility is a hosting test before it is anything else. Google requires a seller to verify that it hosts primarily on Google Cloud, publishes nine approved patterns, and requires that a listing result in meaningful Google Cloud consumption. The commercial terms are a standard revenue share for products that clear the requirements and a business case review, with an adjusted share available to products that do not, so the number is a negotiation and the vendor agreement is where it lives.

Which transaction model applies is decided per transaction and decides who is Merchant of Record, which is a contracting and tax question rather than an administrative one.

None of it creates demand, and Google's own requirements say as much by treating a defined sales motion as something the seller brings rather than something the marketplace supplies. If the listing is ready and the missing piece is the conversations to run through it, see what a first outbound campaign produces, with meeting criteria agreed in writing before anything sends.

Programme requirements and transaction mechanics above are quoted from Google's own partner documentation, fetched and verified 21 August 2026 against pages last updated 11 August 2026. Marketplace terms change. Verify current requirements and commercial terms with Google before relying on them.