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, 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 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 them. Somebody eventually forgets, and a revenue figure includes €80,000 of requests that were never approved.
- Stock. A buyer with no authority could 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 declined leaves gaps 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 procurement app keeps requests in a table of their own, and places the order in the orders app only at final approval. Every order your ERP sees is a real one.
The life of a request
| State | Means | What comes next |
|---|---|---|
| Pending | Waiting for approvals. Budget is reserved | Approved, declined or cancelled |
| Approved | Every approval given. The order is being placed | Ordered |
| Ordered | The order exists and the request links to it | Final |
| Declined | An approver declined. Reserved budget is returned | Final |
| Cancelled | Withdrawn while pending, by the buyer or an administrator. Reserved budget is returned | Final |
There is no expiry. A pending request stays pending until somebody decides it or cancels it, however long that takes.
Approved and Ordered are separate on purpose. Placing the order is a step that can fail when another service is briefly down, and the decision must not be lost because of it. If the order does not land straight away, the request stays Approved, and the hourly reconciliation places it, never twice. You can start the same pass by hand with Run reconciliation on the purchase-request list.
What the request carries
The purchase request mirrors the shape of an order: the same line structure, quantities, prices, addresses and the cost centre per line. It has its own PR number, unique within your tenant. The number is generated, not counted: it does not run in sequence and does not come from a number range, so do not promise a customer a gapless BANF series. Once the order exists, the request links to it.
The mirroring is deliberate. An approver looks at exactly what will be ordered, and the conversion at final approval is a copy rather than a translation: the order is placed with the lines and prices the request holds.
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. The price list, a promotion's validity and stock can all have moved.
The snapshot is what the approver signed for, so it is what the order is placed with. Nothing re-prices it behind the approver's back. If a price has moved materially in the meantime, that is a commercial conversation: an approver who signs €4,200 and finds €4,600 on the invoice will not use the shop again, and neither will you want to deliver steel at last month's price.
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, such as steel, copper or anything indexed, say so in the customer's policy and agree how fast approvers decide.
Stock: reserved when?
Not on the request. No order exists yet, and nothing in the request touches inventory.
That 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
Every movement writes an entry in the budget's ledger. Nothing overwrites a total.
| Moment | What happens on the cost centre's budget |
|---|---|
| Request submitted | The amount is reserved. It no longer counts as available |
| Lines of a pending request corrected | The reservation moves to what the lines now come to |
| Final approval, order placed | The reservation is confirmed against the order. No further amount moves |
| Declined or cancelled | The reservation is withdrawn. The budget gets it back |
| Order placed with no approval needed | The amount is booked against the order in one movement |
| Order cancelled, whole or line by line | The booked amount is given back, unless its budget period has closed |
The reservation is keyed on the request, and a submission on the cart: a buyer who double-clicks, or a connection that drops mid-request, does not produce two requests or two reservations. See Reading the budget ledger.
Correcting a request in flight
A pending request is not frozen. What was recorded about it, such as the customer order number, an external reference or the addresses, can be corrected on the request with Edit, in any state. What was spent can change only while it is pending, and only line by line: the procurement app accepts line corrections through its API, and the Cockpit shows the lines read-only.
A line correction recomputes the request's totals and moves the budget reservation to the new amounts. It does not run the approval rules again, and approvals already given stay given. An approver who signed for €900 has therefore signed for whatever the lines say now. If a change is material, the cleaner path is to cancel the request and let the buyer submit a new cart, so the rules measure it afresh.
Once a request has been decided, what was spent is settled for good.
Decline and starting again
A declined request is finished. It is not reopened and not edited into a new attempt: it stays as the record that this was asked for and refused, with the approver and the reason attached. That record is the audit control.
The same cart cannot be submitted again either: the procurement app refuses a cart whose request was declined or cancelled. The buyer builds a new cart, and the new attempt is measured against the rules as they stand now. That is not friction for its own sake: declines in B2B procurement are rarely a flat "no", they are "not this quantity", "not this supplier", "not this quarter", and a fresh cart with the correction is what the approver wants to see anyway.
Next
- The buyer's path — submitting one.
- The approver's path — deciding on one.