Set up recurring orders

Standing orders

A saved basket plus a schedule. Setting the interval, the price mode, the notification lead time and the end condition — before the first run rather than after it.

A standing order is an order list with a schedule attached. On each run the list is converted into a real order, exactly as if the buyer had pressed the button themselves.

Before you begin. You need three things: the order list that will be run, owned by a contact in the right organization; agreement with the customer on the interval and the quantities; and a decision on the price mode — see Recurring revenue in B2B. Settle the price mode in writing. It is the only part of this that turns into an argument.

What a standing order is made of

Part	What it decides	Change it later?
Source list	The articles, quantities, units, cost centres and position texts	Yes — edit the list, and the next run picks it up
Interval	How often a run happens	Yes
Next run	The date of the next conversion	Yes
Price mode	Captured prices, or resolved fresh each run	Yes, but tell the customer
Notification lead time	How long before a run the buyer is warned	Yes
End condition	A date, a number of runs, or open-ended	Yes
Owner	Whose orders these are, and whose approval path applies	Recreate instead

The source list is doing more work than it looks. Because a run converts the list, everything a list position carries rides along: cost_center_id, custom_sku and position_texts land on the order positions, which is what makes the resulting order bookable at the customer's end without a phone call.

Set one up

Build the order list. Go to CRM › Order Lists and either open the buyer's existing list or create one. Give it a name the buyer recognises a year from now — Wartung Halle 3, not Liste 4. Check the quantities are the per-run quantities, not an annual total.
Check the positions carry the buyer's own data. Cost centre per line, their article number in custom_sku, the machine or floor reference in the position texts. Adding these once here saves them on every future run.
Create the standing order from the list. The list stays the master: it is referenced, not copied, so editing the list changes future runs.
Set the interval and the first run date. See the next section for the traps.
Choose the price mode. Current at each run is the default and is right for goods bought off a price list you maintain. Fixed at start freezes the captured prices and is right only when the arrangement is itself the price agreement.
Set the notification lead time. Long enough for the buyer to skip or adjust — three to five working days for consumables, longer if their approval path has a step in it.
Set an end condition. Open-ended is the default and the riskiest. If the underlying agreement runs to the end of the year, end it at the end of the year and renew deliberately.
Agree who may change it. Customer self-service, your Innendienst, or both. Write it down; this is the question that produces the first complaint.
Activate, then watch the first run happen rather than assuming it did.

Intervals that survive contact with a calendar

Most standing-order incidents are calendar incidents.

Interval style	Behaves well	Watch for
Every n days	Predictable spacing	Drifts across the week — a 14-day run eventually lands on a Sunday
Weekly on a weekday	Stable for the goods-receipt department	52 runs a year, not 12
Every n weeks on a weekday	The usual right answer for consumables	—
Monthly on day n	Matches invoicing rhythms	Day 29, 30 and 31 do not exist in every month
Quarterly / annually	Fits contracts	A single missed run is a quarter of the revenue

Two rules that prevent most of it: pick a weekday, not a day number, when the goods have to be received by somebody; and decide once what happens when a run falls on a weekend or a public holiday — move it forward, move it back, or run it anyway. Deliveries that arrive on 26 December are memorable for the wrong reason.

What a run actually does

Worth being precise, because people expect a draft and there is not one.

Prices resolve fresh (in the default mode), exactly as a checkout would — the buyer's contract prices and scale prices at that moment. See How pricing works.
The order is real, immediately. There is no draft stage anywhere on the platform. What comes out is an ordinary order with the ordinary three statuses.
The approval path still applies. If the owning contact may only request orders, or the value is above your approval threshold, the run produces an order in pending rather than placed — which is correct, and which means somebody has to release it. See Approval rules.
It transmits to the ERP like any other order, through whatever route you configured — see Integration patterns.
A position whose article has disappeared is handled by the same policy as a manual list conversion: take it anyway, leave it out and report it, or refuse the whole conversion. The middle option is the sane default for scheduled runs, because a run that refuses is a run nobody notices.

An open-ended standing order with no notification is a liability. It will outlive the contract, the contact who agreed it, and the machine the parts were for. Every standing order needs an end date or a review date, and a notification that reaches a person who still works there.

Stock on run day

A scheduled run competes for stock with everything else happening that morning. If the goods are scarce, reserve them: the platform's holds work off on_hand − reserved, so a reservation placed for the run is honoured against walk-up orders. See Stock, locations and availability and, for the failure case, Common problems.

What to check

After the first run:

An order exists, with the expected number of positions and no skipped lines.
The customer_order_number the buyer needs is on it.
Cost centres and position texts arrived on the order positions, not in a comment.
The prices on the order match what the notification said they would be.
The order reached your ERP.
The next run date advanced to the right date.

Manage standing orders — pause, skip, change, end.
Configure reorder suggestions — for demand that is regular but not fixed.

Edit this page

Set up recurring orders

Set up — Recurring Orders & Subscriptions.

Subscriptions

Plans, terms and billing cycles — and the distinction that decides everything: what you bill for is not what you deliver, and the two run on different clocks.