Orders & contracts

What an accepted quote becomes once the customer says yes: an order to fulfil and, where relevant, a contract to govern the relationship.

Core objects

• Sales orders & order lines — the order to fulfil, created directly or from a quote, with status and payment status.
• Delivery schedules — fulfilment against an order, quote or contract: scheduled, shipped with carrier and tracking details, delivered or cancelled.
• Contracts & contract products — the agreement, with a lifecycle (activate, suspend, terminate, renew) and the products it covers, each carrying a committed, consumed and remaining quantity.
• Contract amendments, renewals and milestones — changes over the contract’s life, the renewal pipeline, and deliverables with dates and progress.
• Contract versions & redlines — successive drafts of the contract text, and the individual changes proposed, accepted, rejected or countered against them.
• Contract obligations & compliance items — what has been promised under the contract, and the regulatory requirements it has to keep satisfying.
• Clause library — reusable, approved contract language with variations.
• Sales agreements & contracted prices — negotiated pricing that governs future quotes.

What you can do

• Create a sales order from a quote, or create orders directly; add and edit order lines; update order status and payment status.
• Track fulfilment through delivery schedules — schedule a delivery, ship it with carrier and tracking details, mark it delivered, or cancel it. Fulfilment is tracked on the delivery schedule, not on the order lines.
• Raise an invoice from an order, and export the order list.
• Create and manage contracts; activate, suspend, terminate and renew them.
• Generate and download a contract document.
• Manage contract amendments, renewals and milestones.
• Negotiate contract text through versions, redlines and a shared clause library.
• Track obligations and run compliance checks against a contract.
• Maintain contracted pricing through sales agreements.

How quote-to-order conversion behaves

Conversion is deliberately narrow. The quote must be accepted first — a quote in any other status is refused. An approved, presented or sent quote is told to record the customer acceptance first (or use the public quote link); a declined quote is told to revise it and record a new acceptance. Anything else — a draft, for instance — is simply told the quote must be accepted, and which status it is in now. And a quote yields at most one sales order: the order and every line are written in a single transaction, so a failure part-way through leaves no half-built order, and a unique database index holds the one-order rule even when two conversions race each other. Converting the same quote again does not create a second order — you are handed back the order that already exists and land on it. Converting a quote to a contract is gated the same way and marks the quote as converted, after which a sales order can no longer be raised from it.

Orders created directly, rather than from a quote, accept a whitelisted set of header fields — customer, quote link, currency and exchange rate, addresses, dates, payment and delivery terms, notes and reference — plus an optional order number and starting status; anything else sent is ignored. Totals are never taken from the request: subtotal, tax and grand total are computed from the order lines, and payment status always starts at pending.

Moving an order through its life

An order carries two independent statuses: where it is in fulfilment, and how much of it has been paid.

Order status	What it means
Draft	Raised directly in CPQ and not yet committed.
Pending	Waiting to be confirmed. Quote conversion lands orders here.
Confirmed	Committed. Credit has been checked and the order is live.
In production	Being made or prepared.
Shipped	Handed to the carrier.
Delivered	Received by the customer.
Cancelled	Called off. A cancelled order cannot be confirmed.

Payment status runs separately over pending → partial → paid. It flips by itself when an online payment settles the invoice raised against the order — partial while a balance remains, paid once it clears — and can also be set directly on the order.

On the order itself, each status offers the one action that moves it forward — Confirm Order, then Start Production, Mark Shipped and Mark Delivered. The Confirm action appears on orders that are pending, which is where quote conversion puts them; an order you raised directly starts as a draft, and is confirmed through the API. A Generate Invoice button opens a new invoice pre-filled with the order and its customer — it is hidden only while an order is still waiting to be confirmed, or once it has been cancelled.

Confirming an order does more than change its status. When the order came from a quote and no contract exists for that quote yet, CPQ writes one automatically: a numbered contract for the order’s value, starting today and running a year, billed monthly, carrying the quote’s payment terms and terms-and-conditions text, with a contract product for every order line (committed quantity equal to the quantity ordered). The web app takes you straight to the new contract. If the contract cannot be written the order still confirms, and you can create the contract by hand.

Confirming twice is refused — the second attempt is told the order is already confirmed, and the guard holds even when two people confirm at the same moment.

Credit gates on orders

Credit is checked twice, and the two checks are not equally strict.

The new-order form looks up the customer’s credit as you fill it in. A hard credit hold blocks the order from being saved at all; a soft hold, or a value above the available credit, warns you and lets you continue.

Confirmation is the real gate. Confirming runs a credit check for the order’s value against the customer — or, where the quote behind it already carries an approved check, reuses that one. By default the order does not move if the result is a rejection or a hold. What comes back is actionable rather than a bare error: CPQ names the reason, shows the order value against the available credit, and links straight to the credit check so an override can be requested. While an override is pending, the Confirm button is replaced by a disabled Pending Approval; once finance has decided, confirming again picks that decision up — an approved override goes through, and a rejected one is re-tested against current credit, so a shortfall resolved in the meantime still passes. The order’s own status bar carries the customer’s available credit, and a Place Hold action for putting the account on hold from the order.

Confirmation reuses the quote’s approved check rather than running a new one, but it re-reads the customer’s holds first — so a hold placed after that check was approved still stops the order: a hard hold rejects it, a soft hold sends it for approval. See Credit holds.

The gate can be overridden deliberately, but not casually. The confirm request accepts two flags — skipCreditCheck, which skips the check, and forceConfirm, which lets a rejection, an active hold or a pending approval through — and using either needs a credit-override right of its own, beyond the ordinary right to update the order. A request without that right is refused, and every override is audited. A request that sets neither flag is unaffected.

One gap remains: setting an order’s status directly — through the status-update endpoint, or the mobile sales app’s Mark Processing — does not run a credit check at all.

Delivery schedules

Fulfilment is its own module rather than a field on the order. A delivery schedule must point at a sales order, a quote or a contract (at least one of the three), and one order can have as many schedules as the shipment plan needs — which is how partial and staged fulfilment is handled.

A schedule carries a delivery number and description; requested, promised and scheduled dates plus a delivery window; the ship-to name, phone, email and address; carrier and service level; total weight, package count and dock or special-handling instructions; and shipping, insurance and handling costs in a chosen currency. Carriers offered out of the box are FedEx, UPS, DHL, USPS, BlueDart, Delhivery and Other, at Standard, Express, Priority, Economy or Overnight service.

Movement through the schedule is constrained:

From	Can move to
Draft	Scheduled, Cancelled
Scheduled	In transit, Cancelled
In transit	Delivered, Partial, Cancelled
Partial	In transit, Delivered
Delivered	—
Cancelled	—

Ship is offered only on a scheduled delivery, and records the tracking number, tracking URL and carrier along with the ship date (today unless you give one). Mark delivered is offered only on a delivery that is in transit or partially delivered, and records the delivered date and proof of delivery — who received it and a signature image. Cancel is available while a schedule is still draft, scheduled or in transit; a delivered schedule cannot be cancelled. Only a draft schedule can be deleted — cancel anything further along. Once delivered, the proof-of-delivery fields are the only ones still editable, and a cancelled schedule is closed to edits altogether.

The delivery schedules list filters by status and exports to CSV; each schedule’s own page offers Ship, Mark Delivered and Cancel as its status allows.

Contract lifecycle management

Contracts are typed — standard, master agreement, subscription, service, support, licence or framework — and run on a billing frequency of monthly, quarterly or annual. Each carries a value, a committed value, a start and end date, payment and delivery terms, renewal settings and its own product list.

Activating, suspending, terminating and renewing

Activation is guarded: a contract cannot go active without a customer, a start date and at least one contract product. Activating raises a contract.activated event, so workflows and webhooks can hang off the moment a contract goes live.

Suspend parks an active contract; terminate closes it, recording the effective termination date and keeping the reason you give with the contract. Renew extends the contract in place — you supply the new end date and, optionally, a new value — and returns it to active.

A contract can also be generated as a document and downloaded, giving you a formatted version of the agreement built from the contract’s own data.

The contract page brings the rest together as tabs — overview, products, amendments, renewals, milestones, compliance, obligations and version history — with counts on the tab labels, so you can see where the work is without opening each one. The contract list flags anything ending within 90 days, so renewals surface without having to run a report.

Amendments

An amendment is a proposed change to a live contract, drafted and approved separately from it. Amendments come in seven kinds — add product, remove product, price change, term change, quantity change, renewal and cancellation — and the form adapts to the kind you pick, pre-filling the contract’s existing products when you are removing them or changing quantities, and showing the financial or date sections only when they are relevant.

Approving an amendment is what applies it. CPQ writes the change through to the parent contract: the new contract and committed values, billing frequency and payment terms, the new end date (whether given outright, as a number of extension days, or as a co-termination target), amended special and delivery terms, auto-renewal settings, and the products added, removed or re-quantified. Where no explicit value is given, the new contract value is worked out from the product changes themselves. The contract’s amendment count goes up by one in the same write. Rejecting an amendment leaves the contract untouched.

Renewals

A renewal is a record in its own right, not just a new end date. It tracks the renewal term and dates, the current versus proposed contract value and ARR, price escalation and renewal discount, the products to add, remove or re-quantify, the renewal owner, a renewal probability and a churn risk score, plus notes on competitive threats and customer sentiment. Renewals move through pending → quote created → sent to customer → accepted, with declined and lapsed as the other outcomes.

Approving a renewal applies it to the contract and marks it accepted. The end date moves to the renewal’s own end date, or forward by its term in months; the next renewal date is recalculated from that end date less the notice period; and the contract value becomes the renewal value, or is escalated by the renewal’s percentage or fixed amount, with the committed value carried along. Auto-renewal settings and the renewal term follow. Rejecting a renewal records it as churn, with the reason and category you give.

Milestones

Milestones are the contract’s dated deliverables, each with planned start and completion dates and a percent-complete you raise as work advances. They run through not started, in progress, completed, approved, overdue and cancelled, are listed both per contract and across all contracts, and can be marked complete from the milestone itself.

Versions and redlines

Contract versions capture the successive drafts of a contract’s text. Each version has a status — draft, pending review, approved, active or superseded — and activating a version makes it the one in force. A contract’s own page carries a version history timeline; the Contract Versions screen lists versions across contracts and is where new ones are created and activated.

Redlines are the individual changes proposed against a version: an addition, a modification or a deletion, each with the original text, the proposed text, a section reference, who proposed it and when. The redline view puts original and proposed text side by side and summarises how many changes are pending, accepted, rejected or countered. Each one can be accepted, rejected, or countered with your own wording, with a comment attached to the decision. Open a contract’s redlines at /contracts/<contract id>/redlines.

The clause library

The clause library holds approved contract language for reuse: each clause has a title, a category, the clause text itself and a plain-language explanation of it, a risk level, a jurisdiction and searchable tags. Clauses are approved before they can be relied on, and the library shows each clause’s version, risk level, approval state and how often it has been used. A clause can also carry variations — alternative wordings of the same clause for different situations — which is what makes a redline a choice between known positions rather than free text.

Obligations and compliance

Obligations record what the contract actually promises: the deliverable and its quantity, the expected and actual delivery dates, how much has been satisfied so far, and — for revenue purposes — the transaction price, standalone selling price, allocated amount and recognition method and period. Obligations can be marked satisfied, and have delivery and recognition progress tracked against them. They are the ASC 606 performance obligations that revenue recognition works from.

Compliance items are the regulatory side: a requirement with a type and category, an assessment frequency and next due date, the evidence required and provided, a remediation plan and owner, certification and attestation details, and any violation recorded against it. Each item carries a status — compliant, partially compliant, non-compliant, under review or pending — with a compliance score, a risk score and a risk level.

Running a compliance check is not a manual re-typing of that status. CPQ walks the contract’s obligations and milestones, counts what is satisfied, gives partial credit for work in progress, and lists every obligation that is overdue or breached and every milestone that missed its deadline. It scores the result out of 100 and sets the status and risk level from it — 90 or above is compliant and low risk, 70 or above is partially compliant and medium risk, below that is non-compliant and high risk — recording the assessment date and who ran it.

Sales agreements and contracted pricing

A sales agreement is the negotiated commercial framework with a customer, separate from any single contract. Each agreement has a number, a name, the account it covers, a period, a status and its terms and conditions, and comes in five kinds: master, volume, pricing, rebate and framework.

Underneath the agreement sit its contracted products — the specific products covered, each with the agreed price, minimum and maximum quantities and whether it is currently available. Those become contracted prices. When a line is added to a quote for that customer and product, the pricing engine applies the contracted price at the end of the waterfall, as a negotiated discount off the price it has already worked down to — so a contracted price below that price takes effect, and one above it has no effect at all. A line saved with a manual price is stored as typed; the agreement price applies only when the line is priced through the engine.

What an integration receives when an order goes live

Confirming an order publishes order.activated — the signal that a commercial commitment is now real and downstream systems should provision against it. Unlike a header-only “an order happened” ping, the event carries line-level entitlements, so a licence server, fulfilment system or provisioning API can act on it without calling back for the order’s contents.

Any webhook subscription for the tenant that lists the event receives a POST like:

{
  "event": "order.activated",
  "timestamp": "2026-07-25T09:12:44.108Z",
  "data": {
    "event_id": "order.activated:1f2e9c74-...",
    "external_reference": "acme-workspace-42",
    "orderId": "1f2e9c74-...",
    "orderNumber": "SO-00118",
    "contractId": "8c31b0a2-...",
    "companyId": "1",
    "status": "CONFIRMED",
    "entitlements": [
      {
        "account_uuid": "3d5f...",
        "product_code": "JUP-PRO",
        "plan_code": "jupiter_pro",
        "seat_count": 25,
        "credit_amount": null,
        "period_start": "2026-07-25",
        "period_end": "2027-07-25",
        "status": "ACTIVE"
      }
    ]
  }
}

One entitlement line is produced per active order line. account_uuid is the customer the order is for and product_code comes from the catalogue. plan_code and credit_amount are read from the product’s own metadata, so the plan vocabulary is catalogue data you define rather than anything CPQ hard-codes; credit_amount is the per-unit prepaid credit multiplied by the quantity ordered, and is null for products that are not credit packs. seat_count is the ordered quantity. period_start is the moment of activation; period_end is that date plus the product’s default subscription term for recurring products, or plus the credit pack’s expiry months for prepaid credits, and null for one-off lines that never expire. Month ends are clamped rather than allowed to overflow — a term starting 31 January ends on the last day of the month, not the 2nd or 3rd of the next one.

Two fields exist for the integrator’s benefit. event_id is stable for the life of the order — one activation, one id — so a retried delivery can be recognised and discarded; the X-Webhook-Delivery header is fresh on every attempt and cannot be used for that. external_reference is an opaque correlation id you may set when the order is created; CPQ echoes it and never interprets it, which is how an order is tied back to a workspace, tenant or record in your own system.

Deliveries are signed and retried. Each POST carries X-Webhook-Event, X-Webhook-Delivery and, when the subscription has a secret, an X-Webhook-Signature of the form sha256=<hmac> computed over the exact request body — a secret is generated for you if you do not supply one. A non-2xx response or a network failure is retried up to the subscription’s retry count (three by default) with a lengthening delay, and every attempt is logged with its status, response and duration for you to inspect per webhook. Publishing is fire-and-forget: a webhook that is down never fails or delays the confirmation.

Note

The event checklist on the admin Webhooks screen offers order.created and order.fulfilled but not order.activated (or order.confirmed), so subscribe to this one through the API — POST /api/v1/webhooks with order.activated in events. GET /api/v1/webhooks/events returns every event the dispatcher recognises.

The mobile sales app has a confirm action of its own, and its payload is built the same way minus the order number and contract id — but the write behind it is not accepted against the current database, so confirm orders on the web.

Assets and installed products

What a customer ends up owning after fulfilment — serial-numbered equipment, installed products, warranties, maintenance schedules and service contracts — is tracked in CPQ’s assets module rather than on the order. Confirming an order does not create asset records; assets are created and maintained in that module.

Connects to

• Quotes & approvals — a quote converts into an order or a contract.
• Products & pricing — where contracted prices sit in the pricing waterfall.
• Subscriptions — recurring commitments are managed as subscriptions.
• Billing & payments — orders and contracts lead to invoices.
• Accounts — the financial ledger of record.