The buyer's path: submit for approval
This is the path your customer's buyer walks in the storefront. You will not walk it yourself very often, and you need to know it exactly — almost every procurement support call is somebody describing this journey badly over the phone.
What the buyer does not see
Start here, because it is the part that gets misexplained.
The buyer never chooses between "order" and "request for approval". There is one action, and the decision is made server-side after they take it. A buyer who tells you "I clicked the wrong button" has not — there is only one button.
That matters for a reason beyond tidiness: it is why the controls cannot be bypassed. There is no path to an order that skips the evaluation.
1. Cost centre on the line
Each line in the cart carries its own cost centre, because one delivery routinely covers three departments.
What the buyer sees per line depends on the restrictions you configured:
| Situation | What happens |
|---|---|
| Exactly one cost centre usable on that line | It is filled in automatically. The buyer does nothing |
| Several usable | A choice, showing name and code — Werkstatt Halle 2 (4711) |
| None usable | The line cannot be booked. The buyer is stopped here, not at submit |
Auto-selection is the setting that decides whether this feels like governance or like data entry. If your customer's buyers are choosing a cost centre on every line of every order, the restrictions are too loose — go back to Cost centres.
Cost centres set on an order list item come through with the item, so a repeating order carries its allocation without anybody retyping it. For customers who reorder the same twenty articles every week, this is the single highest-value thing to set up.
2. Budget feedback before submitting
Before the buyer commits, the cart shows what booking against these cost centres would mean: what is left on each, and whether this cart would exceed it.
This is the part buyers value most and it is worth saying out loud in a demo. The alternative — finding out after submitting, or worse, three days later when an approver refuses it — is what their current email process does.
Three outcomes are visible at this point:
- Within budget and within their limit — this will become an order.
- Over one of them — this will become a purchase request, and the buyer can see roughly why before committing.
- Blocked by a hard limit — the submit will be refused. Better here than after.
3. Submit
One action. Server-side, three things can result:
| Result | What the buyer sees |
|---|---|
| No rule fires | An order, with an order number. Done. The budget is consumed |
| A rule routes it | A purchase request, with its own number, and who it is waiting on |
| A rule prevents it | A refusal with a reason they can act on. Nothing is created |
Most orders should land in the first row. If your customer's buyers see a request more often than not, the thresholds are set too low — see Approval models.
When a request is created, the budget is held immediately. Their colleague cannot spend the same money while the request waits.
4. Track it
The buyer's request list shows the requests they raised, their value, who is outstanding, and how long each has been waiting. That last column is the useful one: it is what a buyer looks at before phoning the approver, and it is what they will quote to your Innendienst when they phone you instead.
Possible outcomes:
| Outcome | What happens next |
|---|---|
| Approved | An order is created and appears in the normal order lifecycle. The held budget becomes consumption |
| Rejected | The request closes with a reason. The held budget is released |
| Withdrawn by the buyer | Same as rejected, without the reason |
| Changed by the buyer | Re-evaluated. Expect it to need signature again |
A rejected request is not reopened. The buyer starts a new one, usually from the old one, with the correction — see Purchase requests vs. orders.
What to check
Run these three carts as a buyer at the customer, before go-live:
- A small cart, everything auto-selected. It should become an order with no cost-centre interaction at all. If the buyer had to choose anything, fix the restrictions.
- A cart just over a threshold. A request appears, the approver is notified, the budget shows the amount held.
- A cart with two lines on two cost centres. Both allocations survive to the order line and reach the ERP.
Common calls, and what they mean
| The buyer says | Look at |
|---|---|
| "It won't let me order" | Whether a prevent rule fired, or whether a line has no usable cost centre |
| "It made a request, I have permission" | Their personal limit, and the cost centre's remaining budget |
| "The cost centre is missing" | Restrictions on that line's product or category |
| "Nothing happened after I submitted" | The request list. It almost always did |
Next
- The approver's path — the other half.
- Approvals that get stuck — when it stops moving.