How Enterprise Buyers Buy Through a Marketplace

Buying through a cloud marketplace is a procurement path, not a checkout button. The buyer is spending against a cloud agreement their finance team already signed, inside a permission model their IT team already set, and the steps that decide whether the deal closes this quarter mostly happen after the seller has stopped watching.

Almost everything published about cloud marketplaces is written to the seller. Create the listing, build the offer, send it, wait.

The waiting is the part nobody documents. A private offer that a buyer “hasn’t accepted yet” is rarely a buyer who has gone quiet. It is usually a buyer who accepted in one system and cannot purchase in another, or who is the wrong person in the right company, or who is waiting on an internal approval nobody told the seller about.

Here is what the other side of that transaction actually looks like, and which of its delays a seller can do something about.

What does it mean to buy through a cloud marketplace?

Buying through a cloud marketplace means the software purchase is billed by the cloud provider rather than by the software vendor, and settles against the buyer’s existing account with that provider. AWS puts the mechanics plainly: the charge “becomes part of your AWS bill, and after you pay, AWS Marketplace pays the seller.”

That single billing relationship is the entire reason enterprise buyers ask for it. The vendor security review, the new-supplier onboarding, the payment terms negotiation and the tax forms have all been done once, for the cloud provider. A marketplace purchase inherits them.

It also means the purchase is governed by the buyer’s cloud account structure — and that is where the surprises come from.

The four things a buyer needs that a seller cannot see

A marketplace purchase requires four separate things to be true on the buyer’s side. Sellers routinely assume all four and are wrong about at least one.

What is needed	Why it stalls
The right billing account	The offer targets one account; the buyer works in another
The right role on that account	Accepting and purchasing need different permissions
Budget already committed	Drawdown only works against the right agreement
Internal approval	Marketplace bypasses procurement’s tooling, not its policy

The billing account is the most common failure. Microsoft’s buyer documentation is explicit that “private offers align to your billing account,” and that before purchasing, the buyer must “check that you’re signed into the directory (or Azure tenant) that includes the billing account of the private offer.” A large enterprise has many tenants. The person the seller has been emailing may not be able to see the offer at all.

Accepting and purchasing are different acts with different permissions. Microsoft warns that “purchasing a private offer requires different roles and permissions as compared with accepting a private offer” — the purchaser needs “an Azure subscription owner or contributor role for a subscription under the billing account of the private offer.” A champion who can accept can very often not purchase, and discovers this only at the last step.

There is a built-in wait. After acceptance, Microsoft notes that “it can take 15-60 minutes after acceptance for the Purchase button to enable.” A buyer who tries immediately, finds the button greyed out, and assumes something is broken will close the tab and come back tomorrow — or not.

What the buyer sees at each cloud

AWS

The buyer subscribes from a product page or accepts a private offer, and the charge joins their AWS bill. AWS supports buying “at the listed price using the ISV’s standard end user license agreement (EULA) or by accepting a private offer with custom pricing and EULA,” as well as under a standard contract “with specified time or usage boundaries.”

The buyer’s own guardrails apply. Enterprises commonly restrict which products are subscribable at all, so a perfectly good offer can be invisible to the person meant to accept it — a control the seller has no view of and cannot override. What buyers see when you send a private offer walks the same path from inside the console.

Microsoft

The most procedural of the three. Accept, then purchase, then subscribe, then activate — four steps, each with its own permission and its own failure mode.

Two details change how a deal is worth structuring. Auto-renew is off by default: Microsoft states that when auto renew is off, “the SaaS subscription terminates on the end date. There’s no other billing on that SaaS subscription, even if your private offer ends after the end of the billing term.” And the private offer’s end date governs only purchasability — “the private offer end date only affects when the offer can be purchased, not how long the customer’s subscription will last.”

Activation carries a real deadline. Microsoft asks buyers to “ensure that the partner activates your SaaS subscription within 30 days after purchase,” and adds that “to receive MACC benefits on the invoice for the month of purchase, the subscription for MACC-eligible offers must be activated before the end of that month.” If your onboarding takes three weeks, you are inside a window that decides whether the buyer’s commitment drawdown lands this month or next — which is the single fact most likely to make a finance team care about your activation speed.

Google Cloud

Purchases sit alongside the customer’s other Google Cloud spending. Google’s framing is that “for most configurations, your customers receive one bill for all of your products and services, as well as the Google Cloud services that they use.”

Why procurement still shows up

Marketplace removes the vendor onboarding, not the approval. The buyer’s spend policy still applies, the threshold that requires a second signature still applies, and the security questionnaire still gets sent.

What changes is the order. In a direct deal, procurement gates the paperwork before anything is signed. In a marketplace deal, the commercial terms are agreed first and the internal approval runs against an offer that already exists — which is faster when it works, and confusing when the buyer’s process was not designed for it.

The practical consequence for a seller: an offer with a short expiry is a hostage to a process you cannot see. Give the offer a realistic availability window, and ask directly who signs and what threshold they sit above.

What a seller can actually control

Ask for the billing account, not the company name. The single question that prevents the most common stall is “which billing account should this offer target?” — asked before the offer is built, not after it is rejected.

Name the two people. One person accepts, another purchases. Ask which is which, early. Assuming they are the same human is the second most common stall.

Set the expiry against their process, not your quarter. An offer that expires before an approval board meets simply has to be reissued, and each reissue restarts the buyer’s internal clock.

Tell them about the wait. One sentence in the handover email — that the purchase step may not enable for up to an hour after acceptance — prevents a support ticket and a lost day.

Be ready to activate immediately. For Microsoft deals especially, activation timing has a commitment consequence for the buyer. Treat it as part of the deal, not part of onboarding.

For the seller-side mechanics behind all of this, how private offers work across each cloud covers the construction of the offer itself.

Frequently asked questions

Does buying through a cloud marketplace change the price? Not by itself. A public listing is at list price; a private offer carries whatever custom pricing and EULA the seller and buyer agreed. What changes is who bills the customer and which agreement the spend counts against.

Why can a buyer see a private offer but not purchase it? Acceptance and purchase need different permissions. Microsoft requires an Azure subscription owner or contributor role on a subscription under the offer’s billing account to complete the purchase.

How long after accepting can a buyer purchase? On Microsoft, up to an hour. Microsoft states it can take 15–60 minutes after acceptance for the Purchase button to enable.

Does a marketplace purchase skip the buyer’s procurement process? No. It removes vendor onboarding, not approval. Spend thresholds, security review and sign-off policies still apply — they just run against an offer that already exists.

What happens if a Microsoft private offer ends before the subscription does? Nothing to the subscription. The offer’s end date controls only when it can be purchased; the billing term controls how long the subscription runs.

Who should the offer be addressed to? Whoever controls the billing account, which is often not the champion. Ask for the billing account identifier before building the offer.

Takeaways

A marketplace purchase settles against the buyer’s existing cloud agreement. That is the whole value, and the whole source of the constraints.
The offer targets a billing account, not a company. Ask for the identifier before you build it.
Accepting and purchasing need different permissions, and are often different people.
Microsoft’s Purchase button can take 15–60 minutes to enable after acceptance. Warn the buyer.
Auto-renew is off by default on Microsoft SaaS subscriptions, and the offer’s end date does not shorten the billing term.
Activation speed has a commitment consequence for Microsoft buyers, so treat it as part of the deal rather than part of onboarding.

Most stalled marketplace deals are not stalled on price. See how Suger’s buyer service and procurement tooling gives both sides of the transaction the same view of where an offer actually sits.