Purchase requests vs. orders
Between the cart and the order there is a third document. Understanding what it is — and deliberately what it is not — explains most of the behaviour in this area, including the parts customers find surprising.
The three documents
| Document | Exists while | Binding? | Owned by |
|---|---|---|---|
| Cart | The buyer is shopping | No | The buyer |
| Purchase request | Signatures are outstanding | No | The buying company's process |
| Order | From placement onward | Yes | Both companies |
A purchase request is the buying company's internal document: we intend to buy this, subject to approval. In German procurement it is the Bestellanforderung — the BANF — and it is a familiar object to anyone who has worked with SAP. It has a requester, a value, an account assignment, and a decision pending on it. It is not a commitment to you, the supplier, and it must not behave like one.
An order is the commitment. It has a number you both quote, it appears in your fulfilment queue, it consumes stock, and it eventually becomes an invoice.
The rule that follows from that
The order is created only when the last signature lands.
This is the single most important design decision in the area, and it is worth being blunt about why the obvious alternative was rejected.
The obvious alternative is to create the order immediately in a requested
status and flip it to placed when approved. It looks simpler and it is wrong,
for four reasons that all show up in production:
- Your order list fills with things that are not orders. Every count, every dashboard, every export has to remember to exclude two statuses. Somebody eventually forgets, and a revenue figure includes €80,000 of requests that were never approved.
- Stock. An order reserves inventory. A request that reserves inventory lets a buyer with no authority hold your last six spindles for a week by submitting a request nobody will approve.
- Number ranges. An order number is quoted on delivery notes and invoices. Burning order numbers on requests that get rejected leaves permanent gaps that your customer's auditor will ask about.
- It leaks into your ERP. Whatever creates an order eventually syncs it. A request is nobody's business but the buying company's.
So the Orders app has no requested and no declined status. An order's
lifecycle is pending → placed → in_fulfillment → completed, or
cancelled, and every one of those means a real order exists. See
The three order statuses.
What the request carries
The purchase request mirrors the shape of an order: the same line structure, the same quantities, the same prices, the same addresses, the same cost centre per line. It has its own number from its own range, and once the order exists the two reference each other in both directions.
The mirroring is deliberate. It means an approver looks at exactly what will be ordered, and it means the conversion at final approval is a copy rather than a translation — there is no field that exists on one and not the other for somebody to forget.
It also means the request is a snapshot. Which raises the question everybody asks second.
What if the price changes while it waits?
It can. A request approved on Thursday was priced on Monday. Three things can have moved: the price list, a promotion's validity, and stock.
The snapshot is what the approver signed for, so it is what the order is created from. If a price has moved materially in the meantime that is a commercial conversation, not something the system should resolve silently by re-pricing behind the approver's back — an approver who signs €4,200 and finds €4,600 on the invoice will not use the shop again.
The practical consequence: approval latency is a commercial risk, and it is another argument for setting thresholds so that most orders never wait at all. For volatile assortments — steel, copper, anything indexed — say so in the customer's policy and keep the escalation window short.
Stock: reserved when?
Not on the request. There is nothing to reserve against: no order exists yet, and the Inventory app deals in orders.
That is the honest answer and it is the right one, but it has a consequence you should tell customers about before they discover it: a request is not a guarantee of availability. A three-day approval on a part with two in stock can end with an approved request and no goods. Handle it the way you already handle any long-lead order — see Stock and locations and Partial deliveries.
Budget, by contrast, is held from the moment of submission. Money and stock behave differently here on purpose: the budget is the buying company's own number and reserving it costs you nothing, while stock is yours and reserving it for an unapproved request costs you a sale.
The budget movement
Four operations, and the request drives three of them.
| Moment | Operation | Effect on the cost centre |
|---|---|---|
| Request submitted | reserve | The amount is held. It no longer counts as available |
| Final approval, order created | confirm | The hold becomes real consumption |
| Rejected, withdrawn or expired | withdraw | The hold is released. Available budget returns |
| Order placed with no approval needed | commit | Consumed in one movement, no hold |
Every one of those writes an entry in the budget ledger. Nothing overwrites a total. See Reading the budget ledger.
The reservation is keyed on the request, which is what makes a retried submit safe: a buyer who double-clicks, or a mobile connection that drops mid-request, cannot produce two requests holding the budget twice.
Editing a request in flight
A request under decision is not frozen, but changing it is not free either. Two kinds of change, and they behave differently:
- Reducing — removing a line, cutting a quantity. The value falls, the reservation is adjusted down, and the request may now fall under a threshold it previously exceeded.
- Increasing — adding a line, raising a quantity, changing to a more expensive variant. The value rises, and the rules have to be evaluated again, because an amount that needed one signature may now need two.
The safe mental model: any change re-runs the evaluation. Decisions already given on a materially changed request are not carried over — an approver who signed for €900 has not signed for €9,000. Expect a changed request to go back out for signature.
Rejection and resubmission
A rejected request is finished. It is not reopened, not edited into a new attempt, and not resurrected — it stays as the record that this was asked for and refused, with the reason and the person attached. That record is the audit control, and editing rejected documents destroys it.
What the buyer does instead is start a new request, usually from the rejected one as a template. This is not friction for its own sake: rejections in B2B procurement are almost never "no", they are "not this quantity", "not this supplier", "not this quarter". A fresh request with the correction and a reference to what was refused is what the approver wants to see anyway.
Next
- The buyer's path — submitting one.
- The approver's path — deciding on one.