# Create Private Offer
Create a custom offer for a specific customer in GCP Marketplace, allowing flexible pricing and contract terms tailored to your buyer's needs.
---
## Overview
With Cloud Marketplace Private Offers, you can create a custom offer for a Kubernetes app, SaaS product, or virtual machine (VM) image for a specific customer. The offer enables your customer to purchase your Cloud Marketplace product at a negotiated price or discount.
:::danger
When the customer opens their offer, they are taken to a purchase page on Cloud Marketplace. The customer then confirms the purchase and signs up for your product. After sign-up, they use your product as if they signed up for a plan directly through Cloud Marketplace.
:::
A private offer consists of:
1. **Product Plan**: The base plan for the offer. Each plan uses a single [Product Pricing Model](/gcp-marketplace/pricing-model/).
2. **Private Offer Pricing Model**: Customizes the Product Pricing Model for the selected plan. (Note: One Product Pricing Model can have multiple Private Offer Pricing Models.)
3. **Payment Schedule**: Defines how and when the customer pays (Prepay or Postpay).
4. **Contract Duration**: The length of time the offer is valid.
---
## Prerequisites
Before you proceed, make sure both your GCP and Fours environments are ready. This prevents errors during offer creation and approval.
**Google Cloud Marketplace** — collect the following buyer information:
- Exact GCP Billing Account ID
- Organization Name
- Contact Name and Contact Email
**Fours** — you need **Admin** access to the Fours Console. If you don't have access yet, ask your company admin to invite you to the organization. See [Manage Users and Roles](/get-started/account/).
---
## Create the Offer in Fours Console
### Step 1: Open the private offer flow
1. Go to the **Offer** page in the [Fours Console](https://console.suger.io/offer).
2. Click **+ New Private Offer** in the upper-right corner.
3. Select the **GCP Product** you want to base the offer on. This defines what is being sold.
:::tip Start from an existing offer
To reuse an existing offer's details, open it and choose **More actions → Clone Offer**. The form opens pre-filled from that offer. This includes an offer created in Producer Portal and synced into Fours: its GCP Billing Account ID, Organization Name, contact details and notes carry over into the clone. A reseller's offer (`CPPO`) and an incoming resale authorization (`CPPO_IN`) cannot be cloned.
:::
When you clone a private offer or a replacement offer that is still **Pending Acceptance**, the form also shows an **Existing offer** card with **Cancel the existing offer at the publishing of this offer**, checked by default. Leave it checked and Fours cancels the original as soon as the new offer reaches pending acceptance, so your buyer is not left with two live offers; a subscription the buyer already accepted is not affected. Fours cancels the original through the path your integration uses at that moment — see [About Enable PrivateOffer API](/gcp-marketplace/integration/#about-enable-privateoffer-api). With **Enable PrivateOffer API** on, that includes an offer someone built in Producer Portal and Fours picked up by syncing.
### Step 2: Add basic information
- **Offer Name** — A descriptive title for your offer. Use a clear, consistent format, such as `CustomerName - ProductName - MM/YYYY`.
- **Salesforce Opportunity / HubSpot Deal** — Optional dropdowns that link this offer to an active deal in your CRM. This automatically syncs the offer's status back to your sales pipeline so your team can track it without leaving Salesforce or HubSpot.
- **GCP Billing Account ID** — The exact, unique identifier for the customer's Google Cloud billing account. This must be completely accurate — ask your buyer to provide it directly from their GCP console.
- **Organization Name** — The name of the buyer's company or organization (for example, `Acme Corp`).
- **Contact Name & Contact Email** — The name and email of the primary buyer contact who will review and accept the offer.
- **Notes for Customer** — Any additional instructions, context, or welcome messages you want the buyer to see when they open the offer.
- **(Sales info) Contact Name & Email** — The internal sales representative managing this offer. This usually auto-fills with your own Fours login details.
- **Notes for Your Team** — Internal notes visible **only** to your team. The buyer never sees this, so it's the place to track internal approvals, deal context, or special instructions.
- **Internal Notes** — A separate optional Fours-side note, team-only and up to **1,000 characters**, never shown to the buyer. It matches the **Internal Notes** field on the AWS and Azure offer forms, and is in addition to **Notes for Your Team** — both are team-only.
### Step 3: Set pricing information
The fields in this section change depending on the plan type you select. Start with your plan, then work through the fields that appear.
- **Plan** — The specific service tier the buyer is purchasing.
- **Payment Recurrence** — Choose how often the buyer is billed:
- **Monthly, Quarterly, or Yearly** — Standard recurring (Postpay) billing. The buyer is charged at the end of each period after the service is delivered. Auto-Renew is supported with these options.
- **Custom** — Build a custom installment schedule with specific dates and amounts (GCP's Prepay model). The first installment is charged when the buyer accepts, so it shows **Acceptance Date** instead of a date. Auto-Renew is not available with this option.
- **Expiry Date** — The deadline for the buyer to accept the offer. If this date passes without acceptance, the offer becomes void. Google allows at most **3 months**: the latest date you can pick is today plus three months, minus one day, on Google's Pacific calendar. A later date is refused when you create or submit the offer, before anything reaches Google, with a message that names the date you picked and the last date you can use — for example, *"the offer expiration date (January 5, 2027) is too late. Google Cloud Marketplace requires offers to expire within 3 months, so choose a date on or before December 22, 2026"*. Saving a draft does not check the date.
- **Enable future start date** _(optional)_ — Toggle on if you want the contract to begin on a specific future date rather than immediately upon acceptance. Useful for aligning with a buyer's budget cycle.
- **Offer Duration** — The length of the contract in months (for example, enter `12` for a one-year deal). Monthly (Postpay) contracts can run between 1 and 60 months.
- **Proration** — Appears only with **Monthly** recurrence, and not for the **Usage Discount Only** pricing model. **Off** (the default) keeps every installment on the offer's anniversary date; **On** prorates the first installment against the start date so billing lines up with calendar months. Fours always sends your choice to Google, so Google's own plan default never decides it. A cloned offer keeps the setting, and the offer detail page shows it as **On**, **Off** or **Not set (GCP default)**.
The remaining pricing fields depend on the plan type. For the full breakdown of pricing models and how discounts apply, see [Subscription-Based Offers](#subscription-based-offers), [Usage-Based Offers](#usage-based-offers), and [Subscription + Usage Combined](#subscription--usage-combined) below.
- **Subscription plans** — Enter the **Monthly Flat Fee**, the fixed monthly amount the buyer pays. No usage fields apply.
- **Usage plans** — Select the **Usage Plan Pricing Model** (required), then set the **Monthly Commitment** and **Discount on Commitment** as applicable to the chosen model. The dropdown groups the models the way Producer Portal does, with a one-line hint under each: **Committed use discounts** holds *Commitment discount with additional usage at list price* and *Commitment with all usage discounted*, and **Usage Only** holds *Usage-based discount only*.
- **Subscription + usage plans** — Enter the **Monthly Flat Fee** (base fee), **Discount on Usage** (percentage discount on metered consumption beyond the base fee; leave blank if none), and any **Additional Usage Fee**. The **Metric discounts** table updates automatically to show the tier breakdown, list price, and discounted price per unit.
- **Free plans** — Enter `$0` or leave the **Monthly Flat Fee** blank, and `0%` for **Discount on Usage**. Free plans do not generate software charges.
:::info Amounts cannot be negative
GCP rejects a negative amount outright, so Fours catches it on the form instead of at submit time. A negative commit amount reports **"The amount must be 0 or greater."**, and a negative installment names the row it is on — for example "The amount of payment installment 2 must be 0 or greater." Zero is allowed; a free offer is perfectly valid.
:::
### Step 4: Define other information
- Select an **EULA** to define the end customer license agreement. If you choose your own EULA, upload its file: until you do, **Custom EULA File** is listed as missing and **Create Offer** stays disabled.
- Select a **Deal Type** to define the commercial structure of the offer.
Then click **Create Offer** to publish the private offer.
### If the buyer already has an active offer
Google does not allow two active offers on the same product for the same billing account, and allows only one active non-subscription offer per billing account overall. If you submit an offer that would break either rule, Fours shows a toast naming the conflict rather than a raw error:
| Conflict | What the toast says |
| --- | --- |
| The buyer already has an active offer on this product for this billing account | Google doesn't allow two active offers on the same product + billing account. To renew or change pricing, amend the existing offer — GCP calls this a Native Renewal. |
| The buyer already has an active non-subscription offer on this billing account | GCP allows only one active non-subscription offer per billing account. Amend the existing offer or wait for it to end. |
Both toasts name the conflicting offer by the ID you can find in the GCP Producer Portal, and carry an **Open existing offer →** button that takes you straight to it in Fours — usually so you can start a [replacement offer](#replacement-offer) from it instead.
### Coterm and standard billing intervals
An offer billed at a **standard interval** — monthly, quarterly, or yearly — cannot also carry a scheduled end date. Google refuses the combination, so Fours reports it as a validation error on submit rather than accepting the offer and failing it moments later.
This matters most for coterm-aligned replacement offers, where you want the new offer to end when the offer it replaces ends. On a standard interval, express that as an **offer duration** instead of an end date. Offers on a custom billing period are unaffected and may carry an end date as before.
On the private offer and professional services forms, when the form asks for **Offer Duration** rather than an **End Date**, Fours drops any end date the draft still carries — one copied from the offer you cloned, or one saved before you changed the payment recurrence — so the duration you entered is the one Google receives.
### If the offer does not get created
When Fours cannot finish creating and publishing the offer, it lands in `Create Failed`. Either Google refused a request, or Fours' own checks stopped the create before anything was created in Google — for example a custom EULA file Fours cannot read, or pricing it cannot map to your plan.
The offer's detail page shows a **Create Offer Failed** alert with the reason, and keeps its **Edit Draft** and **Submit** actions: fix what the message names and submit the same offer again, without rebuilding it. If you would rather abandon the offer, you can archive it.
An older offer may show `Invalid` for the same kind of refusal. **Submit** does not work on an `Invalid` offer: open **Edit Draft**, fix what the alert names and choose **Save as draft**. The offer becomes a `Draft` again, and **Submit** works on it.
#### Resubmit after a failed publish
With **Enable PrivateOffer API** on, a create that got as far as Google can leave an unpublished draft of the offer there. When you submit the offer again, Fours checks that draft first instead of creating a second one:
```d2
direction: down
submit: "You submit a Create Failed offer again"
draft: "Did an earlier attempt leave\na draft in Google?" { shape: diamond }
state: "What does Google\nshow for it now?" { shape: diamond }
create: "Create the offer in Google"
rewrite: "Rewrite the draft with\nthis submission"
publish: "Publish the offer"
stop: "Submit fails\nGoogle's state is recorded on the offer"
submit -> draft
draft -> create: "no"
draft -> state: "yes"
state -> rewrite: "still a draft"
state -> create: "deleted, cancelled\nor expired"
state -> stop: "publishing, published,\naccepted or ended"
create -> publish
rewrite -> publish
```
- **Still a draft** — Fours rewrites the draft with the offer as you submitted it this time, including any field you cleared, and publishes it. No second draft is left behind.
- **Deleted, cancelled or expired** — Fours creates the offer afresh.
- **Publishing, published, accepted or ended** — the offer is, or was, live in front of the buyer, so Fours neither rewrites it nor creates a second offer beside it. The submit fails, and the offer records the state Google reported.
While Google still shows the offer as a draft, Fours' sync leaves it alone, so the sync cannot overwrite the edits you made to fix it. The offer's **GCP Billing Account ID** shows the account you saved, even while Google still holds the draft with the old one.
---
## Share the Offer
Once you click **Create**, the offer is securely sent to Google for a brief review before it can be shared with your customer. Here's how to track, share, and finalize the deal:
1. **Check the status.** Your offer initially shows as `Pending Google Approval`. Wait a few minutes and refresh until the status updates to `Created` — this means the offer URL is officially ready.
2. **Copy the offer link.** Open the created offer, then click **Copy offer URL**.
3. **Send to the buyer.** Share the link with your buyer so they can log into their GCP account, review the custom terms, and confirm the purchase. See [Accept Private Offer](/gcp-marketplace/accept-private-offer/) for the buyer's steps.
4. **Provide final approval.** For SaaS products, once the buyer accepts the offer, the status changes to `Needs Your Approval`. You must confirm the offer to activate it, unless you have Automatic Offer Approval enabled.
The offer detail page also shows an **Offer Duration** row alongside the dates, so you can confirm the contract length that was sent to Google without reopening the form.
Those dates — **Expire Date**, **Accept Date**, **Start Date** and **End Date** — are shown in Pacific time with a PST or PDT label, for every viewer, and so are a GCP entitlement's start and end dates on its page and in the Entitlements table. That matches Producer Portal, because Google anchors a private offer's term on the Pacific calendar day. An active entitlement's end date follows its offer's term: if the two have drifted apart — usually by a day — Fours moves the entitlement's end date to match on its next sync.
---
## Enable Automatic Offer Approval
By [enabling automatic offer approval](https://console.cloud.google.com/producer-portal/private-offers/settings), you can use scheduled or customer-acceptance start dates for SaaS product first offers. You can create or edit an offer's start date under **Start date**. Kubernetes and VM offers already have flexible start dates.
> 
---
## Multiple Flat Fee Offers
:::tip
Google Cloud Marketplace supports multiple **flat fee offers** for a single buyer. You can have several active private offers with the same customer, each with its own terms and duration.
:::
**To enable Multiple Flat Fee Offers:**
1. Go to the [GCP Producer Portal](https://console.cloud.google.com/producer-portal/private-offers/settings)
2. Select the **Multiple Orders** tab
3. Choose your product
4. Click **Enable Multiple Orders**
> 
---
## Payment Schedules: Prepay vs Postpay
| | **Prepay** | **Postpay** |
| ------------- | ----------------------- | ----------- |
| Contract Term | 2–36 months | 1–60 months |
| Auto Renew | Not supported | Supported |
| Notes | Not available in Brazil | |
---
## Subscription-Based Offers
For subscription-based product plans, only the **Flat fee** pricing model is available, with Prepay or Postpay options.
| | :moneybag: **Flat fee** |
| ------- | :------------------------------------------------------------------------------------------------------------------------------------- |
| Prepay | Customize: - Contract duration (months)
- Installment schedule
 |
| Postpay | Customize: - Contract duration (months)
- Monthly flat fee
 |
---
## Usage-Based Offers
For usage-based product plans, three private offer pricing models are available. The first two are types of [Committed Use Discount (CUD)](#committed-use-discount-cud):
- **Commit discount with additional usage at list price**
- **Commit with all usage discounted**
- **Usage discount only**
Each model supports Prepay or Postpay (except Usage discount only, which is Postpay only).
### Commit Discount with Additional Usage at List Price
The customer commits to a minimum spend and receives a discount on this commitment. Overage is charged at list price.
| | :moneybag: **Commit discount with additional usage at list price** |
| ------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Prepay | Customize: - Contract duration (months)
- Installment schedule
- Discount on commitment
 |
| Postpay | Customize: - Contract duration (months)
- Monthly commitment
- Discount on commitment
 |
### Commit with All Usage Discounted
The customer commits to a minimum spend and receives a discount on all usage, with optional granular discounts per usage metric.
| | :moneybag: **Commit with all usage discounted** |
| ------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Prepay | Customize: - Contract duration (months)
- Installment schedule
- Discount on usage
- Specific discount per usage metric (optional)
 |
| Postpay | Customize: - Contract duration (months)
- Monthly commitment
- Discount on usage
- Specific discount per usage metric (optional)
 |
### Usage Discount Only
The customer pays a discounted rate for usage, with no commitment. Only Postpay is supported.
| | :moneybag: **Usage discount only** |
| ------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Prepay | Not applicable |
| Postpay | Customize: - Contract duration (months)
- Discount on usage
- Specific discount per usage metric (optional)
 |
#### Committed Use Discount (CUD)
With a CUD, the customer receives a discount in exchange for a minimum spend commitment. The customer pays the commitment regardless of usage. The difference between the two CUD models is whether the discount applies to overage.
> 
##### Free credit and unused commitment (Prepay CUD only)
On a **Prepay** CUD offer — either **Commit discount with additional usage at list price** or **Commit with all usage discounted** — two extra controls appear above the payment-installment rows. They are schedule-wide choices that change the columns on the rows below, and they exist only on these plans because GCP models both on the commitment itself.
**Free credit**
Turn the **Free credit** switch on to grant a one-time credit on top of each installment's commitment balance, then enter the amount per installment. Turning the switch back off clears any credit already entered. On a replacement offer, installments that are already locked stay read-only here, the same as their amount and discount.
**Which type of unused commitment rule would you like to apply?**
This decides what happens to an installment's unused commitment — and to any partner-sponsored free credit — when the next installment starts:
| Rule | Effect |
| ---- | ------ |
| **Rollover** | The unused balance carries into the next installment. This is GCP's default. |
| **Expire** | The unused balance is discarded at the start of each following installment. |
| **Custom** | Decide per installment. Each row gains an **Expire** checkbox that governs the transition into the *next* row. |
The first installment never discards anything, since nothing precedes it.
:::warning Expire discards free credit too
"Expire" is not limited to the commitment. All unused and carried-over commitment **and partner-sponsored free credit** expire together. If you intend the credit to survive, choose **Rollover**, or use **Custom** and leave the relevant transitions unchecked.
:::
The offer's detail page carries read-only **Free Credit** and **Unused Commitment** columns on its payment-installments table, so you can confirm what was actually sent to GCP. They appear on different conditions: **Free Credit** only once an installment actually carries a credit, while **Unused Commitment** appears on **every committed-use offer** — both CUD models, whichever rule you chose, **Rollover** included. It shows up whether the offer was created through the Commerce Producer API or the browser-driven path, because a commitment on the installments answers the same question as the stored pricing model.
Each row of that column reports what happens to the balance *leaving* it, matching both the GCP producer portal and the **Expire** checkbox on that row. The last row therefore always reads "Expire all at offer end date": the term ends there, so nothing can roll further.
---
## Subscription + Usage Combined
If your customers pay both a flat fee and additional usage charges, use the **Flat fee with usage discount** model. The flat fee includes a usage allowance; overage can be discounted.
| | :moneybag: **Flat fee with usage discount** |
| ------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Prepay | Customize: - Contract duration (months)
- Installment schedule
- Discount on usage
- Specific discount per usage metric (optional)
 |
| Postpay | Customize: - Contract duration (months)
- Monthly flat fee
- Discount on usage
- Specific discount per usage metric (optional)
 |
---
## Metric Discounts Display
When creating a private offer for a plan that includes usage fees, you can view a detailed breakdown of how discounts apply to each usage metric and pricing tier.
:::tip
Metric discounts are available for **Usage-based** and **Subscription + Usage** plans. They are not calculated for pure subscription plans, nor for the "Commit discount with additional usage at list price" model — in that model the discount applies to the commitment amount, never to the individual usage metrics.
:::
:::note "Commit discount with additional usage at list price" on the offer detail page
A committed-use-at-list-price offer that has payment installments always shows its per-installment metric breakdown once the offer exists, even though no discount was applied to those metrics. That is the point: the breakdown is what shows the buyer, installment by installment, that their additional usage is billed at list price. The installment's discount percentage discounts the commitment, so the metric rows read as list price throughout.
:::
### How It Works
After entering a discount percentage, click the **Metric discounts** button to expand a detailed pricing table. The table shows, for each usage metric:
- **Metric name** (e.g., "API Calls", "Storage GB")
- **Tier information** — tier label, count range, list price per unit, and discounted price per unit
Discounted prices are calculated in real time as you adjust the discount percentage.
**Postpay:** The metric discounts section appears below the discount percentage input.
> 
**Prepay:** The metric discounts appear per payment installment, since each installment can have a different discount percentage.
> 
---
## Custom Feature List
When creating a private offer for a subscription-based plan (**Subscription** or **Subscription + Usage**), you can customize the feature list to tailor it for a specific deal — without changing the underlying product plan.
### How It Works
1. Select a subscription-based pricing plan. The feature list automatically populates with the plan's default features.
2. Click the **Update features** button to open the edit dialog.
3. For each feature, choose a status:
- **Included** — feature is included in the offer
- **Not Included** — feature is excluded
- **N/A** — not applicable
- **Add Details** — enter custom text (up to 100 characters)
4. Click **Save** to apply your changes. Modified features are marked with a checkmark icon.
> 
> 
---
## Replacement Offer
A replacement offer lets you renew or upsell an active entitlement. Once accepted, the buyer's entitlement is updated immediately.
:::tip
You cannot change the product, plan, or price model of the existing private offer. You can only change payment schedule, amount, discount, and duration.
:::
**Required info:**
- **Expiry Date**: The deadline for the buyer to accept the replacement. As with any GCP offer, it can be no later than today plus three months, minus one day, on Google's Pacific calendar — and the rule below about the existing offer's installments can require an earlier date.
- **Start Date**: When the new offer begins (can be a future date; defaults to immediate after acceptance).
- **Payment Schedule**: Prepay or Postpay (can differ from the original offer).
- **End User License Agreement (EULA)**: Select or upload your custom contract. The replacement starts from the replaced offer's EULA choice; if that is a custom EULA, upload its file for the replacement, because the offer cannot be created without it.
:::warning
The expiry or start date must be before the first future payment installment date of the existing offer.
:::
**A co-terming replacement cannot start after the term it co-terms to has ended.** When the replacement is set to co-term to the replaced offer, its **start date** must fall on or before the last live day of that term — Fours rejects a later date and names the latest start date you can use. The check is skipped when the replaced entitlement is already pending cancellation: in that case the replaced term's dates are all in the past and no start date could satisfy the bound.
### When to replace instead of creating a new offer
If you start a **new** offer for a buyer who already has an active entitlement, Fours no longer blocks you — it asks first. An **Active Entitlement Detected** dialog names the billing account and suggests that an amendment may be more appropriate:
- **Proceed** — create the new offer anyway.
- **Go back** — return to the form so you can build a replacement offer instead.
A replacement offer is usually the right choice when you are renewing or upselling the same buyer, because it updates the existing entitlement rather than leaving two offers side by side.
You can also amend an accepted offer that has **no entitlement yet** — Fours links the new offer to the live base offer directly, so you don't have to wait for the entitlement to appear.
:::info Native Renewal eligibility
GCP treats a replacement as a **Native Renewal** only when the entitlement it replaces ran for at least **9 months**, and — if that entitlement has already expired — the replacement comes within **90 days** of its expiration. When those rules are not met, Fours falls back to a **New** deal type and records a warning on the offer rather than failing the create.
Integrations that create entitlements from offers (MaaS) are exempt: GCP applies neither the minimum-duration nor the post-expiration rule to them, so a Native Renewal selection is left as you set it.
:::
### Why a replacement offer was refused
Before creating anything, Fours asks Google whether this replacement is allowed and which offer it must replace. If the answer disagrees with what you selected, the offer is refused up front and **nothing is created** — no half-made offer to clean up.
Each refusal names the specific problem and what to do next:
| What Google said | What to do |
| --- | --- |
| The marketplace requires this offer to replace a **different offer** than the one you selected. The message shows both. | Sync GCP offers for this integration, then start the replacement from the customer's current offer. |
| The offer you selected to be replaced **isn't eligible** for this customer. The message lists the offers that are. | Start the replacement from one of the listed offers, or create a new offer alongside the existing ones. |
| The customer's active order is on **public list pricing**, so the marketplace requires the public offer to be replaced rather than a private one. | Fours cannot create that offer type yet. Create it in the Google Cloud Marketplace console, or contact Fours support. |
| The customer has **no active order** for this product, and the marketplace only accepts a replacement when they do. | Create a standard private offer instead. |
| The customer **already has an active order**, and the marketplace requires a replacement rather than a new offer. The message names their current offer. | Start a replacement offer from this customer's entitlement. |
| The offer is set to end when the offer it replaces ends, but **that offer's end date isn't known**. | Sync GCP offers for this integration, or set an explicit end date on this offer. |
| Fours **couldn't confirm** with the marketplace which offer this one should replace. | Usually temporary — try again shortly. If it persists, contact Fours support. |
| The marketplace **did not allow** Fours to look up which offer this one should replace. | A configuration problem, not an offer problem; retrying will not help. Ask an administrator to check the GCP integration's permissions, then submit again. |
| The marketplace **could not accept the lookup** for this customer. | Usually a missing customer billing account on the offer. Check it, then submit again. |
Fours also refuses a replacement it cannot tie to the offer being replaced, before asking Google anything. The form stops with *"Could not determine the offer being replaced. Reload the entitlement and try again."* — reload the entitlement and start the replacement from it again. The create API refuses the same request, so nothing is created.
### Replacement Offer: Prepay
- **Payment Installment**: Specify amount, discount, and date for each installment (past installments cannot be changed).
- **Offer End Date**: Must be set.
> 
### Replacement Offer: Postpay
- **Monthly Flat Fee**: Set the monthly fee.
- **Discount on Usage**: Set the usage discount.
- **Enable Auto Renew**: Optionally enable auto-renewal.
- **Offer Duration**: Set duration in months.
- **Proration**: Inherited from the offer being replaced and read-only, because Google does not allow changing it on an amendment. It reads **Not set (GCP default)** when the original offer has no recorded setting.
> 
---
## Professional Service Offer
Create a private offer for a professional service product, allowing you to tailor pricing, payment schedules, and contract terms for your customer. This section outlines the required information and available payment options.
**Required information:**
- **Billing Account ID:** Buyer's billing account
- **Organization Name:** Buyer's organization
- **Contact:** Buyer's name and email
- **Plan:** Select the price plan
- **Start Date:** Specify when the offer begins
- **Offer Duration:** Specify how long the offer is valid
:::note
**Whether a SOW is required is decided by the product, not by the offer form.** For a synced GCP product, Fours reads the professional-services designation from the marketplace listing type — the same thing Google enforces the requirement on. This matters for offers created outside the Console: the Salesforce app and the API submit GCP offers without a product type, so an offer with no SOW used to pass every Fours check and then be rejected by Google after the fact. It is now refused up front, where you can still fix it.
:::
- **SOW (Statement of Work):** Attach or reference the SOW agreement
- **SOW Name:** (Optional) Name for the SOW
- **EULA:** Select or upload your custom contract. A custom EULA needs its uploaded file before the offer can be created.
- **Deal Type:** Specify the deal type
**Payment schedule options:**
- **Prepay:** Buyer pays on a custom installment schedule
- **Installment schedule:** Define payment dates and amounts
- **Commit Price:** Set the total committed price
- **Discount on Usage:** Specify any usage-based discounts
> 
- **Postpay:** Buyer pays monthly after service delivery
- **Monthly flat fee:** Set the recurring monthly fee
- **Discount on Usage:** Specify any usage-based discounts
- **Enable Auto Renew:** Optionally allow the contract to auto-renew
> 
:::tip
Ensure all required documents (such as the SOW) are ready before creating the offer. Align payment schedules and contract terms with your customer's procurement process for a smoother experience.
:::
## Virtual Machine Offer
Creating a private offer for a VM product enables customized pricing and terms for GCP virtual machines, including Committed Use Discounts.
**Step 1: Select Plan**
- Select the plan for the private offer.
**Step 2: Select Pricing Model**
- Once the plan is selected, the Pricing Model options will be displayed. These options mirror the standard usage-based models; select the one that aligns with your deal structure.
- **Commit discount with additional usage at list price**
- **Commit with all usage discounted**
- **Usage discount only**
> 
:::tip
For detailed definitions and calculation logic of these three pricing models, please refer to the **Usage-Based Offers** section above.
:::