Google's default commit paper leaves roughly 25 to 40 percent of your committed dollars stranded because Flex CUD scope is frozen at the signature-date SKU list, not the roadmap
Google already sells portability through Compute Flexible CUDs and Flexible Savings Plans, and it widened coverage unilaterally in June 2024, September 2025, and again on January 21, 2026. The negotiation is not whether swap rights exist, it is whether your contract inherits every future expansion automatically and whether the 9 to 25 percent EDP discount and the 20 to 55 percent CUD layer both survive the move. Buyers who redline scope as a forward-looking category instead of a SKU list recover the difference between a 78 percent burn and a 97 percent burn on a three-year commit.
Prepared by Redress Compliance · August 31, 2026 · Google Cloud advisory. Commit, EDP, and Marketplace negotiations 2024 to 2026.
Executive summary
Google has expanded Flex CUD scope at least three times since mid-2024, and every buyer whose contract names SKUs instead of categories paid for coverage they never received.
The June 2024 expansion folded Compute Engine, GKE Autopilot, and Cloud Run into one commitment, the September 5, 2025 announcement added VM families, and the January 21, 2026 change replaced the credit-offset model with discounted prices.
So a clause that says "eligible services as of the Effective Date" locks you out of all of it.
The memory-optimized carve-out is the single most expensive default in Google's paper: a one-year Compute Flex CUD delivers zero discount on memory-optimized VM spend, while a three-year commitment covers it.
If your workload mix shifts toward M-series or ultramem during a one-year term, that spend burns commit dollars at on-demand rates, and Google will not retroactively fix it because the exclusion is documented, not negotiated.
Marketplace drawdown is capped, and the cap you get depends entirely on how the transaction is papered: 25 percent of total commitment through authorized channel partners since June 9, 2025, versus up to 50 percent on direct SaaS listings.
Google states plainly that Marketplace spend earns commit credit but does not also earn the EDP discount, so a buyer planning to burn 40 percent of a $30M commit through third-party software needs the listing type confirmed in writing before signature, not after a shortfall notice.
Accelerator substitution is the weakest right in the current market because Google has withheld published per-chip pricing on Ironwood (TPU7x) three months past GA, leaving only a third-party estimate near $1.60 per chip-hour.
A clause that promises swap into current-generation accelerators at list minus X is unenforceable when there is no list, which is why the accelerator swap right has to be drafted against a most-favoured-rate mechanic or a named discount floor rather than a public price.
You cannot cancel a Google commitment once purchased, which is exactly why the swap right is the only real exit and why Google prices it as a concession rather than a default.
Strong outcomes look like unrestricted movement across all spend-based eligible products, automatic inheritance of future scope expansions, cross-billing-account portability for entities under common control, and a 40 to 50 percent Marketplace ceiling instead of 25 percent.
What Google's commit vehicles actually let you move, and where the walls are
Three instruments sit under the same "commitment" label and they are not interchangeable at the negotiating table. The resource-based CUD buys you a specific machine shape in a specific region and is the least portable thing Google sells: it discounts deeply and strands completely.
The Compute Flexible CUD buys hourly spend against eligible compute and travels across region, project, and machine family, which is why Google removed the need for separate commitments across Compute Engine, GKE Autopilot, and Cloud Run in mid-2024 and widened coverage again on September 5, 2025.
The Flexible Savings Plan is the broadest vehicle, a minimum monthly spend committed against a collection of eligible products rather than a compute family.
All three are non-cancellable once purchased, which is the entire reason substitution language matters: your only exit from a bad allocation is a lateral move, not a refund.
The billing engine applies resource-based CUDs first, then flexible coverage to whatever eligible spend remains, so a poorly sequenced portfolio can leave Flex dollars idle while resource-based coverage soaks up the discountable usage. Two dates belong in your file.
July 15, 2025 is the cutover to the new spend-based model for first-time purchasers, and January 21, 2026 replaces the legacy credit-offset mechanic with discounted prices while expanding eligible scope. Google says this does not increase total cost.
It also does not automatically widen your contract if your paper enumerates SKUs.
| Portability dimension | Resource-based CUD | Compute Flexible CUD | Flexible Savings Plan |
|---|---|---|---|
| Across regions | No | Yes | Yes |
| Across machine families | No | Yes, memory-optimized only on 3-year | Yes, per eligible product list |
| Across services (GCE, GKE Autopilot, Cloud Run) | No | Yes since mid-2024 | Broadest of the three |
| Across billing accounts | No | No, billing-account scoped | No, billing-account scoped |
| Marketplace drawdown | No | No | Contract-specific, capped |
| Cancellable | No | No | No |
The wall nobody prices in is the billing-account boundary. Flexible commitments are purchased at the Cloud Billing account level and apply only to projects paid by that account, so a group with six billing accounts across four legal entities buys six pools of stranded dollars, not one portable pool.
That is a structural leak, not a usage problem, and no amount of FinOps tuning fixes it after signature.
Name the Flexible Savings Plan in the order form even when the account team defaults to CUD language.
The FSP is drafted against a collection of eligible products, so when Google widens that collection (as it did in June 2024, September 2025, and January 2026) an FSP referencing the published list as amended inherits the expansion. A Flex CUD written against a compute SKU schedule does not.
That single naming choice is often worth more than the last two points of discount you are fighting over.
The four redlines that convert Google's product flexibility into a contractual right
Product flexibility that lives only in documentation is revocable. Google can narrow published scope, and your order form is what survives the argument. Four clauses do the work.
First, define eligible products by reference.
Not by list: "eligible usage means usage of any product identified in Google's then-current published spend-based CUD and Flexible Savings Plan documentation, as amended from time to time during the term." That single sentence converts every future expansion into a contractual entitlement and kills the signature-date SKU freeze.
Second, demand cross-billing-account portability for affiliates under common control, with an express right to reallocate commitment coverage across billing accounts on 30 days written notice and without re-pricing.
Google's platform limit is a billing construct, not a commercial one, and the deal desk can and does grant contractual pooling above it.
Third, borrow Google's own language on price protection: the flexible CUD terms already promise the same commitment fee for the entire term and the same discount percentage even when underlying prices change.
Turn that into discount-survives-substitution: any permitted reallocation preserves both the committed rate and the negotiated EDP tier, so a move from N2 to C4 or from us-east1 to europe-west4 does not reset your blended position.
Fourth, write the Marketplace contribution percentage in numbers and identify the listing type, because the ceiling is not one number: channel-partner software purchases have been set at 100 percent counting toward commit capped at 25 percent of total commitment since June 9.
2025, while direct SaaS listings have been quoted at up to 50 percent.
Contribution percentages vary by contract, which means the number is negotiable and silence defaults you to the lower cap.
Expect three counter-sentences.
The deal desk will propose "eligible products as set out in Exhibit A" (a frozen list), "flexibility subject to Google's then-current technical capabilities" (which reads as unilateral narrowing).
And "Marketplace spend contributes toward the Commitment but is not eligible for the Discount," which is Google stating the no-double-dip rule plainly and is generally not worth burning capital on.
Push instead on scope and portability, and hold the memory-optimized carve-out (flexible coverage on 3-year terms only) as a reason to structure term length deliberately rather than a reason to accept a narrow list.
The related work on Google Cloud commit clause redlines and on AWS EDP flexibility provisions shows the same pattern across both hyperscalers: the vendor sells portability in the product and withholds it in the paper.
What Gemini for Workspace adds to your bill
What Gemini for Workspace really costs as a Workspace add on: named user licensing, bundling pressure, and the buyer side levers that cap the spend.
Get the white paper →Why the Marketplace cap is the leverage point Google underestimates
The Marketplace drawdown cap is the softest number in the entire commit paper, and most buyers never touch it because it arrives looking like policy. It is not policy in the sense that a discount floor is policy.
Google built Marketplace drawdown to pull ISVs onto its billing rails and to make Google Cloud the procurement path for third-party software. That is a growth objective, not a margin defense.
When a growth lever meets a customer who can name the software, name the vendors, and put dollars against them, the lever moves. When it meets a customer asking for "more Marketplace flexibility" as an abstract concession, it does not move, because the field has no story to take upstairs.
Look at what the two published ceilings actually tell you. Since June 9, 2025, qualifying software bought through authorized channel partners counts 100 percent toward committed spend but is capped at 25 percent of the total commitment.
Direct SaaS listings have been quoted at 100 percent contribution up to 50 percent of the commit. Same software, same billing account, same Google revenue recognition, double the drawdown headroom. The delta is not a pricing rule.
It exists because Google compensates partners differently on channel transactions than on direct listings, and the cap is the crude instrument that keeps that compensation math from running away.
Once you see the cap as a partner-comp artifact, the negotiation changes shape: you are not asking Google to give up margin, you are asking Google to route the same transaction through a listing structure that already carries a higher ceiling.
The no-double-dip rule reinforces the point rather than undercutting it. Marketplace spend earns commit credit but does not earn the EDP discount on top. Google therefore captures full economics on that dollar and still gets it counted against your commitment.
Economically, Google is close to indifferent between a 25 percent cap and a 40 percent cap. The resistance you meet in the room is field compensation and quota attribution, not gross margin, which is why the objection sounds procedural rather than financial. Procedural objections escalate well.
Margin objections do not.
The practical move is to arrive with a named pipeline. Three to six ISVs, the annual contract value of each, the renewal dates, and a statement that those renewals will route through Marketplace if the cap supports it.
That converts an abstract flexibility ask into incremental Marketplace GMV the rep can claim. Buyers who bring that list routinely land cap relief in the 35 to 50 percent band on a three-year commit.
Buyers who ask for flexibility in the abstract get the standard 25 percent and a sympathetic explanation. That gap is the single largest recoverable item on most Google commit papers, and it sits in the same drafting family as the other commit clause redlines worth tabling before signature.
Sequencing matters more than the percentage. The cap has to be settled before the commit number is fixed, because the cap determines what a safe commit looks like.
If 40 percent of a $30 million three-year commit can be satisfied by software you were buying anyway, the infrastructure burn you actually need to generate drops by $12 million, and you can carry a larger headline commit at a lower risk of shortfall.
Negotiate the number first and the cap second and you have already sized the commitment against the wrong denominator.
Accelerator and reserved capacity: the substitution right that does not exist yet
Every swap clause drafted in 2026 breaks on GPU and TPU spend, and the break is structural. Ironwood (TPU7x) reached general availability around Google Cloud Next 2026 and, three months on, Google had still not published a per-chip rate.
The only figure circulating is a third-party estimate near $1.60 per chip-hour for privately negotiated capacity. You cannot draft "swap into current-generation accelerators at list minus X" against a list that does not exist.
Meanwhile the anchors you can see, a4-highgpu-8g at $64.44 per hour and a3-ultragpu-8g at $42.40 per hour on flex-start, are pure on-demand list and bear no relationship to what any serious buyer pays.
Reserved capacity compounds it: Dynamic Workload Scheduler calendar mode ties VMs to a reservation where you pay the full reserved duration whether or not you consume it. That is a rental, not a redirectable commitment.
So there are two defensible positions and one bad one. The bad one is folding accelerator spend into a general Flex CUD and assuming the swap clause covers it.
The right structural default for most buyers is to carve accelerator spend out of the commit denominator entirely and buy it under a separate schedule.
That protects the commit burn from AI workloads that get cancelled, re-architected, or moved to a competitor mid-term, and it stops undisclosed accelerator pricing from silently absorbing 20 to 30 percent of your committed dollars at rates you never negotiated.
If Google insists accelerators count, price the flexibility explicitly. Draft a named-generation prospective clause that lists TPU v5e, v5p, v6e, Ironwood/TPU7x and successor generations, so a hardware refresh does not strand the commitment against retired silicon.
Pair it with a most-favored-rate mechanic: if Google publishes or offers a lower effective per-chip-hour rate to comparable customers during the term, your rate resets. Without published list, that mechanic is the only thing standing between you and a rate you cannot benchmark.
On reserved capacity, insist that unconsumed calendar-mode reservations still count toward commit burn, since you have already paid for the duration.
What Google's deal desk does when you table these clauses
Table forward-looking swap scope and the deal desk reaches for one of four responses, in a predictable order. First comes the discount trade: 1 to 3 points off the EDP layer in exchange for widening the eligible-products definition.
Second comes the term push, because memory-optimized coverage under Compute Flex CUDs is a three-year-only benefit, so any request touching memory-optimized or accelerator families becomes an argument for extending your one-year vehicle to three.
Third, and this is the one that costs the most money, they offer an annual amendment right instead of automatic inheritance: the eligible-products list stays frozen at signature, and once a year you may ask to refresh it, subject to approval.
Fourth, they decline cross-billing-account portability outright, pointing at the June 2026 default sharing change as the reason to revisit later.
Concede on term if the accelerator or memory-optimized roadmap is real, because the three-year CUD band (30 to 55 percent published) more than pays for the loss of exit optionality. Concede one point of EDP if it buys automatic inheritance of every future Google scope expansion.
Do not concede the annual amendment right.
Google widened Flex CUD coverage unilaterally in June 2024, September 2025, and again on January 21, 2026, which means a frozen list dated at signature is guaranteed to be obsolete inside twelve months, and an amendment you must request is an amendment you can be refused.
| Google's counter | What it costs you | Hold or concede |
|---|---|---|
| 1 to 3 points off EDP for broader swap scope | On a $10M annual commit, 2 points is $200K per year | Concede up to 2 points for automatic inheritance |
| Extend 1-year to 3-year to unlock memory-optimized and accelerator coverage | Loss of exit optionality; offset by 30 to 55 percent three-year CUD band | Concede if roadmap is real |
| Static eligible-products list plus annual amendment right | 25 to 40 percent stranding exposure, approval-gated | Hold, this is the whole fight |
| No cross-billing-account portability pending June 2026 | Blocks entity-level reallocation | Trade for a written revisit trigger |
Run the arithmetic before the call. Two points of EDP on a $30M three-year commit is $600K. A 20 percent stranding rate on the same commit is $6M of dollars that burn at on-demand rates or expire.
The give is cheaper by an order of magnitude, and the deal desk knows it, which is why they open with the discount trade rather than the scope concession.
Anchor the exchange explicitly: the point comes off only when the definition reads as a forward-looking category with automatic inheritance, documented alongside the other commit clause redlines worth tabling before signature.
Evidence base: what we see across Google commit negotiations
Buyer-side deals land outside the published three-year band in both directions, so the published table is an anchor, not a ceiling.
Below roughly $1M in annual Google Cloud spend, account teams route you to standard rate cards; above it, scope language becomes negotiable.
Across 2024 to 2026 engagements the patterns repeat with unusual consistency. The $1M annual spend line is the gate: under it, swap-scope redlines are typically rejected as non-standard; over it, the same language passes with a discount trade attached.
Published CUD bands sit at 25 to 37 percent on one-year and 30 to 55 percent on three-year, while buyer-side observation puts realized outcomes at 25 to 57 percent, meaning the top of the range is negotiable for buyers who bring committed volume and a credible multi-cloud alternative.
The EDP layer stacks above the CUD layer at 9 to 25 percent, so the two discounts are not substitutes, and a swap clause that preserves one but silently drops the other destroys a quarter of the stacked benefit.
Marketplace draw-down is capped at 25 percent of total commitment through channel partners, with direct SaaS listings quoted as high as 50 percent, and Marketplace spend earns commit credit without earning the EDP discount.
The most common failure mode remains the signature-date SKU list: buyers who accepted it in 2024 found their memory-optimized and Cloud Run growth landing outside eligible usage by 2025 and paying on-demand.
That interacts badly with reseller paper, where the reseller's own eligible-usage definition may be narrower than Google's, and with unpriced SKUs like current-generation accelerators where no public per-chip rate exists to anchor a list-minus-X substitution.
Both are treated in adjacent pages in this cluster, including the material on the locks sitting behind the CUD discount.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Pull the executed order form and find out whether "eligible products" is a list or a category, because if it names SKUs or consumption model IDs (Cloud Run 3-year 70D7-D1AB-12A4, for example) you inherited a signature-date snapshot and every expansion Google shipped in June 2024, September 2025, and January 21, 2026 passed you by.
- Model burn under a worst-case workload shift before you name a commit number, running one scenario where 30 percent of your Compute Engine footprint moves to GKE Autopilot, Cloud Run, or a memory-optimized family on a 1-year term, and put the stranded dollars on one line; in our practice that gap is the difference between a 78 percent and a 97 percent burn on a three-year deal, and it is the only number that moves a deal desk.
- Get the Marketplace contribution percentage and listing type in writing first, since a 25 percent channel partner cap and a 50 percent direct SaaS listing ceiling produce very different commit math, and Google will confirm that Marketplace spend earns drawdown credit but not the 9 to 25 percent EDP discount, so size the commit around the confirmed cap rather than the sales-deck version.
- Decide deliberately whether accelerator spend sits inside or outside the commit, and given Google still has no published per-chip price on Ironwood and calendar-mode reservations behave like prepaid rentals, our default recommendation is to carve TPU and reserved capacity out and price it in a separate schedule with a named generation-successor clause.
- Table the four redlines as one package, not four asks, because separated they become trading chips; combine them with the wider commit and term concessions covered in our Google Cloud commit and Workspace redline guide and the CUD shortfall mechanics so the desk has to answer the flexibility question to close the quarter.
Frequently asked questions
Can you actually move committed spend between Google Cloud services mid-term?
Yes, within limits. Compute Flexible CUDs and Flexible Savings Plans are spend-based, so committed dollars apply to any eligible usage on the billing account rather than a fixed machine type or region.
The constraint is the definition of eligible products: if your order form freezes that list at the signature date, you do not inherit the June 2024, September 2025, or January 2026 scope expansions, and spend on newly covered services burns at on-demand rates.
Why does a one-year Compute Flex CUD give no discount on memory-optimized VMs?
Google restricts memory-optimized coverage under compute flexible CUDs to three-year commitments only. A one-year flexible commitment produces zero discount on that spend.
This is documented product behaviour rather than a negotiable term, so if your roadmap includes M-series or ultramem growth, either take the three-year term or carve memory-optimized workloads into a separate resource-based commitment.
How much of a Google Cloud commitment can Marketplace purchases cover?
Since June 9, 2025, qualifying software bought through authorized channel partners counts 100 percent toward committed spend but is capped at 25 percent of the total commitment. Direct SaaS listings have been quoted at a higher ceiling, up to 50 percent.
Confirm which cap applies to your contract in writing, because eligibility and contribution percentages vary by agreement and the difference on a $30M commit is $7.5M of drawdown headroom.
Does Marketplace spend earn the EDP discount as well as the commit credit?
No. Google's position is that Marketplace spend earns commit credit but does not also earn the EDP discount.
That is why the cap negotiation matters more than it looks: raising the ceiling costs Google little in gross margin because it is not giving away discount on that spend, which is exactly the argument to make when the deal desk holds at 25 percent.
Can you cancel a Google Cloud commitment if usage moves elsewhere?
No. Google's documentation is explicit that once a commitment is purchased it cannot be cancelled. That is the structural reason swap and substitution rights are the only real mid-term exit, and why the account team treats broader scope as a paid concession rather than a default entitlement.
Should GPU and TPU spend sit inside a Google Cloud commitment?
Often not. Google has not published a public per-chip price for Ironwood (TPU7x) three months after general availability, with only a third-party estimate near $1.60 per chip-hour circulating, so a swap-into-current-generation clause has no reference price to enforce against.
Dynamic Workload Scheduler calendar-mode reservations also behave as rentals where you pay for the full reserved duration. Either carve accelerators out or pair a named-generation prospective clause with a most-favoured-rate mechanic.
What does Google ask for in exchange for wider swap rights?
Expect a discount give of one to three points, a push from a one-year to a three-year term, and a counter that keeps the eligible-products list static with an annual amendment right instead of automatic inheritance of Google's published scope.
On most portfolios a two-point discount concession is cheaper than a 20 percent stranding risk, so hold the automatic-inheritance clause and trade elsewhere.
