Understand the order lifecycle

Quotes, approvals and negotiation

Selling where the price is agreed before the order exists, and what the platform does and does not model.

In most B2B relationships the price is settled before anyone opens a shop. A buyer asks for a quote, your Innendienst prices it, the buyer raises a purchase order against it, and only then does an order appear. Knowing where that conversation lives, and where it does not, saves you from trying to run it in the wrong place.

The classic B2B path

The vendor-neutral sequence looks like this:

Anfrage (RFQ). The buyer asks what 500 metres of hose costs, delivered to two sites, this quarter.
Angebot (quote). You answer with prices, quantities, a validity date and delivery terms. It is an offer, not a sale.
Bestellung (PO). The buyer's ERP raises a purchase order against your quote. It carries their number, the one that has to end up in customer_order_number.
Auftragsbestätigung (order confirmation). You confirm what you will deliver and when.

Steps 1 and 2 are a sales conversation. Steps 3 and 4 are the order. Avoid treating the whole chain as one document that gradually hardens. The negotiation and the order have different owners, different lifetimes and different systems.

What the platform models, plainly

There is no draft order state. An order's lifecycle values are pending, placed, in_fulfillment, completed and cancelled, and pending means awaiting approval, which is a different thing from a draft. There is no editable, unnumbered, not-yet-real order you can build up over several sessions and then convert. If you are looking for a quoting tool, this is not it, and pretending otherwise produces orders nobody meant to place.

What the platform does model, and models well, is everything on either side of the quote:

The thing you want	Where it lives
A negotiated price for one customer	A contract price in the Pricing area
A price break at 500 units	A scale price
A basket the buyer builds over weeks, saves and re-uses	An order list
A shipping cost that has to be quoted by hand	The quote above threshold on a shipping method
An order that must be released before it is real	The approval path below

That is the honest split. Prices are negotiated in Pricing and then are the price that buyer sees; the shop does not need to know they were argued over. The recurring basket the buyer keeps re-ordering is an order list. And the part of a quote that needs a per-case answer, freight on a pallet shipment, has its own mechanism.

Freight that cannot be priced automatically

A shipping method can carry a quote above value. Above that order value the method stops returning a calculated price and the shipment becomes a quoted one: Speditionsversand auf Anfrage. This is the common case where a parcel tariff cannot answer: two pallets to an island, a crane delivery, a timed slot at a construction site.

Set it on the method rather than telling buyers to phone. The threshold is visible and consistent, whoever picks up the phone.

The approval path

pending exists for orders that are real but not yet released. There are two independent doors into it.

By permission. Who is allowed to do what is defined in the customer's own organization. A contact who may request orders but not place them gets an order in pending and an approval request, rather than a refusal. A contact who may place orders gets a placed order immediately.

By value. A tenant-wide threshold can be set: any order above that value becomes pending regardless of who placed it. Someone holding the approval permission is exempt: an approver does not queue their own order.

The buyer may	Order value	Result
Place orders	Below the threshold	`placed` immediately
Place orders	Above the threshold	`pending`, awaiting approval
Only request orders	Any	`pending`, awaiting approval
Approve orders	Any	`placed` immediately

The order records which of the two put it in the queue, so an approver can tell "this person always needs sign-off" from "this order is unusually large".

Approval on your side or theirs? These are your rules, applied to your buyers. Large customers also run their own approval workflow inside their procurement system, before the order ever reaches you. That path is described in How procurement governance works. Both can be in play on the same order.

What a pending order already costs you

A pending order is not free. It carries a real order number from your number range, it appears in your order list, and it emits an event your integrations may act on. What distinguishes it is an empty placed_at; the number has already been handed out.

Plan for two consequences:

Your order numbers will have gaps if requests are regularly rejected. If your accounting expects a gapless sequence, do not use the approval path as a shopping-list feature.
Do not wire your ERP to the wrong signal. An order arriving in pending is not an order to fulfil. Integrations must react to the placement event rather than to "an order row appeared". See Events and webhooks.

How this works in the Revenue Cloud

Orders awaiting approval are a filter on Order Management › Orders (status = pending) and a counter on the Cockpit dashboard, Awaiting approval. Working the queue means opening the order, checking it, and either letting it proceed or cancelling it with a reason.

Negotiated prices live in Pricing and resolve automatically at checkout, so the buyer sees their agreed price without anyone re-keying it. If a buyer tells you the price on their screen is not the one you agreed, that is a pricing question and it has a diagnostic: Check which price a buyer sees.

The three order statuses — where pending sits among the rest.
Order lists and recurring carts — the saved basket a buyer re-orders from.

Edit this page

The three order statuses

An order can be confirmed, unpaid and half-shipped at the same time. Why that needs three independent statuses, and how to read them.

Design checkout, payment and shipping

Payment methods, shipping rates, stock locations and document numbering: the rules a buyer meets at checkout.